Fiche 19 — Outillage AppSec & pilotage de la dette de vulnérabilités

Le piège de ce métier : installer des scanners est facile, les faire adopter est le vrai travail. Un consultant DevSecOps se juge sur le taux de correction et le délai de correction, pas sur le nombre de findings.

1. Les familles d’outils — savoir les distinguer instantanément ⭐

Famille	Ce qu’elle analyse	Quand	Force	Limite
Secret scanning	Historique + commits	pre-commit, push, CI	Impact immédiat, peu de FP	Ne trouve que des motifs connus
SAST	Code source (analyse statique, flux de données)	MR, nightly	Trouve tôt, couvre tout le code	Faux positifs, pas de contexte runtime
SCA	Dépendances + licences	build	ROI le plus élevé, peu de FP	Bruit sur les dépendances transitives non atteignables
IaC scanning	Terraform, Bicep, CloudFormation, Helm, K8s manifests	MR	Empêche la mauvaise conf avant le déploiement	Ne voit pas la dérive réelle
Image / container scanning	Couches OS + libs de l’image	build, registre, admission	Simple, efficace	CVE de l’OS de base non corrigeables → bruit
DAST	Application en cours d’exécution	préprod, nightly	Vraies vulnérabilités exploitables	Lent, couverture partielle, besoin d’authentification
API security testing	Spécification OpenAPI + trafic	préprod	Couvre BOLA/BFLA que le DAST classique rate	Nécessite une spec à jour
Fuzzing	Entrées aléatoires/guidées	continu	Trouve des bugs profonds	Coûteux, cible restreinte
CSPM / KSPM	Configuration cloud/K8s déployée	continu	Voit la réalité	Après coup
Runtime (eBPF, RASP)	Comportement d’exécution	production	Contexte réel, détection	Complexité, faux positifs
ASPM	Agrège tout ce qui précède	transverse	Priorisation, dédoublonnage, ownership	Nouveau marché, coût

Question piège classique : « SAST ou DAST ? » → Réponse attendue : ce ne sont pas des concurrents, ils ont une couverture complémentaire. Le SAST voit du code non atteignable (faux positifs), le DAST ne voit que ce qu’il atteint (faux négatifs). Si je dois n’en garder qu’un pour démarrer : SCA + secret scanning, parce que c’est là que se trouvent les vulnérabilités réellement exploitées et que le rapport signal/bruit est le meilleur. ⭐

2. Outils concrets (savoir en nommer et justifier)

Besoin	Open source	Commercial / plateforme
Secrets	gitleaks, trufflehog, detect-secrets	GitHub Secret Scanning + Push Protection, GitLab Secret Detection
SAST	Semgrep (règles lisibles, custom facile), Bandit (Py), gosec, SpotBugs/find-sec-bugs (Java), ESLint security	CodeQL (GitHub Advanced Security), Checkmarx, Fortify, Sonar (+ SonarQube pour la qualité), Snyk Code
SCA / dépendances	OWASP Dependency-Check, Trivy fs, Grype, `npm audit`, OSV-Scanner	Dependabot, Renovate, Snyk Open Source, GitLab Dependency Scanning, Mend, Xray
IaC	Checkov, tfsec/Trivy config, KICS, Terrascan, conftest/OPA	Snyk IaC, Prisma Cloud, Wiz Code
Images	Trivy, Grype, Clair, Dockle	Aqua, Sysdig, Prisma, Defender for Containers
K8s posture	kube-bench, kubescape, Polaris, kubeaudit	Wiz, Orca, Sysdig, Defender for Cloud
DAST	OWASP ZAP (baseline scan en CI, full scan en nightly), Nuclei	Burp Suite Enterprise, Invicti, Acunetix, StackHawk
API	Schemathesis, ZAP + OpenAPI	42Crunch, Salt, Noname
Fuzzing	AFL++, libFuzzer, OSS-Fuzz, Jazzer (JVM), go-fuzz	Mayhem, Code Intelligence
Signature / provenance	cosign/Sigstore, in-toto, slsa-github-generator	Chainguard, JFrog
SBOM	Syft, cdxgen, Trivy	Anchore, Snyk, Cybeats
Policy as code	OPA/Rego + conftest, Kyverno	Styra DAS
Orchestration / ASPM	DefectDojo (excellent argument open source ⭐)	ArmorCode, Cycode, Apiiro, Ox, GitLab/GitHub natif, Snyk AppRisk

Comment répondre à « quels outils utilises-tu ? » : ne récite pas une liste. Dis : « Je choisis en fonction du langage, de l’écosystème SCM et de la maturité de l’équipe. En démarrage, je pose systématiquement gitleaks + Renovate/Dependabot + Trivy + Checkov, parce que c’est peu bruyant et que ça se branche en une journée. Le SAST vient ensuite, avec des règles restreintes, et le DAST en dernier parce qu’il demande un environnement de test stable. »

3. Le vrai sujet : les quality gates sans bloquer les équipes ⭐

L’erreur du débutant

Activer tous les scanners en mode bloquant sur tous les projets, le lundi matin. Résultat : 12 000 findings, pipelines rouges, et une équipe qui ajoute allow_failure: true ou contourne la CI dans la semaine. Le programme est mort.

La bonne séquence (à savoir dérouler)

Phase	Durée	Mode	Objectif
0. Baseline	S1-S2	scan informatif uniquement	Mesurer l’ampleur réelle, ne rien casser
1. Gel de la dette	S3-S6	bloquant sur le différentiel uniquement	No new critical : la dette existante est gelée, on empêche l’aggravation
2. Réduction	M2-M6	campagnes ciblées + SLA	Traiter la dette historique par lots priorisés
3. Élargissement	M6+	gates étendus (élevé, puis IaC, puis DAST)	Monter le niveau progressivement
4. Généralisation	M9+	pipeline de conformité imposé au niveau groupe	Rendre le contrôle non contournable

Concept clé : le diff scanning / baseline. On ne bloque que ce que la MR introduit. C’est ce qui rend le programme acceptable politiquement. Semgrep, ZAP, Checkov et les scanners GitLab/GitHub savent tous le faire (--baseline-commit, fichiers de baseline).

Politique de gate raisonnable pour démarrer :

Bloquant : secret détecté (toujours, sans exception), vulnérabilité critique avec correctif disponible introduite par la MR, IaC critique (stockage public, IAM *, chiffrement désactivé).
Avertissement : élevée, moyenne, findings SAST hors du top 5 des règles.
Jamais bloquant : licences (sauf politique juridique), findings informatifs.

Mécanisme d’exception obligatoire ⭐ : sans porte de sortie tracée, les équipes créent des contournements sauvages. Une exception doit avoir : un motif, un porteur, une date d’expiration, une validation (security champion ou AppSec), et être auditable. Les fichiers .semgrepignore / # nosec / .trivyignore doivent exiger un commentaire justificatif et être revus périodiquement.

4. Trier et prioriser (là où le senior se distingue)

Un finding ne vaut d’être corrigé que si l’on peut répondre oui à plusieurs de ces questions :

Le composant est-il réellement chargé/atteignable ? (reachability analysis — Snyk, Semgrep Supply Chain, Endor : réduit souvent le volume de 70-90 %)
Le service est-il exposé (Internet vs interne) ?
Y a-t-il un exploit connu ? → CISA KEV, EPSS (cf. fiche 10)
Manipule-t-il des données sensibles ou des privilèges ?
Existe-t-il un correctif ou seulement un contournement ?
Existe-t-il une mesure compensatoire (WAF, segmentation, absence de la fonctionnalité) ?

→ Formule de priorisation à énoncer : Sévérité (CVSS) × Exploitabilité (KEV/EPSS) × Atteignabilité × Exposition × Criticité métier. Le CVSS seul est un mauvais outil de priorisation en DevSecOps.

Dédoublonnage et ownership : le même CVE remonte par le SCA, le scan d’image, le CSPM et le pentest. Sans agrégation (ASPM / DefectDojo) et sans catalogue de services qui dit qui possède quel composant, rien n’est corrigeable. La question à poser en premier en mission : « qui est le propriétaire de ce service ? » — dans 8 cas sur 10 personne ne sait répondre, et c’est le vrai blocage. ⭐