Jan 01, 1970
Comment transformer un pipeline DevOps en pipeline DevSecOps : un aperçu du concept Shift Left par@goal23
11,146 lectures
Comment transformer un pipeline DevOps en pipeline DevSecOps : un aperçu du concept Shift Left
Trop long; Pour lire
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.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.
Concept de décalage vers la gauche
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.
Structure du pipeline DevSecOps
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 :
- Pré-engagement. Cela implique de vérifier la sécurité du code source avant que le développeur ne valide le code dans le système de contrôle de version. Cette vérification permet de détecter des informations confidentielles non chiffrées telles que des mots de passe ou des clés API.
- Pré-construction. Cela implique de vérifier la sécurité du code source après son entrée dans le système de contrôle de version. Les outils effectuent une analyse statique du code source et de ses dépendances pour détecter les vulnérabilités courantes, telles que la plupart des
OWASP Top 10 liste.
- Post-construction. Il s'agit du contrôle de sécurité d'un artefact construit à partir du code source, tel qu'un fichier Docker, un package RPM ou une archive JAR. Les outils analysent l'environnement de l'application et ses dépendances, trouvant des versions obsolètes de packages et de bibliothèques qui contiennent déjà des correctifs dans des versions plus récentes.
- Temps de test. Cela implique de tester la sécurité d’une application exécutée à partir d’un artefact collecté. Les outils de cette phase tentent de « casser » l'application en simulant les actions des attaquants.
- Post-déploiement. Cela implique de vérifier la sécurité d'une application après son déploiement dans un environnement de production. Les outils surveillent les registres ouverts des vulnérabilités connues en temps réel et avertissent lorsqu'une menace pour l'application est détectée.
Examinons ensuite de plus près ce que sont ces contrôles et quels outils sont utilisés pour les effectuer.
Vérifications préalables à l'engagement
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.
Outils pour les vérifications préalables à l'engagement
De nombreux outils open source peuvent être utilisés pour configurer des vérifications préalables à la validation :
Gitleaks git-secrets Analyse secrète Trivy Chuchotements git-tous-secrets détecter les secrets fuites dégueulasses
Ce sont d’excellents outils pour les vérifications préalables à la validation.
Vérifications préalables à la construction
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 :
- Détection secrète
- Tests de sécurité des applications statiques (SAST)
- Analyse de la composition logicielle (SCA)
Maintenant, discutons-en en détail.
Vérification de la détection des secrets avant la construction
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 .
Outils de détection des secrets
La détection secrète peut être configurée à l'aide de
Vérification SAST avant la construction
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.
Outils SAST
Solutions propriétaires :
La solution gratuite est GitLab SAST.
Vérification SCA source avant la construction
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
Outils SCA
Solution commerciale avec plans tarifaires gratuits :
Dans le cadre de GitLab (disponible dans la version Ultimate uniquement), vous pouvez utiliser
Vérifications post-construction : SCA binaire
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.
Exemples d'analyseurs SCA binaires populaires
La solution gratuite est
Solutions open source :
Docker Registry avec analyseurs intégrés -
Vérifications au moment du test : DAST, IAST et OAST
À 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.
Vérification DAST au moment du test
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).
Exemples d'outils DAST
Outils qui méritent votre attention :
GitLabDAST — uniquement disponible dans la version UltimateProxy d'attaque OWASP Zed (ZAP) — une solution open source, également utilisée dans GitLab DAST- Acunetix
- Fortifier WebInspect
- AppScan de sécurité HCL
- DAST géré par Synopsys
Tenable.io (Analyse d'applications Web)- Analyse dynamique Veracode
Super, continuez.
Vérification IAST au moment du test
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.
Exemples d'outils IAST
Voici d'excellents outils pour vous :
Chercheur de synopsis Analyse interactive Veracode Microfocus Fortify WebInspect Checkmarx CxIAST Évaluation du contraste Détection Hdiv (IAST)
Super, continuez.
Vérification OAST au moment du test
OAST (Out-of-band Application Security Testing) est une technique développée par
Exemples d'outils OAST
Je te recommande:
Suite Rots - OWASP ZAP avec
Plugin OAST - Services OAST
SE VANTER ,TukTuk , etinteragir
Passez.
Vérifications post-déploiement
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.
Surveillance de la sécurité des artefacts
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
Surveillance de la sécurité des applications
Une autre façon de garantir la sécurité consiste à surveiller l’application elle-même. Il existe plusieurs technologies disponibles à cet effet :
- Le pare-feu d'application Web (WAF) est un outil de filtrage du trafic. Il fonctionne au niveau de la couche application et protège les applications Web en analysant le trafic HTTP/HTTPS.
- RASP (Runtime Application Self-Protection) est une technologie qui détecte et bloque les attaques sur une application en temps réel. Il ajoute une fonction de défense à l'environnement d'exécution, permettant à l'application de s'auto-protéger automatiquement.
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.
Les imbéciles RASP
Je te recommande:
Fortifier Écran carré OuvrirRASP est une solution open source développée par BaiduSciences du signal Jscrambler Hdiv Imperva
Super, continuez.
Visualisation des résultats des pipelines DevSecOps et gestion des vulnérabilités
À 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.
Outils DevSecOps
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.
Concept Shift Left : résumons
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 :
- Pré-engagement. Cela implique de vérifier la sécurité du code source avant qu'il n'entre dans le système de contrôle de version.
- Pré-construction. Il s'agit d'une vérification de la sécurité du code source dans le système de contrôle de version (Secret Detection, SAST, SCA).
- Post-construction. Il s'agit d'un contrôle de sécurité d'un artefact construit à partir du code source (Source SCA, Binary SCA).
- Temps de test. Cela implique de tester la sécurité de l'application qui s'exécute à partir de l'artefact collecté (DAST, IAST et OAST).
- Post-déploiement. Cela implique de vérifier la sécurité des applications après leur déploiement dans l'environnement de production (WAF, RASP).
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.
L O A D I N G
. . . comments & more!
. . . comments & more!
