Tests de sécurité automatisés

Une faille critique publiée aujourd'hui a une probabilité médiane d'être exploitée en moins de cinq jours, selon les rapports de vulnérabilités 2025-2026. Pourtant, le délai moyen de remédiation d'une faille critique dépasse encore cinquante jours dans la plupart des organisations. Ce décalage entre la vitesse d'exploitation et la vitesse de correction est le problème que les tests de sécurité automatisés cherchent à résorber.

Quatre approches complémentaires

Chacune détecte des catégories de vulnérabilités différentes, à des moments différents du cycle. Comprendre leurs forces et leurs angles morts est la condition d'une stratégie efficace.

Quatre angles d'attaque du même problème.

Chaque famille a son moment : les déplacer ne les rend pas plus efficaces, seulement plus coûteuses.

SAST : analyse statique du code

Le SAST analyse le code sans l'exécuter : il en construit un modèle abstrait et y recherche des motifs connus de vulnérabilités.

Le point commun : ce sont des motifs lisibles dans le texte du code.

Stratégie recommandée : règles légères dans l'éditeur et en pré-commit, analyse complète en intégration.

DAST : tests dynamiques

Le DAST teste l'application en cours d'exécution : il simule les actions d'un attaquant — requêtes malformées, tentatives d'injection, exploration des points d'entrée.

Ces failles n'existent que lorsque l'application tourne, avec sa configuration réelle.

Ses limites sont symétriques : la couverture — il ne teste que ce qu'il atteint, et un point d'entrée non documenté sera ignoré —, la lenteur — un scan complet peut prendre des heures — et l'environnement — il faut une application déployée et fonctionnelle.

Les outils récents déduisent l'usage prévu d'une API depuis sa spécification, mais ne remplacent pas un test d'intrusion humain.

SCA : analyse des dépendances

Le code que vous écrivez représente souvent moins de 20 % de votre application le reste vient de dépendances. Chacune est un vecteur potentiel, et le rythme des incidents s'est nettement accéléré : le rapport 2026 de Sonatype recense plus de 454 000 nouveaux paquets malveillants publiés en 2025, portant le total cumulé bloqué à plus de 1,2 million — une hausse de 75 % en un an.

Cinq incidents, une même leçon : la confiance dans une dépendance est une décision, pas un état de fait.

Un bon outil ne dit pas seulement « cette bibliothèque a une faille » : il donne de quoi décider.

Toutes les vulnérabilités ne se valent pas : sans priorisation, une faille théorique coûte autant qu'une faille exploitée.

Fuzzing : injecter des données aléatoires

Le fuzzing consiste à envoyer des données aléatoires ou semi-aléatoires à une application pour provoquer des comportements inattendus : plantages, fuites mémoire, exceptions non gérées. Il trouve ce que les autres méthodes manquent — les cas limites (une chaîne de dix millions de caractères, un entier négatif là où on attend un positif), les vulnérabilités inconnues, puisqu'il ne cherche pas un motif connu, et la robustesse générale.

Gourmand en ressources : à réserver au code critique — analyseurs, cryptographie, validation d'entrées.

Orchestrer le tout dans le pipeline

La question n'est pas s'il faut intégrer ces tests, mais comment les orchestrer. Une intégration mal pensée génère plus de friction que de sécurité : bloquer chaque commit avec un scan complet ralentit l'équipe, un scan trop léger laisse passer l'essentiel.

{Pré-commit : le premier rempart, le plus à gauche.}
repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.28.0
    hooks:
      - id: gitleaks

{Intégration continue : analyse statique et dépendances sur chaque demande de fusion.}
security-scan:
  runs-on: ubuntu-latest
  permissions:
    contents: read
  steps:
    - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1  # v7.0.1
      with:
        persist-credentials: false

    - name: Analyse statique
      uses: semgrep/semgrep-action@713efdd345f3035192eaa63f56867b88e63e4e5d # v1
      with:
        config: p/security-audit

    - name: Analyse des dependances
      run: trivy fs --severity HIGH,CRITICAL --exit-code 1 .

{Recette et analyses nocturnes : ce qui est long ne bloque personne.}
dast-scan:
  needs: deploy-staging
  steps:
    - run: nuclei -u https://staging.example.com -t cves/ -severity critical,high

# Analyses profondes : la nuit, sans bloquer le développement
on:
  schedule:
    - cron: '0 2 * * *'

Mesurer l'efficacité

Mesurer évite de confondre l'activité — le nombre de scans lancés — et le résultat — les vulnérabilités réellement corrigées. Les rapports 2025-2026 situent le délai moyen de remédiation des failles critiques autour de 55 jours, et près d'un tiers des vulnérabilités restent ouvertes plus de 180 jours : ce sont ces chiffres qu'il s'agit de battre.

Cinq indicateurs qui mesurent des résultats, pas de l'activité.