L’intégration de la sécurité dans les pipelines d’intégration et de livraison continues n’est plus une option pour les organisations soumises à NIS2 ou au Cyber Resilience Act. Le modèle DevSecOps formalise cette convergence entre les équipes de développement, de sécurité et d’exploitation, en automatisant les contrôles de sécurité à chaque étape du cycle de vie logiciel. Pour un DSI ou un RSSI, l’enjeu est double : réduire la dette technique sécurité accumulée dans les pipelines existants, et construire un référentiel de pratiques reproductibles et auditables.
Pourquoi le modèle traditionnel est dépassé
Pendant longtemps, la sécurité applicative s’exerçait en fin de cycle : un audit de code ou un test d’intrusion réalisé juste avant la mise en production. Ce modèle présente deux défauts structurels. D’abord, le coût de remédiation croît exponentiellement avec la distance entre la détection et l’introduction de la vulnérabilité. Les études sectorielles menées par IBM et Capers Jones, reprises par le NIST dans sa publication SP 800-218 (Secure Software Development Framework, SSDF), établissent cet écart : corriger un défaut en phase de conception coûte en moyenne 6 fois moins qu’en phase de test, et jusqu’à 100 fois moins qu’après déploiement. Ensuite, la cadence de livraison des équipes modernes, souvent pluriquotidienne, rend caduque toute revue manuelle systématique.
Le shift left désigne précisément ce déplacement des contrôles vers les phases amont : dès l’écriture du code, lors de la pull request, et au plus tard lors de l’intégration continue. Cette philosophie ne supprime pas les audits en aval, mais en réduit drastiquement le volume et la sévérité.
Les composantes techniques d’un pipeline DevSecOps
Un pipeline CI/CD sécurisé repose sur plusieurs catégories d’outils complémentaires, positionnés à des moments précis du workflow.
| Catégorie | Positionnement | Exemples d’outils open source |
|---|---|---|
| Pre-commit hooks | Poste développeur | git-secrets, detect-secrets, GitLeaks |
| SAST (Static Analysis) | Pull request / CI | Semgrep, SonarQube Community, Bandit (Python) |
| SCA (Software Composition Analysis) | CI | Dependency-Track, OWASP Dependency-Check, Trivy |
| Secret scanning | CI | TruffleHog, GitLeaks CI mode |
| Container image scanning | CI / registry | Trivy, Grype, Clair |
| DAST (Dynamic Analysis) | Staging | OWASP ZAP, Nuclei |
| Infrastructure as Code (IaC) scanning | CI | Checkov, Trivy (inclut tfsec), kics |
| SBOM generation | CI / release | Syft, CycloneDX |
SAST et SCA : les deux piliers du contrôle en amont. Le SAST analyse le code source sans l’exécuter, à la recherche de patterns connus (injections SQL, désérialisation non sécurisée, gestion incorrecte des erreurs). Semgrep, par exemple, permet d’écrire des règles métier spécifiques à la base de code, en complément des règles communautaires. Le SCA, ou analyse de composition logicielle, inventorie les bibliothèques tierces et les compare aux bases CVE (NVD, OSV). Il détecte les composants affectés par des vulnérabilités connues et référencées, à condition que la CVE soit enregistrée au moment du scan.
Le scan d’images de conteneurs est incontournable dans les architectures cloud-native. Trivy, maintenu par Aqua Security et intégré nativement dans GitHub Actions et GitLab CI, analyse les layers Docker à la recherche de CVE et de mauvaises configurations dans les manifestes Kubernetes ou Helm.
L’IaC scanning cible les fichiers Terraform, CloudFormation, Bicep et les configurations Kubernetes. Des outils comme Checkov ou Trivy (qui intègre désormais les contrôles de l’ancien tfsec, absorbé en 2024) détectent les buckets S3 ouverts, les groupes de sécurité trop permissifs, ou l’absence de chiffrement des volumes, avant que l’infrastructure ne soit provisionnée.
Gestion des secrets : le vecteur d’attaque le plus sous-estimé
La fuite de secrets (clés API, tokens OAuth, certificats, mots de passe de bases de données) dans les dépôts de code constitue l’un des vecteurs d’intrusion les plus fréquents et les plus facilement exploitables. GitHub a détecté en 2023 plus de 1 milliard de secrets exposés dans les dépôts publics, selon son rapport annuel sur la sécurité de l’open source.
La stratégie de protection se déploie sur trois niveaux :
- Prévention : hooks pre-commit locaux (GitLeaks, detect-secrets) qui bloquent le commit si un pattern de secret est détecté, et formation des développeurs aux bonnes pratiques (variables d’environnement, fichiers
.envdans le.gitignore). - Détection : scan automatique dans le pipeline CI et surveillance continue du dépôt via des outils comme GitHub Advanced Security Secret Scanning ou TruffleHog Enterprise.
- Remédiation : en cas de détection, rotation immédiate du secret compromis, audit des journaux d’accès pour évaluer l’exposition, et invalidation de l’historique git si nécessaire (via
git filter-repo).
Les gestionnaires de secrets centralisés (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) permettent d’injecter les secrets à l’exécution du pipeline sans les stocker dans le système de gestion de configuration. L’accès est contrôlé par des politiques granulaires et chaque accès est journalisé, facilitant les audits de conformité.
Sécuriser la supply chain logicielle
L’attaque SolarWinds (2020), qui a compromis le serveur de build d’Orion pour distribuer une backdoor dans des milliers d’organisations, a redéfini la perception des risques liés à la chaîne d’approvisionnement logicielle. MITRE ATT&CK référence cette technique sous l’identifiant T1195 (Supply Chain Compromise). L’incident XZ Utils de mars 2024 (CVE-2024-3094) en illustre une variante plus récente : la backdoor était injectée dans les scripts de build et le tarball upstream, contournant toute détection par SCA classique. C’est précisément pour ce type de menace que la signature cryptographique des artefacts et les attestations de provenance deviennent indispensables.
Deux référentiels structurent aujourd’hui la réponse opérationnelle :
SLSA (Supply-chain Levels for Software Artifacts), projet de l’OpenSSF (Open Source Security Foundation), définit trois niveaux de maturité pour garantir l’intégrité des artefacts logiciels : de la simple traçabilité des sources (niveau L1) jusqu’à la signature cryptographique vérifiable de chaque étape du pipeline (niveau L3). L’objectif est de pouvoir prouver qu’un binaire déployé provient bien du code source déclaré, sans altération ni injection en cours de build.
Le SBOM (Software Bill of Materials) est le complément opérationnel de SLSA. Il s’agit d’un inventaire lisible par les outils, au format SPDX ou CycloneDX, listant chaque composant d’un logiciel avec sa version et ses dépendances transitives. La CISA et l’Executive Order américain de mai 2021 ont rendu les SBOM obligatoires pour les logiciels vendus aux agences fédérales. En Europe, le Cyber Resilience Act (CRA, Règlement UE 2024/2847), dont les dispositions principales s’appliqueront à partir de décembre 2027, impose des exigences similaires aux fabricants de produits numériques. Les organisations soumises à NIS2 ont intérêt à anticiper cette obligation en intégrant dès maintenant la génération de SBOM dans leurs pipelines de release.
Des outils comme Syft (Anchore) ou les modules CycloneDX pour Maven, npm ou pip permettent de générer automatiquement un SBOM à chaque build et de le publier dans un registre centralisé pour suivi des CVE en temps réel.
Gouvernance et pilotage : intégrer DevSecOps dans le SMSI
L’outillage technique n’est efficace que s’il s’inscrit dans un cadre de gouvernance clair. Pour un RSSI, plusieurs points d’attention sont prioritaires.
Definition of Done sécurisée. Chaque équipe produit doit intégrer des critères de sécurité dans sa définition de “terminé” : zéro finding critique bloquant en SAST, SBOM généré, image Docker sans CVE de sévérité haute ou critique. Ces critères doivent être discutés et acceptés par les équipes de développement, pas imposés unilatéralement.
Gestion du bruit. Un pipeline qui bloque sur chaque finding de sévérité faible génère rapidement de la fatigue d’alerte et des contournements. La pratique recommandée est de distinguer les seuils bloquants (findings critiques et hauts sur le code propriétaire, CVE exploitées activement référencées par la CISA KEV) des alertes informatives consignées dans un backlog sécurité priorisé.
Traçabilité et conformité. Les pipelines CI/CD doivent produire des artefacts d’audit : logs signés, attestations SLSA, SBOM versionné, rapports SAST archivés. Ces éléments constituent la base probatoire pour les audits NIS2 ou les réponses aux questionnaires clients dans des contextes B2B exigeants. Pour approfondir les aspects organisationnels liés à la sécurité en entreprise, il convient d’articuler ces exigences pipeline avec la politique de gestion des risques globale.
Métriques de suivi. Le NIST SSDF recommande de suivre au moins quatre indicateurs : le délai moyen de remédiation par sévérité (MTTR), le taux de findings réouverts (régression), la couverture du pipeline (pourcentage de dépôts avec au moins SAST et SCA actifs), et le nombre de secrets détectés avant production. Ces métriques alimentent le reporting RSSI et justifient les investissements outillage. La gestion de l’infrastructure IT dans son ensemble bénéficie de cette visibilité, notamment dans les architectures hybrides et multi-cloud où la surface d’attaque est distribuée.
Feuille de route pour une mise en oeuvre progressive
Une transformation DevSecOps réussie ne s’opère pas en basculant tous les contrôles le premier jour. Une approche en trois phases est généralement plus pérenne :
Phase 1 (0 à 3 mois) - Fondations. Inventaire des dépôts et pipelines existants, déploiement du SAST et du secret scanning sur les dépôts les plus exposés (applications publiques, traitant des données personnelles), formation des équipes sur les findings les plus fréquents, mise en place des gestionnaires de secrets centralisés.
Phase 2 (3 à 9 mois) - Couverture. Extension du SAST et du SCA à l’ensemble du parc, intégration du scan d’images et de l’IaC scanning, mise en place des SBOM sur les releases, définition des seuils bloquants et du processus d’exception documenté.
Phase 3 (9 à 18 mois) - Maturité. Adoption de SLSA L2 ou L3 sur les composants critiques, automatisation du suivi des CVE via Dependency-Track ou un gestionnaire de SBOM, intégration des métriques dans le tableau de bord SMSI, révision annuelle des règles SAST avec les équipes Dev.
Cette démarche pragmatique, ancrée dans les référentiels NIST SSDF et OWASP DevSecOps Guideline, permet de progresser sans déstabiliser les cycles de livraison existants. Elle positionne la sécurité non comme une contrainte, mais comme une propriété intrinsèque du logiciel produit : un argument de plus en plus décisif dans les appels d’offres et les due diligences des grands comptes.