Tests de sécurité automatisés

En 2023, une étude de Snyk révèle que 84% des applications contiennent au moins une vulnérabilité connue dans leurs dépendances. Plus inquiétant : le temps moyen pour corriger une vulnérabilité critique est de 246 jours. Ces chiffres illustrent un décalage fondamental entre la vitesse de développement et la capacité à sécuriser le code.

La bonne nouvelle : l’automatisation des tests de sécurité permet de réduire drastiquement ce délai. L’enjeu n’est plus de choisir entre vélocité et sécurité, mais de les intégrer dans un même flux continu.

Les quatre piliers des tests de sécurité

L’analyse de sécurité repose sur quatre approches complémentaires. Chacune détecte des catégories de vulnérabilités différentes, à des moments différents du cycle de développement. Comprendre leurs forces et limites est essentiel pour construire une stratégie efficace.

Approche	Cible	Moment	Ce qu’elle détecte	Limites
SAST	Code source	Développement	Injections, secrets, patterns dangereux	Faux positifs, contexte d’exécution ignoré
DAST	Application déployée	Staging/Prod	Failles exploitables, misconfigurations	Couverture limitée, lent
SCA	Dépendances	Build	CVE dans les bibliothèques tierces	Ne détecte que les vulnérabilités connues
Fuzzing	Entrées/APIs	Tests	Comportements inattendus, crashs, edge cases	Gourmand en ressources

SAST : analyse statique du code source

Le SAST (Static Application Security Testing) analyse le code sans l’exécuter. Il parse le code source, construit un modèle abstrait et recherche des patterns connus de vulnérabilités.

Ce que SAST détecte

Le SAST excelle à trouver certaines catégories de problèmes :

Catégorie	Exemples	Pourquoi SAST est efficace
Injections	SQL, XSS, Command injection	Patterns reconnaissables : concaténation de strings avec input utilisateur
Secrets hardcodés	API keys, tokens, passwords	Patterns regex : `password = "..."`, formats connus (AWS, GitHub)
Crypto faible	MD5, SHA1, DES	Appels à des fonctions connues comme obsolètes
Mauvaises pratiques	`eval()`, `exec()`, désérialisation non sécurisée	Fonctions spécifiques blacklistées

Limites du SAST

Le SAST a des angles morts importants :

Contexte d’exécution : Le code user_input = request.get('name') suivi de db.query(f"SELECT * FROM users WHERE name = '{user_input}'") est une injection SQL évidente. Mais si l’input est validé trois fichiers plus loin, SAST peut ne pas faire le lien.
Faux positifs : Sans contexte, SAST signale des problèmes qui n’en sont pas. Un eval() utilisé sur une constante n’est pas dangereux.
Logique métier : SAST ne comprend pas que “un utilisateur ne devrait pas pouvoir voir les commandes d’un autre”.

Intégration dans le cycle

Le SAST s’intègre à plusieurs niveaux du cycle de développement :

Point d’intégration	Avantage	Inconvénient
IDE (temps réel)	Feedback immédiat, contexte frais	Peut ralentir l’éditeur
Pre-commit	Bloque avant le push	Peut frustrer si trop strict
CI (Pull Request)	Revue systématique	Feedback plus tardif
Scheduled (nightly)	Analyse approfondie	Détection retardée

DAST : tests dynamiques en exécution

Le DAST (Dynamic Application Security Testing) teste l’application en cours d’exécution. Il simule les actions d’un attaquant : envoie des requêtes malformées, tente des injections, explore les endpoints.

Ce que DAST détecte

Le DAST trouve ce que le SAST manque :

Catégorie	Exemples	Pourquoi DAST est nécessaire
Injections exploitables	SQL, XSS qui passent vraiment	Valide que la faille est réellement exploitable
Misconfigurations	Headers manquants, CORS permissif	Configuration runtime, pas dans le code
Authentification faible	Session fixation, tokens prédictibles	Comportement runtime
Fuites d’information	Stack traces, versions exposées	Réponses HTTP réelles

Limites du DAST

Le DAST a aussi ses angles morts :

Couverture : Il ne teste que ce qu’il peut atteindre. Un endpoint non documenté ou une fonctionnalité derrière une authentification complexe peut être ignoré.
Lenteur : Contrairement au SAST qui analyse du texte, le DAST envoie des requêtes réelles. Un scan complet peut prendre des heures.
Environnement : Il faut une application déployée et fonctionnelle. Impossible de tester du code non encore intégré.

Quand utiliser DAST

Le DAST s’utilise plus tard dans le cycle que le SAST :

Environnement	Usage	Fréquence
Développement local	Tests ciblés sur nouvelles fonctionnalités	À la demande
Staging/Pre-prod	Scan complet avant release	Chaque release candidate
Production	Monitoring continu, pentest	Hebdomadaire/mensuel

SCA : analyse des dépendances

Le SCA (Software Composition Analysis) analyse les bibliothèques tierces utilisées par votre application. Il compare vos dépendances aux bases de données de vulnérabilités connues (CVE). C’est un pilier critique du DevSecOps moderne.

Pourquoi SCA est critique

Le code que vous écrivez représente souvent moins de 20% de votre application. Le reste vient de dépendances : frameworks, bibliothèques, utilitaires. Chaque dépendance est un vecteur potentiel de vulnérabilités.

Exemples récents marquants :

Log4Shell (2021) : Vulnérabilité dans Log4j, présente dans des millions d’applications Java
Spring4Shell (2022) : Faille dans Spring Framework, framework Java le plus utilisé
Polyfill.io (2024) : Supply chain attack via un CDN JavaScript largement utilisé

Ce que SCA détecte

Information	Description	Utilité
CVE	Vulnérabilités publiées avec identifiant unique	Identifier les failles connues
CVSS	Score de sévérité (0-10)	Prioriser par criticité
EPSS	Probabilité d’exploitation (0-100%)	Prioriser par risque réel
Licence	Type de licence (MIT, GPL, propriétaire)	Conformité juridique
Dépendances transitives	Dépendances de vos dépendances	Visibilité sur la supply chain

Stratégie de priorisation

Toutes les CVE ne se valent pas. Une stratégie efficace priorise selon plusieurs critères :

Priorité	Critères	Action
P0 - Critique	CVSS ≥ 9.0 ET (EPSS > 10% OU KEV)	Patch immédiat, bloquer le déploiement
P1 - Haute	CVSS ≥ 7.0 ET dépendance directe	Patch sous 7 jours
P2 - Moyenne	CVSS ≥ 4.0 OU dépendance transitive critique	Patch sous 30 jours
P3 - Basse	CVSS < 4.0, pas d’exploit connu	Inclure dans maintenance régulière

Fuzzing : tests par injection de données aléatoires

Le fuzzing (ou fuzz testing) consiste à envoyer des données aléatoires ou semi-aléatoires à une application pour provoquer des comportements inattendus : crashs, fuites mémoire, exceptions non gérées.

Pourquoi fuzzer

Le fuzzing trouve ce que les autres méthodes manquent :

Edge cases : Que se passe-t-il avec une string de 10 millions de caractères ? Un entier négatif là où on attend un positif ?
Vulnérabilités inconnues : Contrairement au SAST/SCA qui cherchent des patterns connus, le fuzzing peut découvrir des vulnérabilités nouvelles (0-days).
Robustesse : Au-delà de la sécurité, le fuzzing améliore la qualité générale en trouvant des bugs de stabilité.

Types de fuzzing

Type	Description	Exemple
Dumb fuzzing	Données totalement aléatoires	Bytes aléatoires envoyés à un parser
Smart fuzzing	Données aléatoires respectant un format	JSON valide avec valeurs aléatoires
Coverage-guided	Adapte les inputs pour explorer plus de code	AFL, libFuzzer
API fuzzing	Teste les endpoints REST/GraphQL	Burp, RESTler

Quand utiliser le fuzzing

Le fuzzing est gourmand en ressources. Il est particulièrement pertinent pour :

Code critique : Parsers, cryptographie, validation d’entrées
Bibliothèques partagées : Code utilisé par de nombreux projets
Avant release majeure : Validation approfondie
Nightly builds : En parallèle du développement

Intégration dans le pipeline CI/CD

La question n’est pas si intégrer ces tests, mais comment les orchestrer efficacement. Voici une stratégie éprouvée :

Pre-commit : détection de secrets

Premier rempart, le plus à gauche. Bloque les commits contenant des secrets avant qu’ils n’atteignent le dépôt.
.pre-commit-config.yaml
```
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.0
    hooks:
      - id: gitleaks
```

CI (Pull Request) : SAST + SCA

Chaque PR est analysée automatiquement. Les vulnérabilités critiques bloquent le merge.

# GitHub Actions
security-scan:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4

    # SAST avec Semgrep
    - name: Run Semgrep
      uses: returntocorp/semgrep-action@v1
      with:
        config: p/security-audit

    # SCA avec Trivy
    - name: Run Trivy
      run: |
        trivy fs --severity HIGH,CRITICAL --exit-code 1 .

Staging : DAST

Une fois l’application déployée en staging, les tests dynamiques peuvent s’exécuter.

dast-scan:
  needs: deploy-staging
  runs-on: ubuntu-latest
  steps:
    - name: DAST scan
      run: |
        nuclei -u https://staging.example.com -t cves/ -severity critical,high

Nightly : fuzzing et scans approfondis

Les analyses longues s’exécutent la nuit, sans bloquer le développement.

on:
  schedule:
    - cron: '0 2 * * *'  # Tous les jours à 2h

jobs:
  deep-scan:
    # Analyse complète, tous les seuils

Métriques à suivre

Pour évaluer l’efficacité de vos tests de sécurité, suivez ces métriques :

Métrique	Description	Cible
MTTD (Mean Time To Detect)	Délai entre introduction et détection	< 24h pour critique
MTTR (Mean Time To Remediate)	Délai entre détection et correction	< 7 jours pour critique
Taux de faux positifs	Alertes non pertinentes	< 10%
Couverture	% du code analysé par SAST	> 90%
Dette de vulnérabilités	Vulnérabilités connues non corrigées	Tendance descendante

À retenir

SAST : Analyse le code source, rapide, beaucoup de faux positifs → développement
DAST : Teste l’application réelle, lent, peu de faux positifs → staging/prod
SCA : Analyse les dépendances, critique pour la supply chain → CI/CD
Fuzzing : Trouve les edge cases et 0-days → nightly/release
Combinaison : Aucune approche n’est suffisante seule

Mettre en pratique

Shift-left Déplacer les tests de sécurité au plus tôt dans le cycle.

Pipeline sécurisé Construire un pipeline CI/CD avec security gates intégrés.

Guides d'implémentation SAST, DAST, SCA : guides pas à pas avec les outils.