DevSecOps en 2026 : policy-as-code en CI/CD avec OPA, SLSA, Sigstore et Trivy

La sécurité logicielle ne peut plus attendre la revue finale.
Transformez vos règles en contrôles exécutables, traçables et bloquants au bon moment.

1. Chiffres clés

2. Introduction

Un pipeline CI/CD peut être rapide et fragile. Il peut compiler, tester, construire une image, pousser en registry, déployer en staging, puis en environnement réel, tout en laissant passer un secret, un artefact sans signature, une dépendance critique, une règle IAM trop ouverte ou un déploiement Kubernetes sans limite de ressources.

La friction n'arrive pas toujours au moment du commit. Elle arrive quand un audit client demande des preuves, quand un incident supply chain révèle une dépendance vulnérable, quand un développeur contourne un scanner trop bruyant, quand le RSSI découvre que les exceptions ne sont documentées nulle part, quand le déploiement "urgent" devient la norme.

Le verdict est net : une chaîne de delivery sans politiques exécutables repose sur de la confiance implicite.

Le DevSecOps ne se résume pas à ajouter un outil de sécurité dans un pipeline saturé. Son intérêt est ailleurs : rendre les règles lisibles, versionnées, testables et applicables. Avec le policy-as-code, ce déplacement devient concret. La consigne quitte le PDF ; elle devient un contrôle qui lit un artefact, prend une décision, produit une trace et bloque seulement quand le risque le justifie.

Cette nuance est importante. Bloquer tout est impossible. Tout autoriser est irresponsable. La maturité se trouve entre les deux : politiques claires, exceptions contrôlées, priorisation par gravité, preuves exportables, responsabilité partagée.

3. Acteurs

L'écosystème DevSecOps policy-as-code rassemble des standards, des outils de scan, des moteurs de décision et des plateformes de delivery.

3.1. Les standards donnent le vocabulaire

3.2. Les outils n'ont pas tous le même métier

Le piège serait de confondre outil et système. Trivy détecte. OPA décide. SLSA structure la provenance. Sigstore signe. Le pipeline orchestre. Le RSSI arbitre. Les développeurs corrigent. Aucun acteur ne remplace les autres. Comme dans une chaîne de montage, le contrôle qualité n'a de valeur que s'il intervient au bon poste, avec un critère compris par l'atelier.

4. Définition

On appelle policy-as-code la pratique qui écrit des règles de sécurité, conformité ou gouvernance dans un format versionné, exécutable et testable par machine.

Dans une chaîne CI/CD, ces règles évaluent des entrées concrètes : pull request, fichier Terraform, image conteneur, manifeste Kubernetes, SBOM, attestation SLSA, signature Cosign, résultat de scan, dépendance, secret, licence ou contexte de déploiement. La sortie est une décision : autoriser, avertir, bloquer, demander une exception ou escalader.

La définition doit rester précise. Un scanner n'est pas automatiquement du policy-as-code. Un scanner produit un signal. Le moteur de règles transforme ce signal en décision cohérente avec une exigence d'entreprise. Par exemple : "bloquer un conteneur non attesté en environnement critique", "refuser un conteneur root", "interdire une CVE critique exploitable sans correctif planifié", "demander approbation RSSI pour une exception de 14 jours", "refuser un secret détecté dans un commit".

Le DevSecOps devient alors une chaîne de preuves.

5. Contexte 2026

La pression vient de deux directions. D'un côté, la surface logicielle s'étend : microservices, conteneurs, open source, IaC, SaaS, APIs, registries, agents IA, dépendances transitives, workflows GitHub ou GitLab. De l'autre, les attaquants exploitent les failles de cette chaîne avec plus de méthode. Le Verizon DBIR 2026 indique que 31 % des brèches commencent désormais par des vulnérabilités logicielles, devant les mots de passe volés comme vecteur initial.

Cette donnée change l'ordre des priorités. Pendant longtemps, l'effort de sécurité a fortement pesé sur l'authentification, le réseau et la surveillance. Ces sujets restent majeurs. Mais la chaîne de fabrication du logiciel devient un terrain d'attaque direct : dépendance compromise, image modifiée, script CI détourné, secret exfiltré, construction non reproductible, configuration cloud trop permissive.

Le NIST SSDF propose une réponse de fond : préparer l'organisation, protéger le logiciel, produire du logiciel sécurisé et répondre aux vulnérabilités. La logique n'est pas de bloquer les développeurs, mais d'intégrer des pratiques vérifiables dans le cycle de vie. CISA insiste de son côté sur la sécurité par conception, la transparence et les SBOM comme éléments de visibilité supply chain.

Cette approche donne la couche opérationnelle. Elle évite le grand écart entre les principes et la réalité du pipeline. Un contrôle écrit en Rego, Conftest, Gatekeeper, Kyverno ou équivalent se révise en pull request, se teste, se déploie progressivement et s'audite. Une attestation SLSA ou GitHub Artifact Attestation prouve la provenance. Une signature Sigstore relie un artefact à une identité de construction. Un SBOM nourrit la gestion de vulnérabilités.

Automatisée correctement, la sécurité devient plus explicite. Elle ne disparaît pas.

6. Méthode recommandée

La méthode recommandée suit un principe simple : partir des risques de livraison, traduire en politiques minimales, automatiser progressivement, puis durcir à mesure que la qualité des signaux augmente.

6.1. Commencer par le flux réel

1. Cartographier la chaîne de construction et de déploiement. On identifie où le code entre, où il est testé, où l'artefact conteneur est construit, où les secrets sont disponibles, où les dépendances sont résolues, où les livrables sont stockés et où les déploiements sont validés. Sans cette cartographie, les contrôles se posent au hasard.

2. Classer les environnements. Le niveau d'exigence varie entre une branche expérimentale, un environnement de test, une préproduction et un service exposé. Les règles distinguent avertissement, blocage souple et blocage strict. Cette progressivité réduit les contournements.

3. Définir un socle de gates minimaux. Le premier socle couvre secrets, vulnérabilités critiques exploitables, dépendances obsolètes, licences interdites, IaC dangereuse, conteneur root, artefact sans signature, absence de SBOM, provenance manquante pour un déploiement sensible. Mieux vaut un socle court, compris et assumé qu'un traité impossible à appliquer.

6.2. Transformer les signaux en décisions

4. Séparer détection et décision. Les outils de scan produisent des résultats. Les politiques tranchent. Cette séparation évite de subir les seuils par défaut d'un outil. Elle permet aussi de dire : une vulnérabilité critique dans un service exposé bloque ; la même faiblesse dans un composant jamais chargé peut créer une exception limitée.

5. Versionner les règles comme du code. Le référentiel de contrôles vit dans un dépôt, avec tests unitaires, revue, changelog et propriétaires. Une condition de sécurité non testée peut casser le delivery. Une consigne sans historique ne se prouve pas.

6. Attester les artefacts. Les constructions destinées aux environnements critiques produisent une provenance : source, commit, workflow, builder, dépendances, digest, signature. SLSA et Sigstore donnent les briques nécessaires pour relier le livrable à son origine.

6.3. Gouverner les exceptions

7. Gérer les exceptions comme un produit. Une dérogation contient une raison, une durée, un propriétaire, un risque accepté, une date d'expiration et une action de correction. Sans échéance, elle devient une faille permanente.

8. Mesurer les effets. Les indicateurs utiles couvrent blocages, faux positifs, délais de correction, vulnérabilités critiques ouvertes, dérogations expirées, images signées, artefacts attestés, constructions reproductibles, secrets détectés et règles modifiées.

9. Relier CI/CD et production. Le contrôle par politique ne s'arrête pas au build. Les mêmes intentions se prolongent dans l'admission Kubernetes, le GitOps, les registres, le cloud et l'observabilité. Sinon, le pipeline paraît propre tandis que l'exécution reste permissive.

Cette méthode est volontairement pragmatique. Elle protège le flux sans le figer.

7. Conseils Logiks

Nous recommandons de ne pas commencer par une ambition "zéro vulnérabilité". C'est séduisant dans une présentation, rarement soutenable dans une vraie équipe. Le bon départ identifie les contrôles qui évitent les incidents graves avec peu de débat : secrets dans le code, artefact non signé en environnement critique, privilèges excessifs, dépendance critique exploitable sans plan, absence de propriétaire.

Ensuite, nous conseillons de nommer un propriétaire par famille de règles. La doctrine reste côté sécurité, mais la plateforme maintient l'exécution, les équipes applicatives corrigent, et le produit arbitre les délais quand une release métier est concernée. Sans gouvernance, le policy-as-code devient un mur opaque.

Nous privilégions aussi les preuves exportables. Un client B2B, un investisseur, un assureur ou un auditeur demandera rarement une capture d'écran de pipeline. Il demandera des preuves : SBOM, attestation, signature, historique de corrections, politique d'exception, matrice de risques. Construire ces preuves dès le départ évite une reconstruction pénible au moment critique.

Enfin, nous insistons sur la pédagogie. Un blocage doit expliquer quoi corriger, où agir et comment demander une exception. Un message d'erreur cryptique crée du contournement. Un feedback clair crée de la discipline.

Maillage interne recommandé : relier cet article aux contenus Logiks sur audit technique pré-levée, EDR vs antivirus PME, Zero Trust, PRA/PCA, audit cybersécurité PME et gouvernance IA.

8. Grille de décision

8.1. Choisir ce qui bloque vraiment

8.2. Garder une règle lisible

Un blocage doit rester rare, explicable et difficile à contourner. Lorsque tout bloque, les équipes cherchent une porte latérale. Lorsque rien ne bloque, la politique n'existe pas.

9. Erreurs fréquentes

La première erreur consiste à activer dix scanners sans politique commune. Les développeurs reçoivent des alertes contradictoires, les seuils varient, les tickets s'empilent, puis la fatigue s'installe. Un signal non priorisé finit ignoré.

La deuxième erreur consiste à bloquer trop tôt. Une organisation qui découvre 800 vulnérabilités ne doit pas mettre toute la CI au rouge le premier jour. Elle doit créer une baseline, bloquer les nouveaux risques critiques et résorber l'ancien stock par lots.

La troisième erreur consiste à traiter le SBOM comme un PDF. Un SBOM utile est généré automatiquement, attaché à un artefact, conservé, exploitable par machine et relié aux vulnérabilités. Sinon, il rassure plus qu'il ne protège.

La quatrième erreur consiste à oublier les secrets du pipeline. Les environnements CI/CD manipulent tokens cloud, clés de registry, identifiants de déploiement et permissions élevées. Protéger le code sans protéger le pipeline revient à fermer la porte en laissant les clés dehors.

La cinquième erreur consiste à ne pas tester les politiques. Un contrôle OPA mal écrit peut bloquer une release saine ou laisser passer un cas critique. Les règles doivent avoir leurs fixtures, leurs tests et leurs revues.

La sixième erreur consiste à laisser les exceptions sans fin. Une exception permanente n'est plus une exception. C'est une politique alternative non assumée.

10. Plan d'action 30 / 60 / 90 jours

10.1. jours : établir la baseline

Dans les 30 jours, on cartographie le pipeline, les artefacts, les registries, les secrets, les environnements et les responsabilités. Les scans existants sont consolidés, mais les seuls blocages immédiats concernent les secrets et les risques déjà incontestables. Une première politique d'exception précise propriétaire, durée et preuve attendue.

10.2. jours : appliquer les premiers gates

Dans les 60 jours, les premiers contrôles codés entrent dans la chaîne : IaC, conteneurs, signatures, SBOM, seuils de vulnérabilité et admission Kubernetes si le contexte s'y prête. Les règles sont versionnées, testées et revues. Le reporting distingue stock historique et nouveau risque introduit.

10.3. jours : produire des preuves auditables

Dans les 90 jours, provenance et attestations couvrent les livrables critiques. Les conteneurs sensibles sont signés, les SBOM attachés, les exceptions expirent automatiquement, et les déploiements importants vérifient l'origine des artefacts. Les comités de pilotage suivent peu de métriques : blocages utiles, délai de correction, exceptions expirées, couverture signature/provenance, dette critique.

Le flux porte alors une part mesurable de sécurité. Pas une réunion de fin de course.

11. FAQ

Quelle différence entre DevSecOps et policy-as-code ?
Le DevSecOps est une culture et une organisation qui intègrent la sécurité au développement et à l'exploitation. Le policy-as-code est un moyen technique de rendre les règles exécutables, testables et auditables.

OPA est-il obligatoire ?
Non. OPA est un moteur puissant et largement adopté, mais Kyverno, Conftest, Sentinel, Checkov ou des gates natifs peuvent convenir. Le point structurant est la clarté des règles et leur intégration au pipeline.

Faut-il bloquer toutes les vulnérabilités critiques ?
Pas mécaniquement. Il faut bloquer les vulnérabilités critiques exploitables, exposées ou sans mitigation acceptable. Une politique mature tient compte du contexte, mais documente toute exception.

SLSA remplace-t-il les scanners ?
Non. SLSA traite surtout la provenance et l'intégrité de build. Les scanners traitent vulnérabilités, secrets, IaC, licences ou configurations. Les deux se complètent.

À quoi sert Sigstore dans une PME SaaS ?
Sigstore permet de signer et vérifier des artefacts sans gérer une PKI complexe. Pour une PME qui déploie des conteneurs, c'est une manière pragmatique de réduire le risque d'image non autorisée.

Comment éviter de ralentir les développeurs ?
En démarrant avec peu de règles, des messages clairs, des exceptions bornées, une baseline de dette existante et un blocage ciblé sur les risques nouveaux ou critiques.

12. Sources principales

• Verizon, 2026 Data Breach Investigations Report : https://www.verizon.com/business/resources/reports/dbir/
• NIST, Secure Software Development Framework SP 800-218 : https://csrc.nist.gov/pubs/sp/800/218/final
• NIST SP 800-218 PDF : https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf
• OpenSSF SLSA v1.1 levels : https://slsa.dev/spec/v1.1/levels
• SLSA Build Track basics v1.2 : https://slsa.dev/spec/v1.2/build-track-basics
• CNCF, Open Policy Agent project : https://www.cncf.io/projects/open-policy-agent-opa/
• Open Policy Agent : https://openpolicyagent.org/
• Trivy GitHub repository : https://github.com/aquasecurity/trivy
• Trivy misconfiguration scanning : https://trivy.dev/docs/latest/scanner/misconfiguration/
• CISA, Secure by Design : https://www.cisa.gov/securebydesign
• CISA, 2025 Minimum Elements for SBOM : https://www.cisa.gov/sites/default/files/2025-08/2025_CISA_SBOM_Minimum_Elements.pdf
• Sigstore Cosign signing overview : https://docs.sigstore.dev/cosign/signing/overview/
• GitHub Artifact Attestations documentation : https://docs.github.com/actions/security-for-github-actions/using-artifact-attestations/using-artifact-attestations-to-establish-provenance-for-builds