![Search icon](https://hackernoon.imgix.net/search-new.png?w=19&h=19)
Salut HackerNoon ! Je m'appelle Sofia et je suis ingénieur DevOps/Cloud. J'ai décidé de participer au concours de HackerNoon et Aptible.
Dans cet article, je parlerai des fonctionnalités du pipeline DevSecOps et du concept de Shift Left. Vous découvrirez les principales étapes du pipeline DevSecOps, les contrôles de sécurité automatisés dans le développement de logiciels et les outils gratuits et open source. Vous trouverez également des conseils pour vous aider à détecter les vulnérabilités plus tôt et à améliorer la sécurité des applications.
Cet article vous aidera à évaluer la maturité de votre pipeline DevSecOps, à élaborer une feuille de route pour son développement, à choisir les bons outils pour chaque tâche et à mieux comprendre comment gérer des projets selon la philosophie DevSecOps.
L'objectif principal de la méthodologie DevSecOps est d'introduire des contrôles de sécurité automatisés dans les pipelines DevOps, c'est-à-dire dans le processus de développement logiciel lui-même.
Il n'y a pas si longtemps, les spécialistes de la sécurité de l'information effectuaient des tests une fois le processus de développement terminé. Cette approche est inefficace : si des erreurs sont découvertes lors des tests de sécurité, tout le cycle de développement doit être redémarré. Cela prend du temps et coûte cher.
Regardez l'image ci-dessous. Vous pouvez constater que le coût de la correction des erreurs augmente à chaque étape.
Il ne coûte presque rien de résoudre les problèmes de sécurité découverts lors du développement et des tests fonctionnels. Toutes les modifications nécessaires peuvent être apportées immédiatement au code source et envoyées pour revérification.
La résolution des problèmes au stade de la construction de l’artefact coûte au moins deux fois plus cher. Vous devrez apporter des modifications au processus de construction, par exemple modifier le Dockerfile, ce qui signifie que vous aurez besoin de l'aide d'ingénieurs DevOps.
Si une erreur est détectée lors des tests d’intégration, sa correction coûtera 10 fois plus cher. Dans ce cas, vous devez relancer le cycle de développement et impliquer les développeurs, les ingénieurs DevOps et les testeurs.
Les problèmes de sécurité détectés lors de la phase de déploiement peuvent entraîner des fuites de données utilisateur. L'entreprise peut recevoir des millions de dollars d'amendes et nuire à sa réputation, ce qui signifie que le coût d'une erreur est multiplié par des centaines.
La principale conclusion est donc que les contrôles de sécurité doivent être effectués le plus tôt possible. Si vous le visualisez, déplacez-les vers la gauche du Pipeline. C’est le concept de Shift Left, dont les experts en sécurité aiment tant parler.
Les pipelines DevSecOps sont une chaîne automatisée de processus et d'outils qui créent, testent et fournissent des applications dans un environnement de production et les sécurisent à chaque étape.
L'image ci-dessus montre la structure du pipeline DevSecOps avec toutes les principales phases des contrôles de sécurité. Voici quelques mots sur chacun d’eux :
Examinons ensuite de plus près ce que sont ces contrôles et quels outils sont utilisés pour les effectuer.
Les vérifications préalables à la validation vous permettent d'analyser le code source sur la machine du développeur avant de valider les modifications dans la copie locale du référentiel. Si l'une des instructions renvoie une erreur, la validation n'est pas effectuée. Dans ce cas, le développeur doit corriger l’erreur et s’engager à nouveau.
Cette vérification évite la situation où du code non contrôlé, par exemple avec des secrets non chiffrés, pénètre dans le référentiel.
Pour effectuer des vérifications du code source avant la validation, il est nécessaire d'installer des outils sur les machines locales des développeurs. Cette approche présente non seulement des avantages mais aussi des inconvénients. Par exemple, les différences environnementales : différentes versions des instruments, différents systèmes d'exploitation et même architectures de processeurs.
Si les développeurs utilisent différentes versions d'outils de pré-validation, les résultats de la vérification seront différents, ce qui peut rendre difficile la collaboration. Tenez-en compte lors de la mise en œuvre de contrôles préalables à l'engagement au sein d'une équipe ou dans l'ensemble de l'entreprise.
De nombreux outils open source peuvent être utilisés pour configurer des vérifications préalables à la validation :
Ce sont d’excellents outils pour les vérifications préalables à la validation.
Dans la phase de pré-construction, des tests en boîte blanche sont effectués. Ces vérifications permettent d'analyser le code source, comme à l'étape précédente. Dans ce cas, l’application est une « boîte blanche » car on connaît et comprend son architecture et sa structure interne.
Il existe plusieurs types de vérifications préalables à la construction :
Maintenant, discutons-en en détail.
La détection secrète est une vérification automatisée qui détecte les informations sensibles non chiffrées : les secrets non chiffrés dans le code source qui ont pénétré dans un système de contrôle de version.
Les vérifications préalables à la construction sont effectuées une fois que le code source est entré dans le référentiel du système de contrôle de version. Par conséquent, toutes les données sensibles non chiffrées du stockage peuvent potentiellement être consultées par des attaquants, par exemple en cas de fuite du contenu du référentiel.
En outre, le processus de mise en œuvre des contrôles de détection de secrets peut ne pas avoir lieu à partir de zéro mais dans le cadre d'un projet en évolution. Dans ce cas, des secrets non chiffrés peuvent être trouvés dans d’anciens commits et différentes branches du référentiel.
Pour résoudre ces problèmes, nous devons faire de nombreuses choses différentes. Par exemple, nous devons nettoyer les référentiels des secrets non chiffrés ou mettre en œuvre divers outils de gestion des secrets comme Hashicorp Vault .
La détection secrète peut être configurée à l'aide de
Les tests de sécurité des applications statiques (SAST) sont un test dans lequel les analyseurs ne se contentent pas de vérifier l'exactitude syntaxique, mais mesurent également la qualité du code à l'aide de métriques uniques. La tâche principale des scanners SAST est de tester la sécurité.
En particulier, les analyseurs SAST contiennent le code source des vulnérabilités courantes, par exemple certaines des
L'analyse SAST est appelée White Box Testing car l'analyseur peut accéder à la structure interne de l'application. Il est important de noter que les analyseurs vérifient le code source sans l'exécuter, ils peuvent donc générer des faux positifs et ne pas détecter certaines vulnérabilités.
Pour cette raison, vous ne devez pas vous limiter uniquement à l’analyse SAST. Il est préférable d'aborder la question de manière globale et d'utiliser différents types d'analyses : SCA, DAST, IAST et OAST.
Solutions propriétaires :
La solution gratuite est GitLab SAST.
Software Composition Analysis (SCA) est une méthodologie qui sécurise les applications en analysant leurs composants open source.
Les scanners SCA recherchent les dépendances obsolètes contenant des vulnérabilités et des exploits connus. De plus, certains outils SCA peuvent déterminer la compatibilité des licences des composants et les risques de violation de licence.
Source SCA analyse le code source et, plus particulièrement, les dépendances applicatives définies dans le code source. Cette analyse est souvent appelée analyse des dépendances.
SCA vous permet de détecter un problème dans lequel une vulnérabilité dans un composant peut entraîner des problèmes de sécurité dans toutes les applications.
Un bon exemple est
Solution commerciale avec plans tarifaires gratuits :
Dans le cadre de GitLab (disponible dans la version Ultimate uniquement), vous pouvez utiliser
La phase de post-construction intervient après la création des artefacts à partir du code source dans le pipeline CI : une image Docker, un package RPM ou une archive JAR. Grâce aux vérifications post-build, vous pouvez analyser les dépendances de ces artefacts binaires.
L'analyse SCA binaire implique l'inspection des artefacts binaires tels que les images Docker, les packages RPM et les archives JAR/WAR/EAR. Il est également souvent appelé « Container Scanning ». Il est logique de l'exécuter lorsque les artefacts binaires sont construits, c'est-à-dire pas avant l'étape post-construction.
Il existe des fonctionnalités intéressantes lorsque vous travaillez avec des images Docker. Les analyseurs binaires SCA vérifient les couches d'images Docker et les recherchent sous forme de sommes de hachage dans les bases de données publiques de vulnérabilités telles que
Certains analyseurs peuvent non seulement trouver des composants vulnérables, mais également suggérer un correctif, par exemple en spécifiant la version minimale requise d'un composant présentant une vulnérabilité déjà corrigée.
La solution gratuite est
Solutions open source :
Docker Registry avec analyseurs intégrés -
À ce stade, des tests dynamiques de la boîte grise et des tests de la boîte noire sont effectués. Lorsque la structure interne de l'application est partiellement ou totalement inconnue, ces contrôles de sécurité sont effectués en émulant les actions d'un attaquant qui découvre des vulnérabilités et tente de « casser » l'application en les exploitant. Discutons brièvement de chacun d'eux : DAST, IAST et OAST.
Les scanners DAST testent automatiquement les applications en simulant des attaques externes via diverses vulnérabilités. L'application est une boîte noire pour l'analyseur ; on n'en sait rien.
Pour les contrôles DAST, il est nécessaire de disposer d’une instance en cours d’exécution de l’application disponible pour le scanner. De plus, plus les paramètres de l’instance de test de l’application sont proches de l’installation de production, moins il y aura de faux positifs.
Par exemple, supposons que vous ayez déployé une instance d'application de test accessible uniquement via le protocole HTTP, mais qu'en production, l'application est accessible uniquement via le protocole HTTP.
Dans ce cas, le scanner DAST générera des erreurs liées au manque de cryptage du trafic entre le client (analyseur) et le serveur (instance d'application).
Outils qui méritent votre attention :
Super, continuez.
IAST (Interactive Application Security Testing) est un test en boîte grise qui combine les avantages et les points forts du test en boîte blanche SAST et du test en boîte noire DAST.
Pour rassembler tous les avantages et éliminer les inconvénients des méthodes SAST et DAST, les développeurs ont inventé IAST, un mécanisme hybride combinant ces méthodes. Il augmente la précision des tests dynamiques car il donne plus d'informations sur le fonctionnement de l'application grâce à l'analyse du code.
Il convient de rappeler qu’outre ses avantages, l’IAST présente des limites. Le plus fondamental est la dépendance à l’égard de la langue dans laquelle l’application testée est écrite. Les solutions IAST fonctionnent au niveau de l'application et nécessitent un accès au code exécutable pour analyser son comportement.
Cela signifie que les solutions IAST doivent être capables de comprendre le langage de programmation dans lequel l'application est écrite. Il convient de noter que la prise en charge d'une solution IAST particulière peut être mieux implémentée pour certaines langues que pour d'autres.
L'analyse IAST prend également beaucoup de temps. Cela dépend de nombreux facteurs, tels que la taille et la complexité de l'application, le nombre de dépendances externes et les performances de l'outil IAST utilisé.
De plus, le processus d'analyse n'analyse pas le code lui-même mais vérifie uniquement les fragments directement exécutés. Par conséquent, il est préférable de combiner l’analyse IAST avec des tests fonctionnels lorsque vous pouvez tester autant de scénarios d’application que possible.
Voici d'excellents outils pour vous :
Super, continuez.
OAST (Out-of-band Application Security Testing) est une technique développée par
Je te recommande:
Passez.
Il s’agit d’une étape essentielle pour garantir la sécurité et l’opérabilité des applications. Contrairement aux vérifications préalables à la validation, qui sont effectuées au stade du développement, les vérifications post-déploiement vous permettent d'identifier d'éventuels problèmes dès le fonctionnement de l'application dans l'environnement naturel.
Pour détecter de nouvelles vulnérabilités à temps, il est nécessaire d'effectuer des contrôles réguliers des artefacts, y compris après le déploiement d'une application.
Cela peut être fait à l'aide de référentiels ou d'outils spéciaux, tels que
Une autre façon de garantir la sécurité consiste à surveiller l’application elle-même. Il existe plusieurs technologies disponibles à cet effet :
Le principal avantage de RASP par rapport à WAF est qu'il comprend le fonctionnement de l'application et détecte les attaques et le trafic illégitime. RASP peut détecter non seulement les attaques typiques utilisant la correspondance de signatures, mais également les tentatives d'exploiter les vulnérabilités du jour zéro en réagissant aux anomalies.
Contrairement à WAF, RASP fonctionne au sein et avec l'application. WAF peut être trompé. Si un attaquant modifie le code de l'application, WAF ne peut pas le détecter car il ne comprend pas le contexte d'exécution.
RASP a accès aux informations de diagnostic sur l'application, peut les analyser, détecter les anomalies et bloquer les attaques.
La technologie RASP a pour spécialité de se concentrer sur la prévention des attaques par défaut. Le système ne nécessite pas d'accès au code source.
Je te recommande:
Super, continuez.
À différentes étapes du Pipeline, j'utilise de nombreux analyseurs de tests de sécurité des applications/DevSecOps. Chacun d’eux génère un rapport dans son propre format, et certains génèrent des faux positifs. De ce fait, il n’est pas facile d’analyser la sécurité d’une application dans son ensemble.
Pour analyser efficacement les vulnérabilités et gérer le processus de remédiation, des outils spécialisés de gestion des vulnérabilités, souvent appelés simplement tableaux de bord de sécurité , sont utilisés.
Les tableaux de bord de sécurité résolvent le problème en fournissant les résultats des analyses DevSecOps sous une forme unifiée et facile à analyser. De cette manière, les ingénieurs en sécurité peuvent identifier les problèmes existants, ceux qui sont les plus critiques et ceux qui doivent être résolus en premier.
Un large éventail d'outils est généralement utilisé comme tableaux de bord de sécurité : par exemple, les systèmes SOAR/SIEM classiques et l'orchestrateur spécialisé DevSecOps AppSec.Hub de Swordfish Security ou la boîte à outils open source de gestion des vulnérabilités DefectDojo.
DefectDojo est un outil répandu. Il est largement utilisé même dans les entreprises. Cependant, malgré sa popularité et son âge avancé, cet outil présente parfois des défauts de niveau initial lorsque les contributeurs brisent les fonctionnalités de base du commit.
Cependant, ce qui est bien, c'est que les développeurs et les responsables de DefectDojo aident à résoudre les complexités. Les développeurs de DefectDojo sont des personnes très réactives - nous vous recommandons de les contacter directement via Issues sur GitHub.
Encore une fois, voici un bref récapitulatif de ce qu’il y avait dans l’article.
J'ai expliqué ce qu'est le concept Shift Left et comment il contribue à réduire le coût des corrections de bugs et le temps de développement : plus tôt dans le processus de développement vous démarrez les contrôles de sécurité, mieux c'est.
Ensuite, j'ai déconstruit la structure du Pipeline DevSecOps et examiné quels contrôles de sécurité sont effectués à chaque étape du Pipeline :
Vous comprenez désormais comment fonctionne le pipeline DevSecOps. Vous pouvez désormais évaluer la maturité de vos pipelines DevSecOps, élaborer une feuille de route pour son développement et choisir les bons outils pour chaque tâche.