DevSecOps pour les programmes de défense : la sécurité à chaque sprint

Le DevSecOps — l'intégration des pratiques de sécurité à chaque étape du cycle de développement logiciel — est la réponse des programmes de défense à la reconnaissance que les approches de sécurité traditionnelles avec test en fin de cycle ne suivent pas les rythmes modernes de livraison logicielle. Lorsque les tests de sécurité n'ont lieu qu'avant la mise en production, corriger les vulnérabilités est coûteux et retarde la livraison ; lorsqu'ils sont intégrés dans le pipeline CI/CD, les vulnérabilités sont découvertes près de leur point d'introduction, quand le contexte est frais et la correction relativement peu coûteuse.

Les programmes de défense ont des exigences supplémentaires par rapport au DevSecOps commercial : conformité aux STIG (Security Technical Implementation Guides), pistes d'audit pour les autorités d'accréditation, gestion des secrets pour les systèmes classifiés, et exigences strictes d'intégrité de la chaîne d'approvisionnement pour les artefacts de code déployés dans des systèmes critiques. Ces exigences modifient la configuration et les priorités du pipeline DevSecOps, mais pas l'architecture de base. L'ANSSI et la DGA ont toutes deux publié des cadres de développement logiciel sécurisé qui reconnaissent DevSecOps comme bonne pratique pour les logiciels de défense.

Analyse statique du code : Semgrep et outils SAST

SAST (Static Application Security Testing) analyse le code source ou le bytecode sans l'exécuter, détectant les vulnérabilités potentielles via l'analyse du flux de données, la vérification de configuration et la correspondance de motifs. Semgrep est le standard de facto pour le SAST léger dans les pipelines DevSecOps : il prend en charge plus de 30 langages de programmation, s'exécute en secondes sur des bases de code typiques et peut être personnalisé pour des motifs de sécurité spécifiques aux programmes de défense — secrets codés en dur, primitives cryptographiques non sécurisées, désérialisation non sécurisée.

Semgrep permet la définition de règles avec une syntaxe YAML simple, permettant aux équipes de sécurité de codifier des motifs de sécurité spécifiques au domaine. Pour les programmes de défense, cela inclut des règles spécifiques au domaine : vérification du chiffrement des données classifiées, détection de connexions réseau non sécurisées dans le contexte de systèmes classifiés, et détection de motifs d'accès aux données violant les règles de contrôle d'accès obligatoire (MAC).

Tests dynamiques : OWASP ZAP et DAST dans le pipeline

DAST (Dynamic Application Security Testing) teste les applications en cours d'exécution en envoyant des entrées malveillantes et en observant le comportement, découvrant les vulnérabilités qui émergent des interactions entre composants. OWASP ZAP (Zed Attack Proxy) est l'outil DAST open source standard pour l'intégration dans les pipelines CI/CD. ZAP en mode daemon fournit une API REST qui permet aux pipelines de lancer des scans automatisés, de récupérer des rapports et de sortir avec un code non nul pour les résultats dépassant les seuils.

Pour les applications de défense, les scans DAST doivent couvrir les vecteurs d'attaque spécifiques à la défense : vulnérabilités d'authentification dans les systèmes avec contrôle d'accès obligatoire, injection SQL dans les bases de données de données opérationnelles, vulnérabilités de gestion des sessions dans les systèmes avec plusieurs niveaux de classification.

Analyse des composants : SCA et détection des vulnérabilités

SCA (Software Composition Analysis) identifie les vulnérabilités connues dans les dépendances tierces. Grype et Trivy sont des outils SCA standard dans les pipelines DevSecOps : ils analysent les paquets de dépendances (Maven, npm, pip, modules Go) et les images de conteneurs par rapport aux bases de données de vulnérabilités (NVD, GitHub Advisory Database, bases de données d'avis de distribution).

Pour les programmes de défense, le SCA est particulièrement important pour deux raisons : les composants tiers sont la source la plus courante de vulnérabilités dans les bases de code matures, et les exigences de la chaîne d'approvisionnement des programmes de défense (EO 14028, exigences SBOM) nécessitent un inventaire complet et une documentation des composants tiers.

Détection des secrets : Gitleaks et protection pre-commit

Les secrets — clés API, mots de passe, certificats, jetons — qui pénètrent dans les dépôts de code source constituent l'une des violations de sécurité les plus courantes et les plus impactantes. Gitleaks et detect-secrets sont des outils standard de scan de secrets dans les pipelines DevSecOps : ils analysent les dépôts git (y compris l'historique git) à la recherche de motifs correspondant aux formats de secrets connus. Les hooks pre-commit qui exécutent Gitleaks offrent la première barrière de protection, empêchant les commits contenant des secrets détectés.

Sécurité des conteneurs : signature des images et registre

Les images de conteneurs déployées dans les systèmes de défense doivent être vérifiées pour leur intégrité. Cosign (du projet Sigstore) fournit la signature et la vérification des images de conteneurs : le pipeline de build signe l'image avec une clé cryptographique après avoir réussi toutes les vérifications de sécurité ; un webhook d'admission Kubernetes vérifie la signature avant d'autoriser le déploiement de l'image. Harbor est le registre de conteneurs standard pour les déploiements de défense sécurisés et isolés : il fournit un contrôle d'accès, des journaux d'audit, un scan de vulnérabilités intégré (via Trivy) et une prise en charge de la signature de contenu.

Conformité STIG : automatisation de la vérification

Les STIG (Security Technical Implementation Guides), publiés par DISA, définissent des exigences techniques spécifiques de configuration de sécurité pour les systèmes du Département de la Défense. OpenSCAP fournit une vérification automatisée de la conformité STIG : il compare les configurations des systèmes aux spécifications STIG (au format XCCDF/OVAL) et génère des rapports de conformité identifiant les résultats de Catégorie I (critiques), II (moyens) et III (faibles). Pour les pipelines CI/CD, les vérifications de conformité STIG peuvent être automatisées dans le cadre de la build de l'image de conteneur.