Un quality gate de sécurité qui ne bloque jamais ne fait que produire des rapports que personne ne lit. Un quality gate qui bloque pour tout est ignoré au bout de trois sprints — l'équipe désactive ou contourne. Le sweet spot existe : c'est ce que je rebuilde sur la majorité des missions DevSecOps. Voici la grille concrète.
Le principe : criticité × phase × confiance
Un finding remonté par un outil n'est pas une vérité absolue. Il a une criticité (CVSS, exploitabilité), il intervient à une phase du SDLC (commit, PR, build, déploiement), et il a un niveau de confiance (signal vs. bruit selon l'outil). Le bon design d'un quality gate combine les trois.
Le pattern :
- Bloquant : criticité haute + confiance haute + phase tardive (déploiement prod).
- Warning : criticité moyenne ou confiance moyenne. PR peut merger, mais ticket créé.
- Silencieux : criticité basse, à traiter dans les revues techniques de fond.
SAST (Static Application Security Testing)
Analyse du code source. Trouve les patterns dangereux : injections SQL, XSS, désérialisation non sécurisée, gestion incorrecte des secrets, mauvais usage des API crypto.
Outils 2026 :
- SonarQube : large couverture, intégration GitLab/GitHub native, signal correct mais bruyant en bas de pyramide.
- Semgrep : rapide, règles personnalisables, excellent pour les patterns d'entreprise.
- Snyk Code : interface produit soignée, intégration IDE, faux positifs moindres mais payant.
- CodeQL (GitHub) : très puissant, gratuit pour repos publics, courbe d'apprentissage non négligeable.
Quality gate type :
- Bloque la merge sur PR : findings nouveaux de niveau Critical ou High avec confiance haute.
- Tolère les findings existants sur la branche cible (pas de régression sans en sortir).
- Les règles personnalisées (Semgrep) couvrent les patterns spécifiques à votre stack.
DAST (Dynamic Application Security Testing)
Test dynamique sur l'application déployée. Trouve les classes d'attaque qui dépendent de la configuration runtime : headers HTTP manquants, CSRF, contrôles d'accès cassés, exposition d'endpoints debug.
Outils 2026 :
- OWASP ZAP : open source, intégrable en CI mais lent (ne pas le mettre sur chaque PR — sur la pipeline staging).
- Burp Suite Enterprise : top gamme, automatisation correcte mais cher.
- Detectify : surface de scan SaaS, bon pour le périmètre internet-facing.
Quality gate type :
- Pas sur PR (trop lent). Sur déploiement staging post-merge.
- Bloque la promotion staging → prod si un High est trouvé non-acquitté.
- Acquittement explicite par un humain pour les false positives, avec ticket de suivi.
SCA (Software Composition Analysis)
Analyse des dépendances tierces. Détecte les CVE connues dans les libs que vous utilisez. C'est le quality gate avec le ROI le plus rapide.
Outils 2026 :
- Snyk Open Source : bon catalogue, fix PR automatique.
- Dependabot (GitHub) : gratuit, pratique pour les majors, moins fin sur la priorisation.
- Renovate : open source, configuration plus puissante que Dependabot.
- OWASP Dependency-Check : open source, fiable mais moins ergonomique.
Quality gate type :
- Bloque la merge si une nouvelle dépendance ajoutée a une vulnérabilité High/Critical.
- Crée des PR automatiques pour les patches mineurs.
- Quarterly review pour les majors avec breaking changes.
IaC scanning
Scan des configurations Infrastructure-as-Code (Terraform, CloudFormation, Kubernetes manifests, Helm charts). Détecte les misconfigurations classiques : S3 publics, security groups trop ouverts, secrets en clair, RBAC excessif.
Outils 2026 :
- Checkov : open source, large couverture, bonne intégration CI.
- tfsec : ciblé Terraform, rapide.
- Kubescape : pour Kubernetes, niveau MITRE ATT&CK.
- Snyk IaC : intégration unifiée si vous êtes déjà chez Snyk.
Quality gate type :
- Bloque la merge sur les violations Critical (ex: bucket public, security group 0.0.0.0/0 sur port admin).
- Warning sur Medium avec ticket auto.
Secret detection
Le quality gate avec le plus haut taux de signal. Détecte les clés API, tokens, mots de passe commités par erreur. À configurer en pre-commit ET en CI.
Outils 2026 :
- gitleaks : open source, très rapide, faux positifs gérables.
- trufflehog : meilleur sur l'historique Git profond.
- GitHub Secret Scanning : natif sur GitHub, zéro setup, alerte les fournisseurs (AWS, Stripe...) qui révoquent automatiquement.
Quality gate type :
- pre-commit hook (refusé localement avant push).
- CI ré-vérifie systématiquement (un dev peut désactiver son hook local).
- Bloque la merge sans exception. Pas de warning. Un secret commité = un secret à révoquer immédiatement.
Le cas Mercedes-Benz illustre les conséquences : voir Mercedes-Benz et la fuite de token GitHub.
L'architecture type d'un pipeline sécurisé
``` PR ouverte ├─ pre-commit (local) : secret detection ├─ CI build : │ ├─ SAST (rapide, configurable, bloquant sur regressions) │ ├─ SCA (rapide, bloquant sur new High/Critical) │ ├─ IaC scan (rapide, bloquant sur Critical) │ └─ Secret detection (bloquant systématique) ├─ Tests fonctionnels └─ ✓ Merge
Post-merge sur staging : ├─ Déploiement staging ├─ DAST (long, bloquant sur High avant promotion) └─ ✓ Promotion possible vers prod
Production : ├─ Déploiement ├─ Re-scan SCA quotidien (nouvelles CVE) └─ Monitoring runtime ```
Le piège : trop de bloquants
Un quality gate qui bloque sur tout produit deux comportements toxiques :
- Les développeurs apprennent à acquitter sans lire ("on regardera plus tard").
- La sécurité devient l'ennemi de la vélocité dans la culture d'équipe.
Le bon réglage : moins de 5% des PR bloquées par les outils sécurité, et chaque blocage est un vrai sujet. Si vous bloquez 30% des PR, vous bloquez du bruit.
Les SLO sécurité du pipeline
À tracker en parallèle des quality gates :
- MTTR vulnérabilités Critical : moins de 7 jours en prod.
- MTTR vulnérabilités High : moins de 30 jours.
- Taux de couverture SAST : >90% des nouveaux commits.
- Taux de fuites secrets : 0 en production. Dans dev, idéalement bloqué avant push.
Ces SLO sont auditables. Ils servent autant la sécurité que la conformité (SOC 2, ISO 27001).
Pas de DevSecOps sans threat model
Mettre des outils n'est utile que si on sait quoi chercher. Avant de déployer une stack DevSecOps complète, faites le threat modeling de votre application. Cela oriente les règles personnalisées (Semgrep notamment), priorise les efforts, évite de scanner du code qui n'est jamais exposé. Pour les applications IA, les classes de menaces changent — voir Threat modeling LLM.
