La question que je reçois le plus souvent en discovery : "on a un outil X, faut-il qu'on en ajoute d'autres ?". La bonne réponse n'est jamais générique. Elle dépend de votre langage, de votre stack, de votre maturité dev. Mais le canevas de décision, lui, est stable. Voilà ce que je propose en cadrage avec un CTO ou un lead DevSecOps en 2026.
Les cinq familles, sans ambiguïté
SAST (Static Application Security Testing)
Analyse statique du code source pour trouver des vulnérabilités (injections, deserialization, crypto faible, etc.).
À déployer : sur le repo, déclenché à chaque PR + en scan complet hebdomadaire.
Choix d'outil : voir comparatif Checkmarx, Semgrep, SonarQube, Snyk, Fortify. En vrai, pour une PME, Semgrep ou SonarQube + un OSS spécialisé par langage (Bandit, ESLint security, etc.) couvre 80% du besoin.
DAST (Dynamic Application Security Testing)
Test boîte noire de l'application qui tourne. OWASP ZAP, Burp Suite, ou outils managés (Detectify, StackHawk).
À déployer : sur l'environnement de staging, déclenché en nightly + avant chaque release majeure.
Piège classique : faire tourner DAST sur staging avec des données dégradées et croire que ça couvre. Si staging n'a pas les mêmes routes/flux que la prod, vous testez à côté.
SCA (Software Composition Analysis)
Analyse des dépendances tierces (libs, packages) pour trouver des CVE connues. Snyk, Trivy, OWASP Dependency-Check, Dependabot/Renovate côté GitHub natif.
À déployer : sur chaque build, bloquant si CVE critique avec exploit connu.
Le piège : se contenter de "ya une CVE high" sans regarder si elle est réellement exploitable dans VOTRE contexte d'usage de la lib. Beaucoup d'équipes brulent du temps à patcher des CVE non exploitables. Voir SBOM et reachability pour la logique de priorisation.
Secrets scanning
Détection de tokens/clés API/credentials dans le code, l'historique git, les logs. Gitleaks, TruffleHog, GitHub native secret scanning.
À déployer : pre-commit hook côté local + scan à chaque PR + scan historique sur tous les repos lors de l'onboarding.
Le piège : ne pas faire le scan historique sur les vieux repos. C'est là que sont les vrais secrets fuités. Un secret committé en 2022 et révoqué en 2024 reste exploitable dans l'historique si jamais l'auteur du commit n'a pas révoqué proprement. Voir secret leak repo GitHub playbook 24h.
IaC scanning (Infrastructure as Code)
Analyse des Terraform, Pulumi, CloudFormation, Kubernetes manifests, Helm charts. Checkov, tfsec, Trivy IaC, Kics.
À déployer : à chaque PR sur les repos d'infra, bloquant sur les misconfigurations critiques (S3 public, IAM trop large, security group 0.0.0.0/0).
Le piège : autoriser tellement d'exceptions ("temporaire") qu'au bout de 6 mois la baseline est vidée de sens.
Comment je les enchaîne dans un pipeline
Pour une équipe qui démarre, voici le pipeline minimum que je pose en J1 :
`` PR → pre-commit (secrets scanning local) → CI build → SAST (Semgrep) — bloquant sur high/critical → SCA (Trivy ou Snyk) — bloquant sur CVE critique exploitable → Secrets scanning (Gitleaks) — bloquant si match → IaC scanning (Checkov) sur les dossiers terraform/k8s/ — bloquant sur critical → Merge si tout vert → CD vers staging → DAST (OWASP ZAP) en nightly sur staging — non bloquant, alerting → Tests E2E → Promotion vers prod → SBOM généré et stocké, signé → Signature du container (Cosign / Sigstore) ``
Tout ça est outillable en GitHub Actions, GitLab CI, ArgoCD ou équivalent. Le temps de mise en place initial : 5-15 jours-dev selon votre niveau de pipeline existant.
Les arbitrages à expliciter
Bloquant ou alerting ?
Tout bloquer dès le J1 = pipeline rouge en permanence, équipes qui contournent (skip CI). Tout en alerting = personne ne corrige.
Mon canevas : bloquant sur critical/high exploitables (SAST, secrets, SCA) + alerting graduel pour le reste, avec SLA de remédiation (high : 30 jours, medium : 90 jours). Et un sprint dédié tous les 3 mois pour vider la dette accumulée.
Tout en open-source ou outils managés ?
OSS = gratuit, contrôle total, mais coût d'intégration et de maintien. Managé = rapide à déployer, dashboards, mais coût récurrent et dépendance.
Pour une PME < 50 personnes : OSS partout. Pour une scale-up qui passe ISO 27001 / SOC 2 : managé sur SAST/SCA pour avoir le reporting compliance, OSS sur le reste.
Centralisé sur une plateforme ou stack composée ?
Les plateformes "tout-en-un" (Snyk, GitHub Advanced Security) simplifient le reporting. Mais elles sont souvent moins fortes que les outils spécialisés sur chaque famille. Si votre maturité est faible : plateforme. Si vous avez déjà une équipe sécu : stack composée.
L'angle sécurité IA — où ça s'arrête
Cette stack couvre l'application classique. Elle ne couvre pas :
- La sécurité des prompts et outputs LLM → outils dédiés (PyRIT, Promptfoo, voir stack outils sécurité IA).
- La sécurité du pipeline MLOps (datasets, modèles, fine-tunes) → voir pipeline MLOps sécurisé.
- L'isolation des tools côté agent IA → voir sécurité MCP.
Les deux stacks (DevSecOps classique + sécu IA) cohabitent dans le même pipeline mais répondent à des risques différents. Confondre les deux mène à des trous de couverture.
Mon avis en 1 ligne
Pas de stack magique. Le bon réflexe : commencer minimal (Semgrep + Gitleaks + Trivy + Checkov, tout en OSS, intégrés en bloquant sur critical), mesurer le bruit, ajuster. Puis monter d'un cran (DAST nightly, SBOM signé, reachability) quand la baseline est tenue. La sophistication vient après la discipline.