Dans le processus, on nous pose souvent la question: comment implémenter un analyseur statique en développement pour que
tout se passe bien.
Nous avons déjà expliqué pourquoi un analyseur statique est nécessaire pour un développement sûr. Cet article sera utile si vous choisissez un analyseur statique ou envisagez déjà de l'implémenter. Comment configurer le processus pour que les vulnérabilités découvertes dans le code soient enfin corrigées? Dans cet article, nous allons essayer de vous aider à résoudre ce problème.
Qu'est-ce qui vient?
La mise en œuvre de l'analyseur de manière à ce que les vulnérabilités soient corrigées de manière stable n'est pas chose rapide. Par expérience, nous pouvons dire que cela prend de quelques semaines à plusieurs mois. Si vous implémentez l'analyseur dans une grande entreprise, préparez-vous à une série d'approbations. Après tout, ce sont des centaines de bases de code qui doivent être analysées et des dizaines d'équipes avec leurs propres ordres de développement.
Pour ajouter une nouvelle étape de développement - l'analyse statique, vous devrez étudier le fonctionnement du processus de chaque équipe et proposer une solution adaptée à tous. Dans les petites entreprises, l'ordre de développement établi peut ne pas exister du tout. L'implémentation de l'analyseur peut être une excuse pour construire un processus. Pour que l'intégration soit plus douce, nous vous conseillons de savoir quel analyseur a les capacités pour cela.
Quelles sont les options d'intégration?
En règle générale, l'analyseur suppose une interface non graphique (CLI, REST) ​​pour l'intégration dans n'importe quel processus. Il existe des analyseurs avec des intégrations prêtes à l'emploi: avec des outils de construction et des environnements de développement, avec des systèmes de contrôle de version (Git, SVN), des serveurs CI / CD (Jenkins, TeamCity, TFS), des systèmes de gestion de projet (Jira) et la gestion des utilisateurs (Active Directory). Plus votre entreprise sera utile, plus il sera facile de tout configurer.
Comment pouvez-vous construire un processus?
Considérez la situation standard: les services impliqués sont la sécurité de l'information, la gestion des versions et le développement. En règle générale, le client de la mise en œuvre de l'analyseur est la sécurité de l'information (SI). La tâche consiste à s'entendre sur qui, quand et quoi fera. Nous distinguons les étapes suivantes:
démarrer l'analyse, traiter les résultats de l'analyse, créer une demande de correction de la vulnérabilité, corriger la vulnérabilité, vérifier la correction . Examinez chaque étape plus en détail.
Étape 1. Exécutez l'analyse
Vous pouvez exécuter l'analyse manuellement ou automatiquement. Les approches ont leurs avantages et leurs inconvénients.
ManuellementLui-même se souvenait de l'analyseur, il téléchargeait lui-même le code, il allait voir les résultats.
S'il existe une dizaine de projets dans l'entreprise et qu'un responsable de la sécurité est chargé de surveiller la sécurité, un tel scénario est possible. S'il existe une centaine de projets, vous devez configurer l'automatisation.
AutomatiséDécidez à quelle fréquence et à quel moment vous devez analyser le code. Par exemple, avant d'entrer dans un environnement productif, selon un horaire donné (une fois par semaine) ou après chaque changement.
Si l'application est rarement mise à jour, mais que vous devez également surveiller sa sécurité, configurez l'analyse en cas de modifications.
Si beaucoup de gens travaillent sur le code, de nombreuses branches sont créées, les changements affluent souvent - il est préférable d'analyser souvent, mais n'interfère pas avec le développement. Par exemple, au moment de la création d'une demande de fusion avec la branche principale ou lorsque l'état de la tâche sur cette branche change. L'intégration avec un système de contrôle de version ou avec un système de gestion de projet vous y aidera. L'intégration avec CI / CD fera de l'analyse l'une des étapes de construction.
Définissez le calendrier afin que vous ayez le temps de traiter les résultats.
Étape 2. Traitez les résultats de l'analyse
N'instruisez pas les développeurs de corriger immédiatement toutes les vulnérabilités trouvées. Laissez l'agent de sécurité les vérifier en premier. Les résultats de la première analyse peuvent sembler déplorables: des dizaines de vulnérabilités critiques, des centaines de vulnérabilités moins critiques et des milliers de faux positifs. Que faire ici? Nous vous recommandons de corriger progressivement les vulnérabilités. Le but ultime est de parvenir à l'absence de vulnérabilités à la fois dans l'ancien code et dans le nouveau. Au stade initial, vérifiez les vulnérabilités critiques (toujours dangereuses pour elles) et nouvelles (le nouveau code est plus facile à corriger).
Utilisez des filtres. Trier les vulnérabilités par gravité, par langue, fichier et répertoire. Des outils plus avancés vous montreront les vulnérabilités uniquement dans le nouveau code, cacheront les vulnérabilités dans les bibliothèques tierces. Des filtres ont été appliqués, mais y a-t-il encore de nombreuses vulnérabilités?
Affichez les vulnérabilités les plus probables. Il existe des analyseurs qui évaluent la probabilité d'un faux positif. S'il existe de nombreuses vulnérabilités et que le niveau de criticité est presque le même pour tout le monde, filtrez les résultats à l'aide de cette métrique. Vous traitez donc rapidement les vulnérabilités les plus probables (voir capture d'écran ci-dessous).
Utilisez les états de vérification. Pour capturer les résultats de la vérification, les analyseurs proposent généralement de travailler avec des statuts pour la vulnérabilité: confirmer ou rejeter comme faux positif. En règle générale, le travail effectué doit être conservé lors de la nouvelle analyse.
Étape 3. Créez une demande de correction de vulnérabilité
Si le développeur commence l'analyse de son code et corrige immédiatement les vulnérabilités, vous n'avez bien sûr pas besoin de créer des requêtes inutiles.
Si le responsable de la sécurité examine et vérifie les résultats, alors pour la correction supplémentaire des vulnérabilités confirmées, il faut généralement définir une tâche. Nous avons été confrontés à plusieurs reprises au fait que c'est à ce stade que des difficultés sont apparues.
Formulaire de demandeIl existe des entreprises dans lesquelles les tâches importantes de la scène sont fixées dans le système de gestion de projet (par exemple, Jira). Et pour les sous-tâches et les bogues, par exemple, des problèmes GitLab sont utilisés, auxquels seuls le chef d'équipe et son équipe ont accès. Il arrive également que l'assemblage soit impossible sans créer une tâche distincte dans le système de gestion de projet. L'analyseur peut avoir des intégrations avec lesquelles vous pouvez créer immédiatement les requêtes nécessaires dans l'interface.
Souvent au sein d'une même entreprise avec de nombreux groupes de développement, chacun d'eux a sa propre procédure de mise en œuvre des tâches. Et vous devez vous adapter à tout le monde. Des questions se posent:
- Vaut-il la peine d'allouer un projet distinct pour corriger les vulnérabilités ou créer des tâches dans celles existantes?
- La vulnérabilité est-elle un bug familier ou une nouvelle entité?
- Créer une tâche distincte pour chaque vulnérabilité ou regrouper des tâches similaires?
- Que dois-je donner comme description du problème: un lien vers une vulnérabilité dans l'interface de l'analyseur ou une place dans le code et décrire brièvement le problème?
- Et le développeur a-t-il besoin d'accéder aux résultats - il suffit d'envoyer un rapport PDF avec le texte "voir page 257 "et ça suffit?
Bien sûr, cela dépend de la façon dont le processus dans l'équipe est ajusté, des systèmes de suivi des erreurs utilisés.
Si le code est écrit par des entrepreneurs pour lesquels l'accès aux systèmes internes est minimal, un schéma avec un rapport PDF convient. Généralement, vous pouvez sélectionner les vulnérabilités qui vous intéressent pour les rapports et les envoyer immédiatement à l'adresse souhaitée depuis l'interface de l'analyseur.
Si une entreprise ne peut pas faire une seule étape sans créer un projet pour un certain type de tâche avec une certaine quantité de ressources, alors vous devriez chercher un outil avec intégration pour votre système. Les intégrations les plus flexibles généreront une description de la tâche pour vous (elles n'oublieront même pas le lien vers le code source dans le système de contrôle de version) et vous permettront de remplir tous les champs obligatoires. Choisissez le type de tâche, spécifiez le parent, les artistes et même la version finale.
Coûts et conditions de travailSi l'équipe a décidé de donner une évaluation des coûts de main-d'œuvre pour chaque tâche, la tâche de correction de la vulnérabilité doit être effectuée de la même manière. En cours de route, les développeurs vérifient les vulnérabilités. Parfois, à cette étape, il s'avère que la vulnérabilité est fausse ou impossible à exploiter.
Mais en règle générale, les ressources ne sont toujours pas suffisantes pour corriger immédiatement toutes les vulnérabilités. Par conséquent, il est également nécessaire de coordonner leurs priorités.
Les tâches ont été déterminées par les coûts de main-d'œuvre et les priorités - puis les responsables des dates de sortie (il peut s'agir du chef de projet ou du même chef d'équipe) décident quoi réparer et quand. Dans un premier temps, en utilisant l'analyseur, nous vous conseillons de ne pas reporter la publication, si toutes les vulnérabilités ne sont pas corrigées.
Étape 4. Corrigez les vulnérabilités
Comment allouer correctement les ressources: connecter de nouvelles personnes ou confier à ceux qui sont déjà engagés dans le développement est une question budgétaire. Une chose est vraie: si l'entreprise alloue des ressources pour l'installation de l'analyseur, vous devez vous préparer aux coûts de correction des vulnérabilités. Un moyen possible est de fixer le pourcentage de temps pour corriger les vulnérabilités comme un travail avec une dette technique.
Il existe deux scénarios: corriger immédiatement dans le processus de développement ou à la demande d'un responsable de la sécurité. La correction des vulnérabilités pendant le développement est un scénario idéal. Immédiatement trouvé - immédiatement corrigé. Le développeur scanne sa branche de fonctionnalités avant de demander une fusion avec la branche principale. Cela peut également être automatisé grâce à des intégrations: avec l'environnement de développement, avec des outils de construction, un système de contrôle de version ou avec CI / CD.
Un autre scénario consiste à analyser la branche principale de développement après tous les changements. Un responsable de la sécurité ou un chef d'équipe examine les résultats et crée des tâches pour corriger les vulnérabilités. Ce scénario prend plus de temps. À l'entrée du développeur se trouve le code source, la tâche de correction et les résultats de l'analyse. Pour un développeur, la tâche de corriger une vulnérabilité n'est pas très différente de la correction d'un bogue.
Étape 5. Vérifiez le correctif
Vous devez vous assurer que la vulnérabilité est vraiment corrigée et qu'une nouvelle n'est pas apparue à sa place. Il y a des résultats de l'analyse du code corrigé. Que chercher? Fichier et numéro de ligne de la vulnérabilité? Ou rechercher par nom de vulnérabilité? C'est possible et ainsi. Mais si le code était modifié, la ligne avec la vulnérabilité pourrait changer, et il pourrait toujours y avoir de nombreuses occurrences d'une vulnérabilité. Certains analyseurs peuvent montrer des vulnérabilités «fixes». Acceptez, afin que vous puissiez vérifier le correctif de vulnérabilité plus rapidement (voir capture d'écran).
Des exemples
Voici deux scénarios possibles.
Scénario 1
L'équipe utilise Git pour le contrôle des versions, Jira pour la gestion des projets et des tâches. Jenkins configure le calendrier de construction. Par exemple, une fois par jour s'il y a des changements dans la branche. Comme étape supplémentaire, le démarrage de l'analyseur est indiqué.
Le responsable de la sécurité examine les résultats de l'analyse de la branche principale (maître ou développement) et les développeurs examinent ses branches de fonctionnalités.
Les développeurs corrigent les vulnérabilités si nécessaire. Si l'analyseur peut filtrer les vulnérabilités à la demande: afficher uniquement les nouvelles vulnérabilités ou ne pas afficher les vulnérabilités dans les bibliothèques tierces, afficher les vulnérabilités dans un répertoire ou un fichier spécifique - le développeur pourra afficher rapidement les résultats qui l'intéressent. Ainsi, la probabilité de correction est plus élevée.
L'agent de sécurité examine les résultats de l'analyse de la succursale principale. À l'aide de l'intégration avec Jira, le responsable de la sécurité crée des tâches de gestion des vulnérabilités à partir de l'interface de l'analyseur. Vient ensuite la coordination des délais et des priorités.
Lorsque la vulnérabilité est corrigée et que le nouveau code franchit toutes les étapes de développement internes (examen par le chef d'équipe, les utilisateurs et les tests de régression), le responsable de la sécurité doit s'assurer que la vulnérabilité n'existe plus. L'auteur ferme la tâche terminée.
Scénario 2
Le code de l'entreprise est rédigé par un groupe d'entrepreneurs. Timlid interagit avec les développeurs par e-mail et utilise GitLab pour le contrôle de version. Les contractants n'ont pas accès aux systèmes internes de gestion de projet (Jira).
Le responsable de la sécurité ou le chef d'équipe lui-même examine les résultats de l'analyse de la branche principale de développement. Les entrepreneurs n'ont pas accès à l'analyseur. S'il existe des vulnérabilités à corriger, le responsable de la sécurité envoie un rapport PDF avec les résultats de l'analyse au chef d'équipe ou immédiatement au développeur.
À partir du rapport, le développeur découvre où se trouve la vulnérabilité, en quoi elle consiste et comment elle peut être corrigée. Il est utile que pour les vulnérabilités liées au flux de données non sécurisées (par exemple, l'injection SQL), le schéma de distribution soit déchargé dans le rapport: de la source de données à leur utilisation dans l'appel de fonction / méthode (voir capture d'écran).
Après avoir corrigé la vulnérabilité, le chef d'équipe informe le responsable de la sécurité qu'il est temps de vérifier les résultats de la nouvelle analyse.
Quoi d'autre est important?
Établir l'interaction entre la sécurité de l'information et le développement. Il est important que les deux parties souhaitent corriger les vulnérabilités. Eh bien, si ce ne sera pas seulement des demandes, mais aussi une communication en direct.
Ne négligez pas les rôles d'utilisateur. Un bon analyseur devrait avoir la capacité de différencier les droits. Il est peu probable qu'un entrepreneur ait besoin de droits d'administrateur ou des résultats d'une analyse des systèmes internes. Pour modifier les résultats - pour changer la criticité et le statut - il suffit d'autoriser le responsable de la sécurité et le chef d'équipe. Le principe des privilèges minimaux n'a pas été annulé.
Si l'entreprise est grande et utilise un système de gestion des utilisateurs (par exemple, Active Directory), envisagez des outils avec une intégration prête à l'emploi. Vous pourrez réutiliser les rôles et les groupes acceptés dans l'entreprise et leur donner les droits nécessaires.
Conclusion
Après avoir choisi un analyseur, préparez-vous au fait qu'il doit encore être correctement implémenté. N'ayez pas peur des rencontres et de la coordination avec les participants: mieux vous comprenez dans le processus, plus le résultat est utile. Il est important que le scénario de travail soit non seulement approuvé, mais également commencé à suivre.
Publié par Elizaveta Kharlamova, Analyste principal, Solar appScreener