Analyse de code et sécurité applicative
Mise à jour :
En 2021, un chercheur découvre que le code source de Twitch a fuité sur Internet. Parmi les 125 Go de données : des clés API en clair, des tokens d’accès et des secrets de production directement commitées dans le code. Cette fuite massive illustre un problème récurrent : les développeurs sous-estiment ce que leur code révèle.
Analyser le code avant qu’il n’atteigne la production n’est plus optionnel. Entre les vulnérabilités introduites par inadvertance, les secrets exposés dans les commits et les dépendances obsolètes qui traînent, la surface d’attaque d’une application moderne est considérable.
Dans ce guide, je présente :
- Les trois familles d’analyse : SAST, DAST et SCA
- Les outils modernes pour chaque approche
- Comment intégrer ces analyses dans un pipeline CI/CD
- Les limites et complémentarités de chaque méthode
Pourquoi analyser le code ?
Le problème : des failles qui passent en production
Chaque ligne de code est une opportunité d’introduire une vulnérabilité. Une injection SQL oubliée, une validation d’entrée manquante, un secret hardcodé pour “tester rapidement”… Ces erreurs arrivent même aux équipes expérimentées.
Le coût de correction explose selon le moment de détection :
| Phase de détection | Coût relatif |
|---|---|
| Pendant le développement | 1x |
| Pendant les tests | 10x |
| En production | 100x |
| Après un incident | 1000x+ |
Détecter une faille pendant qu’on écrit le code coûte quelques minutes. La corriger après une compromission peut coûter des millions.
Les trois piliers de l’analyse
L’analyse de sécurité du code repose sur trois approches complémentaires :
- SAST (Static Application Security Testing) : analyse le code source sans l’exécuter
- DAST (Dynamic Application Security Testing) : teste l’application en cours d’exécution
- SCA (Software Composition Analysis) : analyse les dépendances et composants tiers
Aucune de ces approches n’est suffisante seule. C’est leur combinaison qui offre une couverture efficace.
SAST : l’analyse statique du code
Qu’est-ce que le SAST ?
L’analyse statique consiste à parcourir le code source pour y détecter des patterns problématiques : vulnérabilités connues, mauvaises pratiques, violations de règles de sécurité. Le code n’est jamais exécuté — l’outil analyse sa structure, son flux de données et ses appels.
Ce que le SAST détecte :
- Injections : SQL, XSS, command injection, LDAP injection
- Problèmes cryptographiques : algorithmes faibles, clés en dur
- Gestion des erreurs : exceptions non gérées, informations exposées
- Contrôle d’accès : vérifications manquantes, élévation de privilèges
- Secrets hardcodés : mots de passe, tokens, clés API dans le code
Le SAST couvre trois sous-domaines : l’analyse du code applicatif, le scan d’Infrastructure as Code (IaC) et la détection de secrets.
Outils SAST pour le code applicatif
Voici une sélection d’outils SAST populaires :
| Outil | Langages | Points forts | Licence |
|---|---|---|---|
| Semgrep | 30+ langages | Règles personnalisables, rapide, CI-friendly | Open source |
| CodeQL | Java, JS, Python, Go, C++ | Requêtes puissantes, intégré GitHub | Gratuit pour OSS |
| Bandit | Python | Spécialisé Python, simple à utiliser | Open source |
| SonarQube | 25+ langages | Qualité + sécurité, tableau de bord complet | Community/Commercial |
| Checkmarx | 25+ langages | Enterprise, très complet | Commercial |
Ma recommandation : utiliser Semgrep pour sa flexibilité et sa rapidité en CI/CD, complété par CodeQL sur les projets GitHub pour les analyses approfondies.
# Semgrep : scan rapide avec règles de sécuritésemgrep --config=p/security-audit .
# Bandit : scan Pythonbandit -r ./mon_projet -f json -o bandit-report.jsonOutils SAST pour l’Infrastructure as Code
L’analyse statique s’applique aussi aux fichiers de configuration d’infrastructure :
| Outil | Cibles | Points forts | Licence | |-------|--------|--------------|---------|| | Checkov | Terraform, K8s, Dockerfile, ARM | 1000+ règles, policies as code | Open source | | Dockle | Dockerfile | Best practices CIS, simple | Open source | | KICS | Multi-IaC | Large couverture, rapide | Open source | | tfsec | Terraform | Spécialisé Terraform, précis | Open source |
→ Guide Checkov | Guide Dockle
Outils SAST pour la détection de secrets
Les secrets hardcodés (clés API, tokens, mots de passe) sont une catégorie critique que le SAST détecte via des outils spécialisés :
| Outil | Points forts | Mode |
|---|---|---|
| Gitleaks | Rapide, règles complètes, pre-commit | Scan historique Git |
| TruffleHog | Détection entropie, vérification live | Scan Git + S3 + filesystems |
| detect-secrets | Léger, baseline pour réduire le bruit | Pre-commit, CI |
| git-secrets | Simple, AWS-focused | Pre-commit |
# Gitleaks : scanner l'historique completgitleaks detect --source . -v
# TruffleHog : scanner avec vérification des secrets actifstrufflehog git file://. --only-verified→ Guide Gitleaks | Guide TruffleHog
Avantages et limites du SAST
Avantages :
- Intervient tôt dans le cycle de développement (shift-left)
- Couvre tout le code, y compris le code mort
- Résultats reproductibles et traçables
- Facilite la formation des développeurs aux bonnes pratiques
- Fonctionne sans environnement d’exécution
Limites :
- Faux positifs fréquents (nécessite du tri)
- Ne détecte pas les vulnérabilités runtime ou de configuration
- Peut être lent sur de grosses bases de code
- Ne voit pas les problèmes liés à l’infrastructure ou au déploiement
DAST : les tests dynamiques de sécurité
Qu’est-ce que le DAST ?
Le DAST teste l’application en cours d’exécution, comme le ferait un attaquant. L’outil envoie des requêtes malformées, tente des injections, explore les endpoints et observe les réponses. C’est un test en boîte noire : on ne regarde pas le code source.
Ce que le DAST détecte :
- Vulnérabilités web : XSS réfléchi, CSRF, clickjacking
- Problèmes de configuration : headers manquants, cookies non sécurisés
- Erreurs d’authentification : sessions faibles, bypass d’auth
- Injection runtime : SQL, command injection exploitables
- Exposition d’informations : stack traces, version disclosure
Outils DAST modernes
| Outil | Type | Points forts | Licence |
|---|---|---|---|
| OWASP ZAP | Proxy + scanner | Référence open source, très complet | Open source |
| Burp Suite | Proxy + scanner | Fonctionnalités avancées, communauté active | Community/Pro |
| Nuclei | Scanner templates | Ultra-rapide, templates communautaires | Open source |
| Nikto | Scanner web | Simple, détection de misconfigs | Open source |
Ma recommandation : utiliser OWASP ZAP en mode automatisé dans la CI/CD pour les tests de base, complété par Burp Suite Pro pour les audits manuels approfondis.
# OWASP ZAP : scan automatisé en baselinedocker run -t owasp/zap2docker-stable zap-baseline.py \\ -t https://mon-app.example.com -r zap-report.html
# Nuclei : scan avec templates de vulnérabilitésnuclei -u https://mon-app.example.com -t cves/ -o nuclei-results.txtAvantages et limites du DAST
Avantages :
- Détecte les vulnérabilités réellement exploitables
- Indépendant du langage : teste l’application quelle que soit la stack
- Trouve les problèmes de configuration et d’environnement
- Vision attaquant : très formatrice pour les équipes
Limites :
- Nécessite une application déployée et accessible
- Intervient tard dans le cycle (coûts de correction plus élevés)
- Couverture limitée : ne teste que les endpoints atteints
- Peut perturber l’environnement testé (données, logs, alertes)
SCA : l’analyse des dépendances
Qu’est-ce que le SCA ?
Le SCA (Software Composition Analysis) analyse les bibliothèques et composants tiers utilisés par l’application. L’objectif est d’identifier :
- Les vulnérabilités connues (CVE) dans les dépendances
- Les licences incompatibles ou à risque juridique
- Les composants obsolètes ou non maintenus
- Les dépendances transitives (les dépendances de mes dépendances)
Une application moderne peut embarquer des centaines de dépendances. Chacune est un vecteur potentiel d’attaque si elle contient une faille non corrigée.
Outils SCA modernes
| Outil | Points forts | Intégration | Licence |
|---|---|---|---|
| Trivy | Multi-cibles (images, SBOM, IaC, code) | CI/CD native | Open source |
| Grype | Rapide, focus conteneurs | CLI, CI/CD | Open source |
| Dependency-Track | Plateforme de gestion continue | API, webhooks | Open source |
| Snyk | UX, remédiation guidée | IDE, CI/CD, GitHub | Freemium |
| OWASP Dependency-Check | Référence historique | CLI, plugins | Open source |
Ma recommandation : utiliser Trivy ou Grype en CI/CD pour le scan automatisé, et Dependency-Track pour centraliser et suivre les vulnérabilités dans le temps.
# Trivy : scan des dépendances d'un projettrivy fs --scanners vuln ./mon-projet
# Grype : scan depuis un SBOMgrype sbom:./sbom.cdx.json --fail-on high
# OWASP Dependency-Check : génération rapportdependency-check --project "Mon App" --scan ./src -f HTMLPour générer un inventaire complet (SBOM) des dépendances et l’exploiter avec ces outils, consulte le guide SBOM.
Avantages et limites du SCA
Avantages :
- Cartographie exhaustive des composants utilisés
- Corrélation avec les bases CVE mises à jour en continu
- Détection des risques licences (GPL, copyleft…)
- Visibilité sur les dépendances transitives
Limites :
- Faux positifs : une CVE présente n’est pas forcément exploitable
- Ne détecte que les vulnérabilités connues (pas les 0-days)
- Nécessite une gestion active (triage, priorisation)
- Volume d’alertes potentiellement écrasant sans VEX
Intégrer l’analyse dans la CI/CD
Pipeline type
Un pipeline DevSecOps intègre les analyses de sécurité à chaque étape :
# Exemple GitHub Actionsname: Security Pipelineon: [push, pull_request]
jobs: secrets-scan: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: fetch-depth: 0 - name: Gitleaks uses: gitleaks/gitleaks-action@v2
sast: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Semgrep uses: returntocorp/semgrep-action@v1 with: config: p/security-audit
sca: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Trivy uses: aquasecurity/trivy-action@master with: scan-type: 'fs' severity: 'HIGH,CRITICAL' exit-code: '1'Stratégie de gates
On ne peut pas tout bloquer du jour au lendemain. Une approche progressive :
| Phase | Comportement | Objectif |
|---|---|---|
| Observation | Scan, log, ne bloque pas | Établir une baseline |
| Warning | Alerte sur les nouvelles issues | Sensibiliser les équipes |
| Soft gate | Bloque les critiques uniquement | Empêcher les régressions graves |
| Hard gate | Bloque high+ sans exception | Maintenir un niveau de sécurité |
Gérer les faux positifs
Le problème de l’alert fatigue
Un scanner mal configuré peut remonter des centaines d’alertes. Si 80% sont des faux positifs, les équipes finissent par ignorer les vraies alertes. C’est l’alert fatigue.
Stratégies de réduction
- Baseline : ignorer les issues existantes, ne traiter que les nouvelles
- Suppression ciblée : marquer les faux positifs confirmés comme ignorés
- Règles personnalisées : ajuster la configuration aux spécificités du projet
- VEX pour le SCA : documenter les vulnérabilités non exploitables dans le contexte
Pour comprendre comment qualifier l’exploitabilité des vulnérabilités SCA, consulte la section VEX du guide SBOM.
Comprendre les scores de vulnérabilités
Quand un scanner remonte une CVE, il faut savoir la prioriser. Trois métriques sont essentielles :
- CVSS : score de sévérité théorique (0-10)
- EPSS : probabilité d’exploitation dans les 30 jours (0-100%)
- KEV : catalogue CISA des vulnérabilités activement exploitées
Pour aller plus loin
Après avoir compris les fondamentaux de l’analyse de sécurité, approfondis avec ces guides :
SAST (analyse statique)
- Scan IaC : Checkov pour Terraform, Kubernetes, Dockerfiles
- Scan Dockerfile : Dockle pour les best practices CIS
- Détection secrets Git : Gitleaks
- Vérification secrets live : TruffleHog
DAST (analyse dynamique)
- Scanner vulnérabilités : Nuclei pour les CVE et misconfigurations
SCA (dépendances)
- Scanner multi-cibles : Trivy pour images, code, IaC et SBOM
- Scanner conteneurs : Grype pour l’analyse des images Docker
- Plateforme de suivi : Dependency-Track
Gestion des vulnérabilités
- Comprendre les scores : CVE, CVSS et EPSS EPSS](/docs/securiser/analyser-code/cve/)
- Inventaire logiciel : SBOM
Sécurité supply chain
- Introduction : Sécurité de la supply chain
- Évaluation des projets : OpenSSF Scorecard
- Signature d’artefacts : Cosign
- Framework SLSA : SLSA
Conclusion
L’analyse de code n’est pas une case à cocher, c’est un processus continu. SAST, DAST et SCA se complètent pour couvrir différentes facettes de la sécurité applicative.
Ma checklist minimale :
- Secrets : scanner chaque commit avec Gitleaks ou TruffleHog
- SAST : analyser le code avec Semgrep ou CodeQL à chaque PR
- SCA : vérifier les dépendances avec Trivy ou Grype en CI/CD
- DAST : tester l’application déployée avec ZAP périodiquement
- Centraliser : utiliser Dependency-Track pour suivre les vulnérabilités
- Prioriser : utiliser CVSS, EPSS et le contexte pour trier les alertes
- Automatiser : intégrer progressivement des gates bloquants
La question n’est pas “faut-il analyser le code ?” mais “comment le faire efficacement sans noyer les équipes ?”. La clé est une intégration progressive et une gestion rigoureuse des faux positifs.