Trouver une faille d’injection pendant la revue de code coûte quelques minutes ; la découvrir après une fuite de données coûte des semaines et parfois une notification à la CNIL. Le principe du « shift left » consiste à placer des contrôles de sécurité automatiques à chaque étape du développement. Trois familles d’outils en forment le socle : SAST, SCA et DAST. Le sujet est d’autant plus actuel que le code est de plus en plus écrit avec l’aide de l’IA : selon le rapport de Veracode publié fin juillet 2026, le code généré par les modèles d’IA ne réussit que 56 % des tests de sécurité en moyenne, un taux qui ne progresse plus.
L’essentiel en 30 secondes
- SAST (analyse statique) : lit le code source pour y trouver des motifs dangereux (injection, secrets, fonctions risquées).
- SCA (analyse de composition) : inventorie les dépendances et signale celles qui sont vulnérables ou malveillantes.
- DAST (analyse dynamique) : attaque l’application en fonctionnement, comme le ferait un attaquant, sans voir le code.
- Ajoutez la détection de secrets et l’analyse de l’infrastructure as code. Bloquez seulement sur les nouveaux problèmes graves, et traitez le reste en continu.
Trois approches complémentaires
| SAST | SCA | DAST | |
|---|---|---|---|
| Ce qui est analysé | Votre code source | Les bibliothèques tierces | L’application déployée |
| Moment | À chaque modification | À chaque modification et chaque jour | En recette, puis périodiquement |
| Forces | Localise précisément la ligne fautive, très tôt | Couvre la majorité du code réellement exécuté | Trouve les défauts de configuration et d’exécution réels |
| Limites | Faux positifs, ne voit pas la configuration du serveur | Ne voit pas vos propres erreurs | Tardif, couverture partielle, ne localise pas la cause |
| Outils open source | Semgrep, CodeQL, SonarQube Community | OSV-Scanner, Trivy, Dependabot, Dependency-Track | OWASP ZAP, Nuclei |
Ce que l’OWASP Top 10 2025 change
La nouvelle édition du Top 10 OWASP fait entrer une catégorie « défaillances de la chaîne d’approvisionnement logicielle » à la troisième place, et une catégorie nouvelle sur la mauvaise gestion des conditions exceptionnelles (erreurs, cas limites). Le contrôle d’accès défaillant reste en tête et la mauvaise configuration remonte au deuxième rang. Traduction outillage : le SCA et la sécurisation des pipelines ne sont plus optionnels, et le DAST garde toute sa place pour les configurations.
Un pipeline type
| Étape | Contrôles | Blocage |
|---|---|---|
| Poste du développeur | Détection de secrets avant commit, extension SAST dans l’éditeur | Secrets |
| Pull request | SAST sur les fichiers modifiés, SCA, secrets, analyse de l’infrastructure as code | Nouveaux problèmes critiques et élevés |
| Construction | Analyse de l’image, SBOM, signature | Vulnérabilités critiques corrigeables |
| Recette | DAST de base (passif), puis actif sur les parcours principaux | Failles graves confirmées |
| Production | Réanalyse quotidienne des dépendances, DAST périodique, test d’intrusion annuel | Alerte et correction planifiée |
Les commandes pour démarrer
# Secrets dans le dépôt (historique Git compris)
gitleaks git --redact .
# SAST avec les règles OWASP de Semgrep
semgrep scan --config p/owasp-top-ten --error
# SCA : dépendances vulnérables
osv-scanner scan source -r .
# Infrastructure as code (Dockerfile, Kubernetes, Terraform)
trivy config .
# DAST de base sur l'environnement de recette
docker run --rm -t ghcr.io/zaproxy/zaproxy:stable zap-baseline.py -t https://recette.exemple.frNe lancez jamais un DAST actif sur un site de production sans accord : il envoie de vraies charges d’attaque et peut créer des données ou provoquer des erreurs.
Faire accepter les outils par les développeurs
- Bloquer peu, mais bien : seulement les nouveaux problèmes graves. Le stock existant est traité dans un plan à part.
- Trier les faux positifs et les documenter dans l’outil (avec justification), pour qu’ils ne reviennent pas.
- Résultats dans la pull request, là où travaille le développeur, plutôt que dans un rapport PDF.
- Mesurer le délai de correction par niveau de gravité, pas seulement le nombre d’alertes.
- Former : chaque type de faille trouvé est l’occasion d’un rappel concret.
Le cas du code généré par l’IA
Le rapport 2026 de Veracode note que les modèles produisent du code qui compile presque toujours, mais échoue à environ 44 % des tests de sécurité lorsqu’aucune consigne de sécurité ne leur est donnée, avec de fortes différences selon les langages (63 % de réussite en Python, 30 % en Java). Conséquences pratiques :
- traitez le code généré comme celui d’un développeur débutant : revue humaine et analyses automatiques systématiques ;
- donnez aux assistants de code des consignes de sécurité explicites (requêtes paramétrées, validation des entrées, pas de secrets en dur) ;
- vérifiez que les dépendances suggérées existent réellement : les noms inventés par l’IA sont parfois enregistrés par des attaquants.
Pour les API, croisez ces contrôles avec les quatre piliers d’une API sûre ; pour les dépendances, voir l’automatisation des alertes.
Questions fréquentes
Par quoi commencer avec un petit budget ?
Détection de secrets et SCA d’abord : c’est rapide à mettre en place, peu bruyant et cela couvre les risques les plus fréquents. Ajoutez ensuite le SAST, puis un DAST de base en recette.
Ces outils remplacent-ils un test d’intrusion ?
Non. Ils trouvent les défauts connus et répétitifs ; un auditeur trouve les failles de logique métier, comme un contrôle d’accès mal pensé, que les outils voient rarement.
Faut-il des outils commerciaux ?
Les outils open source cités couvrent l’essentiel pour une PME. Les offres commerciales apportent surtout la centralisation, le tri assisté et le support.
Quelle place pour l’IA dans la correction ?
Les assistants proposent des correctifs utiles, mais chaque correctif doit être relu et repasser les mêmes contrôles que le reste du code.
Sources
- Veracode, rapport 2026 sur la sécurité du code généré par l’IA, 28 juillet 2026.
- OWASP, Top 10 2025.
- OWASP ZAP, analyse de base en Docker.
- Semgrep, documentation.
Besoin d’un accompagnement ?
MPCÂBLE Solutions Informatiques (MPCSI) accompagne particuliers, entreprises, associations et collectivités depuis Gaudiès, en Ariège : sur site en Occitanie, principalement dans un rayon de 40 km (Pamiers, Foix, Mirepoix, Saverdun, Castelnaudary), et à distance partout en France. Nous auditons la sécurité de vos applications lors d’un audit. Demandez un devis gratuit ou appelez le 05 32 42 99 98.
