DevSecOps : intégrer des contrôles utiles dans la CI/CD

Ajouter plusieurs scanners à une pipeline ne suffit pas à sécuriser un logiciel. Si chaque alerte bloque sans contexte, l'équipe finit par contourner le contrôle. Si rien ne bloque, le tableau devient une archive.

Le Secure Software Development Framework du NIST couvre préparation, protection du logiciel, production sécurisée et réponse aux vulnérabilités. La CI/CD est une partie de ce système, pas son unique défense.

Définir les décisions

Écrivez les règles avant les outils : branches protégées, revues requises, résultats bloquants et personne autorisée à accepter un risque. Une exception doit avoir un responsable, une justification et une date de révision. Une faille exploitable dans un composant exposé ne se traite pas comme un résultat incertain dans du code non livré.

Installer des contrôles progressifs

Avant le push, cherchez les secrets et lancez les vérifications rapides. Sur la pull request, exécutez tests, analyse statique et revue des dépendances. La dependency review de GitHub compare les changements et peut bloquer l'introduction d'une dépendance vulnérable selon la politique choisie.

Après le build, inspectez l'artefact réellement déployable : image, paquets, configuration et infrastructure as code. Gardez l'identité de la source, du commit et du processus. Le cadre SLSA fournit un vocabulaire pour l'intégrité et la provenance ; choisissez les garanties adaptées au risque.

Avant production, contrôlez permissions, secrets, exposition réseau et politique de déploiement. Après livraison, surveillez les nouvelles vulnérabilités et préparez rotation ou retrait.

Réduire le bruit et protéger la pipeline

Attribuez les résultats, dédupliquez-les et séparez découverte, validation et correction. Suivez le délai de correction, les exceptions expirées et les contrôles contournés. Commencez par secrets, dépendances nouvelles, défauts critiques confirmés et protection du pipeline.

La pipeline accède au code, aux jetons et parfois à la production. Limitez les permissions des runners, séparez les environnements et contrôlez actions ou images tierces. Un bon scanner dans un workflow modifiable par tous n'apporte pas la garantie attendue.

Le résultat recherché est une décision claire au bon moment, avec une voie de correction et une trace lorsque le risque est accepté.

Sources officielles

• NIST SP 800-218, février 2022.
• Dependency review, GitHub, consulté le 7 septembre 2026.
• SLSA v1.2, consulté le 7 septembre 2026.