DevSecOps : intégrer la sécurité en amont dans les pipelines

Déplacer la sécurité vers la gauche signifie intégrer les activités de sécurité plus tôt dans le cycle de vie du développement logiciel, dans l’IDE du développeur, la Review de code et le pipeline CI/CD, plutôt que de tester la sécurité comme barrière finale avant le déploiement. Les Reviews de sécurité traditionnelles avaient lieu à la fin du cycle de développement, ce qui rendait les corrections coûteuses et chronophages. La détection d’une vulnérabilité pendant le développement coûte environ 100 fois moins cher à corriger que sa découverte en production après une compromission.

DevSecOps étend le modèle DevOps en intégrant la sécurité comme une responsabilité partagée entre les équipes de développement, d’exploitation et de sécurité pendant tout le SDLC. L’objectif est d’automatiser les tests de sécurité afin qu’ils s’exécutent à chaque étape sans ralentir la livraison. La sécurité devient une propriété continue du pipeline plutôt qu’un contrôle ponctuel. Dans les programmes DevSecOps matures, les développeurs reçoivent un retour sur la sécurité quelques secondes après avoir écrit leur code, et non plusieurs semaines après une revue manuelle.

SAST (Static Application Security Testing) analyse le code source, le bytecode ou le binaire sans exécuter l’application. Les outils SAST recherchent des motifs indiquant des vulnérabilités : concaténation SQL, sortie non nettoyée, utilisation de fonctions interdites, identifiants d’accès codés en dur et utilisation non sécurisée de la cryptographie. Le SAST s’exécute dans le pipeline d’intégration continue à chaque validation, ce qui permet de détecter les problèmes avant leur arrivée en QA ou en production. Parmi les outils courants figurent Semgrep, SonarQube, Checkmarx et Veracode.

DAST (Dynamic Application Security Testing) teste une application en fonctionnement en lui envoyant des charges malveillantes et en observant ses réponses : il simule ainsi le comportement réel d’un attaquant. Contrairement au SAST, le DAST détecte les vulnérabilités qui n’apparaissent qu’à l’exécution : défauts d’authentification, problèmes de gestion des sessions, bogues de logique métier et vulnérabilités par injection dans des flux de données complexes. Parmi les outils DAST courants figurent OWASP ZAP (gratuit), Burp Suite Enterprise et Acunetix. Le DAST s’exécute sur un environnement de préproduction dans le pipeline.

Les images de conteneurs sont créées à partir d’images de base contenant des paquets du système d’exploitation, des environnements d’exécution de langages et des dépendances d’application : autant de sources potentielles de vulnérabilités connues. Les outils d’analyse des images de conteneurs examinent les couches des images et identifient les paquets vulnérables. Trivy (gratuit et rapide), Grype (Anchore) et Clair sont largement utilisés. Les analyses s’exécutent dans le cadre du pipeline de création des images et empêchent la promotion vers les registres de production des images présentant des CVE critiques.

L’analyse de sécurité de l’IaC examine Terraform, CloudFormation, les manifestes Kubernetes et les graphiques Helm afin de détecter les erreurs de configuration de sécurité avant leur application. Des outils comme Checkov et tfsec recherchent notamment les violations suivantes : des compartiments S3 sans chiffrement côté serveur, des groupes de sécurité autorisant tout le trafic entrant, des rôles IAM dotés d’autorisations génériques et des pods Kubernetes s’exécutant avec les privilèges root. L’analyse de l’IaC empêche les erreurs de configuration du cloud d’atteindre quelque environnement que ce soit.

Les outils d’analyse des secrets vérifient le code source et les validations afin de repérer les identifiants d’accès inclus accidentellement. Des outils comme truffleHog, GitLeaks et detect-secrets analysent l’historique git et les nouvelles validations à la recherche de motifs correspondant à des clés d’API, des chaînes de connexion, des clés privées et des jetons JWT. En tant que crochet de prévalidation, l’analyse des secrets bloque les validations qui contiennent des identifiants d’accès. En tant que contrôle du CI, elle analyse tous les fichiers du dépôt à chaque envoi et fait échouer la compilation si des secrets sont détectés.

La modélisation des menaces est un processus structuré visant à identifier les exigences de sécurité et les défauts de conception avant l’écriture du code. Le modèle STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial de Service, Elevation de Privilege) aide les équipes à énumérer systématiquement les menaces pesant sur le diagramme de flux des données d’un système. Les séances de modélisation des menaces ont lieu pendant la conception et produisent une liste hiérarchisée de menaces qui orientent les exigences de sécurité et le choix des règles SAST/DAST.

Les pipelines DevSecOps mettent en œuvre les contrôles de sécurité sous forme de contrôles bloquants (la compilation échoue et le déploiement est empêché) ou de contrôles de recommandation (les résultats sont signalés et le déploiement peut se poursuivre). Les résultats de gravité critique et élevée issus du SAST, de l’analyse des conteneurs et de la détection des secrets bloquent généralement le processus. Les résultats de gravité moyenne ou faible génèrent des notifications ou des tickets sans bloquer le processus. Cet équilibre empêche la sécurité d’arrêter toutes les livraisons, tout en garantissant que les conditions réellement dangereuses ne puissent pas atteindre automatiquement la production.

Les programmes DevSecOps doivent être évalués à l’aide d’indicateurs clairs. Parmi les indicateurs essentiels figurent : le Mean Time to Remediate (MTTR) des résultats de gravité élevée, la densité de vulnérabilités (nombre de résultats pour 1 000 lignes de code au fil du temps), le taux d’échappement (pourcentage de vulnérabilités découvertes après la mise en production par rapport à celles découvertes avant) et le taux de réussite des contrôles de sécurité du pipeline. Le suivi de ces indicateurs au fil du temps démontre l’efficacité du programme et oriente les décisions d’investissement dans des outils ou des formations supplémentaires.

La partie la plus difficile du DevSecOps est culturelle, et non technique. La sécurité doit devenir la responsabilité de chaque développeur, et non celle de la seule équipe de sécurité. Cela nécessite : une formation des développeurs à la sécurité (sensibilisation au codage sécurisé), des référents sécurité intégrés aux équipes de développement, des analyses rétrospectives sans recherche de coupable lorsque des vulnérabilités atteignent la production (en privilégiant l’amélioration des processus plutôt que la sanction) et un engagement de la direction à accepter des compromis sur la rapidité lorsque le risque réel pour la sécurité l’exige. La technologie sans évolution de la culture produit des outils d’analyse que les développeurs finissent par ignorer.

Évaluez votre compréhension des notions de CompTIA Security+ (SY0-701) abordées dans cette leçon.

Dans cette leçon, vous avez appris que le DevSecOps intègre le SAST, le DAST, l’analyse des secrets, l’analyse des conteneurs et l’analyse de l’IaC comme contrôles automatisés du pipeline, que le blocage des résultats de gravité élevée empêche les conditions dangereuses d’atteindre la production et que le déplacement de la sécurité vers la gauche réduit considérablement les coûts de correction en détectant les vulnérabilités pendant le développement plutôt qu’après le déploiement. Nous allons maintenant étudier les contrôles de sécurité physique des installations et des centres de données.