TL;DR — l'essentiel en 5 points
- DevSecOps = sécurité dans le pipeline, pas un poste de sécurité externe : les développeurs sont les premiers responsables, outillés.
- Stack 2026 : SAST (Semgrep) + DAST (OWASP ZAP) + SCA (Snyk/Dependabot) + Secret detection (gitleaks) + IaC scanning (Checkov) + SBOM (Syft) + Signature (Sigstore).
- Bloquant uniquement sur findings critiques : <5% de PR bloquées. Au-delà, l'équipe contourne et perd toute valeur.
- CRA et NIS2 imposent : SBOM tenu à jour, VDP opérationnel, signature des artefacts, MTTR vulnérabilités < 30 jours.
- L'erreur courante : empiler des outils sans politique cohérente. Le bon design vient d'un threat model.
Le contexte 2026
DevSecOps n'est plus une option en 2026. Trois facteurs forcent l'adoption :
Régulation. CRA (déc. 2027), NIS2 (transposé 2025), DORA (jan. 2025), AI Act (août 2026) imposent des contrôles techniques sur le code, les dépendances, les déploiements. Sans pipeline DevSecOps, la conformité est manuelle, coûteuse, fragile.
Supply chain attacks. SolarWinds, Log4j, xz/liblzma, tj-actions/changed-files... la chaîne logicielle est devenue le vecteur d'attaque privilégié. Sans SBOM, signature, et audit des dépendances, vous ne maîtrisez pas votre exposition.
Industrialisation des outils. Ce qui était R&D en 2020 est commodity en 2026. Snyk, Semgrep, gitleaks, Sigstore, Vault — chacun fait son job en quelques minutes de setup, intégrable en quelques lignes de YAML CI/CD.
La stack DevSecOps type 2026
``` PR ouverte ├─ pre-commit (local) : secret detection (gitleaks) ├─ CI build : │ ├─ SAST (Semgrep, SonarQube) │ ├─ SCA (Snyk, Dependabot) │ ├─ IaC scanning (Checkov, tfsec) │ ├─ Secret detection (gitleaks) │ ├─ Tests fonctionnels │ └─ ✓ Merge si quality gates passent
Post-merge : ├─ Build artefact + SBOM (Syft) ├─ Signature artefact + SBOM (Sigstore) ├─ Push registry ├─ Déploiement staging ├─ DAST (OWASP ZAP) └─ ✓ Promotion prod si OK
Production : ├─ Re-scan SCA quotidien (nouvelles CVE) ├─ Monitoring runtime └─ Alerting anomalies ```
Les 5 quality gates de référence
1. Secret detection — bloquant systématique
C'est le quality gate avec le plus haut taux de signal. Un secret commité = un secret à révoquer. Aucune exception. Outils : gitleaks, trufflehog, GitHub Secret Scanning natif.
2. SAST — bloquant sur régressions
Bloque les nouveaux findings High/Critical introduits par la PR. Tolère les findings existants sur la branche cible. Outils 2026 : Semgrep (rapide, règles personnalisables), SonarQube (large couverture), Snyk Code (UX produit).
3. SCA — bloquant sur new High/Critical
Bloque l'ajout d'une dépendance avec CVE critique. PR auto-générées pour les patches mineurs. Outils : Snyk Open Source, Dependabot, Renovate (plus configurable).
4. IaC scanning — bloquant sur Critical
S3 publics, security groups 0.0.0.0/0 sur ports admin, secrets hardcodés. Checkov (large couverture), tfsec (Terraform), Kubescape (Kubernetes).
5. DAST — sur staging post-merge
Trop lent pour bloquer chaque PR. Tourne après merge sur staging, bloque la promotion prod si High non acquitté. OWASP ZAP, Burp Suite Enterprise.
Voir DevSecOps en CI/CD : quality gates qui bloquent vraiment pour les seuils précis.
Supply chain — le sujet 2026
L'attaque tj-actions/changed-files (2023) a démontré qu'une seule action GitHub compromise peut exposer des secrets de milliers d'organisations. La supply chain est devenue le vecteur d'attaque le plus dangereux.
Trois pratiques essentielles :
- SBOM systématique par build, signé, archivé pour la durée de support. Voir SBOM 2026.
- Signature Sigstore des artefacts livrés. Sans clé persistante, via OIDC. Vérification automatique en admission controller Kubernetes. Voir Sigstore.
- Audit des actions GitHub : pinning par SHA, allowlist organisation, permissions strictes, OIDC pour les credentials cloud. Voir Supply chain GitHub Actions.
Secret management
Les secrets long-terme dans le code, les configs ou les CI sont la principale source de fuites. La cible 2026 : zéro secret long-terme stocké.
Architecture type :
- HashiCorp Vault (ou AWS/GCP Secrets Manager) comme source unique.
- Secrets dynamiques : DB credentials, AWS credentials, PKI certificates générés à la demande avec TTL court (1h-24h).
- External Secrets Operator ou Vault Agent pour injecter dans les pods Kubernetes.
- OIDC pour authentifier les pipelines CI/CD sans clés persistantes.
- Audit log centralisé.
Voir Secret rotation automatisée.
Règles SAST personnalisées — le levier sous-utilisé
Les règles génériques (OWASP, packs vendor) couvrent les généralités. Vos vrais risques sont spécifiques : APIs internes à ne pas exposer, fonctions dépréciées, patterns d'autorisation à respecter, isolation multi-tenant à faire respecter.
Semgrep permet d'écrire en 30 minutes des règles AST qui détectent vos patterns dangereux. ROI immédiat. Voir Semgrep règles entreprise.
OWASP ASVS niveau 2 — le baseline
ASVS L2 est devenu en 2026 l'attente baseline pour SaaS B2B sérieux. ~200 contrôles couvrant les 14 chapitres : architecture, authentification, sessions, autorisation, validation, crypto, logging, data protection, communications, code, business logic, files, API, configuration.
Pour aligner sur ASVS L2 :
- Threat model maintenu (V1).
- MFA obligatoire sur comptes sensibles, vérification HIBP des mots de passe (V2).
- RBAC strict avec tests d'autorisation horizontaux et verticaux (V4).
- Validation systématique côté serveur (V5).
- Crypto moderne uniquement (V6).
- Logs structurés, événements sécurité tracés (V7).
- API : rate limiting, OpenAPI strict, CORS configuré (V13).
Voir OWASP ASVS niveau 2.
Articulation avec la conformité
DevSecOps est un préalable à la conformité, pas un sous-produit :
- ISO 27001 Annexe A 2022 : nouveaux contrôles A.8.28 (secure coding), A.5.7 (threat intelligence), A.8.9 (configuration management). DevSecOps les couvre directement. Voir ISO 27001 Annexe A 2022.
- CRA : SBOM, VDP, signature, MTTR vulnérabilités. DevSecOps les industrialise. Voir CRA roadmap.
- SOC 2 Type II : continuous compliance. DevSecOps fournit la télémétrie.
- PCI DSS 4.0.1 : exigences sur scripts e-commerce et continuous compliance. DevSecOps les automatise.
Les pièges que je vois en mission
Empiler les outils sans politique
"On a Snyk, SonarQube, Semgrep, et Checkmarx en parallèle." Résultat : énormément de findings, équipe submergée, signalisation noyée. Le bon design = un outil par catégorie, configuré finement, intégré dans le pipeline avec des seuils clairs.
Bloquer trop ou pas assez
Bloquant sur tout : équipe désactive en 2 semaines, perte totale. Bloquant sur rien : reports lus par personne. Sweet spot : Critical/High bloquant, Medium en warning avec ticket auto, Low en revue technique de fond.
Pas de threat model en amont
Outils sans modèle de menace produisent du bruit générique. Avec un threat model spécifique au produit, les règles deviennent ciblées et le signal monte massivement.
Pas de SBOM ou SBOM "fait au stylo"
Excel, Notion, document Word — tout sauf un SBOM machine-lisible signé. À l'audit CRA en 2027, c'est une non-conformité directe.
Secrets en variables d'environnement non-rotated
Le pattern le plus dangereux. Mercedes-Benz l'a appris. Aucune exception ne devrait exister en 2026 : tout secret doit venir d'un secret manager avec rotation.