Analyse de code et sécurité applicative

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.

Pourquoi analyser le code ?

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 :

Approche	Cible	Moment	Ce qu’elle détecte
SAST	Code source	Développement	Injections, secrets, mauvaises pratiques
DAST	Application déployée	Staging/Prod	Failles exploitables, misconfigurations
SCA	Dépendances	Build	CVE dans les bibliothèques tierces

Aucune de ces approches n’est suffisante seule. C’est leur combinaison qui offre une couverture efficace.

SAST : analyse statique Scanner le code source pour détecter vulnérabilités, secrets et mauvaises configurations.

DAST : tests dynamiques Tester l'application en cours d'exécution comme le ferait un attaquant.

SCA : analyse des dépendances Identifier les CVE dans les bibliothèques et composants tiers.

Comprendre les CVE Interpréter CVSS, EPSS et KEV pour prioriser les vulnérabilités.

Quand utiliser chaque approche

SAST : pendant le développement

Le SAST (Static Application Security Testing) analyse le code sans l’exécuter. Il parcourt le code source, suit les flux de données et identifie les patterns problématiques.

Cas d’usage :

• Scanner chaque pull request avant merge
• Détecter les secrets dans l’historique Git
• Valider les fichiers IaC (Terraform, Kubernetes)
• Bloquer les commits avec des failles critiques

Outils : Semgrep, CodeQL, Checkov, Gitleaks, TruffleHog

→ Guide complet SAST

DAST : après déploiement

Le DAST (Dynamic Application Security Testing) teste l’application en cours d’exécution. Il envoie des requêtes malformées, tente des injections et analyse les réponses.

Cas d’usage :

• Scanner l’environnement de staging avant production
• Détecter les CVE connues sur des services exposés
• Valider la configuration des headers de sécurité
• Tester les mécanismes d’authentification

Outils : OWASP ZAP, Nuclei, Burp Suite, Nikto

→ Guide complet DAST

SCA : pendant le build

Le SCA (Software Composition Analysis) analyse les dépendances pour identifier les vulnérabilités connues dans les composants tiers.

Cas d’usage :

• Scanner les dépendances à chaque build
• Générer un inventaire logiciel (SBOM)
• Surveiller les nouvelles CVE sur les projets déployés
• Bloquer les versions avec des failles critiques

Outils : Trivy, Grype, Dependency-Track, Snyk

→ Guide complet SCA

Intégrer l’analyse dans la CI/CD

Pipeline type

Un pipeline DevSecOps intègre les analyses de sécurité à chaque étape :

# Exemple GitHub Actions
name: Security Pipeline
on: [push, pull_request]

jobs:
  secrets-scan:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
        with:
          fetch-depth: 0
      - name: Gitleaks
        uses: gitleaks/gitleaks-action@ff98106e4c7b2bc287b24eaf42907196329070c7 # v2.3.9

  sast:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - name: Semgrep
        uses: returntocorp/semgrep-action@713efdd345f3035192eaa63f56867b88e63e4e5d # v1
        with:
          config: p/security-audit

  sca:
    runs-on: ubuntu-24.04
    steps:
      - uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683 # v4.2.2
      - name: Trivy
        uses: aquasecurity/trivy-action@6c175e9c4083a92bbca2f9724c8a5e33bc2d97a5 # 0.30.0
        with:
          scan-type: 'fs'
          severity: 'HIGH,CRITICAL'
          exit-code: '1'

Stratégie de gates progressive

On ne peut pas tout bloquer du jour au lendemain. Une approche graduée :

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 — et c’est dangereux.

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

Chaque guide dédié (SAST, DAST, SCA) détaille les techniques de gestion des faux positifs spécifiques à chaque approche.

Checklist minimale

1. Secrets : scanner chaque commit avec Gitleaks ou TruffleHog
2. SAST : analyser le code avec Semgrep ou CodeQL à chaque PR
3. SCA : vérifier les dépendances avec Trivy ou Grype en CI/CD
4. DAST : tester l’application déployée avec ZAP ou Nuclei
5. Centraliser : utiliser Dependency-Track pour suivre les vulnérabilités
6. Prioriser : utiliser CVSS, EPSS et le contexte pour trier les alertes
7. Automatiser : intégrer progressivement des gates bloquants

Guides détaillés

Comprendre les approches

SAST Analyse statique du code source, IaC et secrets.

DAST Tests dynamiques sur application déployée.

SCA Analyse des vulnérabilités dans les dépendances.

CVE, CVSS, EPSS Comprendre et prioriser les vulnérabilités.

Outils SAST

Semgrep Analyse statique polyvalente avec règles personnalisables.

Checkov Scanner IaC : Terraform, Kubernetes, Dockerfile.

Dockle Linter de sécurité pour images Docker.

Gitleaks Détection de secrets dans le code et l'historique Git.

TruffleHog Scanner de secrets avec vérification live.

Outils DAST

Nuclei Scanner ultra-rapide basé sur templates.

Outils SCA

Trivy Scanner polyvalent : images, code, IaC, SBOM.

Grype Scanner de vulnérabilités pour images et SBOM.

Dependency-Track Plateforme de gestion continue des vulnérabilités.

Supply chain

Sécurité supply chain Protéger la chaîne d'approvisionnement logicielle.

SBOM Générer et exploiter un inventaire logiciel.

Ressources externes

• OWASP Testing Guide ↗
• OWASP Code Review Guide ↗
• CWE - Common Weakness Enumeration ↗