du code généré par IA échoue au test de sécurité
Testé sur plus de 100 modèles et 80 tâches de développement. Pour Java, le taux d'échec atteint 72 pour cent.
Veracode GenAI Code Security ReportAI Code Security · AI SAST · validation d'exploitabilité
La sécurité du code à l'ère de l'IA
Les scanners à base de règles trouvent toujours ce pour quoi ils ont été conçus : les erreurs de syntaxe. Ce qui fait mal aujourd'hui — autorisation cassée, logique métier, permissions supposées à tort — n'a pas de signature. Nous mettons règles, raisonnement IA et validation d'exploitabilité dans un ordre que vos équipes peuvent réellement exploiter.
- État des lieux en deux semaines, résultat solide en 90 jours
- Neutres en outillage : nous évaluons votre stack, nous n'en vendons pas
- Des preuves qui tiennent en audit CRA, NIS2 et client
Quatre chiffres qui décrivent la situation
Tous issus de sources primaires et d'opérateurs accessibles publiquement. Ensemble, ils expliquent pourquoi volume et vitesse sont devenus un problème simultané.
Broken Access Control reste en tête du Top 10 OWASP
L'édition 2025 couvre explicitement BOLA et BFLA — précisément les défauts qu'aucun motif ne sait exprimer.
OWASP Top 10:2025des failles exploitées connues sont attaquées le jour de leur publication
Part des entrées KEV avec exploitation le jour de la publication du CVE ou avant, premier semestre 2026.
Catalogue KEV de la CISAdes CVE entrants sont encore entièrement enrichis
La NVD fonctionne en mode triage depuis avril 2026. Attendre des bases complètes n'est plus une stratégie.
NIST sur la transition NVDUn scanner lit la syntaxe. Un attaquant lit l'intention.
La différence n'est pas un problème d'outil mais de classe de défaut. Les deux exemples viennent de la même application.
pythonDÉTECTÉ
# Findet jede Regel-Engine seit 2005query = "SELECT * FROM users WHERE id=" + req.iddb.execute(query)# → CWE-89 · SQL Injection · deterministisch erkennbar
Une requête SQL concaténée a une forme stable. C'est exactement ce pour quoi les règles sont faites : rapides, reproductibles et assez économiques pour tourner à chaque commit. Personne ne remplace cette couche.
C'est pourquoi nous ne remplaçons rien. Nous ajoutons une seconde couche capable de raisonner sur l'intention.
Trois couches plutôt qu'un outil
Chaque couche a sa classe de défauts, sa cadence et son prix. Sélectionnez une couche pour voir sa règle d'emploi.
Layer 2
AI SAST à raisonnement sémantique
- Ce qu'elle trouve
- Défauts dépendants de l'intention : autorisation cassée, IDOR et BOLA, logique métier, isolation locataire absente.
- Où elle tourne
- Ciblée sur les dépôts à forte valeur : services exposés, authentification, tout ce qui touche des données personnelles ou de paiement.
- Ce qu'elle coûte
- Coût moyen. L'effort se justifie par la classe de défaut, pas par le volume.
Plus rapide, moins cher, syntaxiquePlus lent, plus cher, plus profond
La question n'est jamais « quelle couche » mais « quelle couche sur quel dépôt à quelle cadence ». C'est précisément cette affectation que nous construisons avec vous — à partir de l'exposition et de la classe de données, pas à l'intuition.
L'atteignabilité est une hypothèse. L'exploitabilité est une preuve.
Quatre étapes séparent un extrait de code signalé d'un risque réel. Les sauter, c'est prioriser au feeling.
- 01
Finding
Une règle ou un modèle signale un endroit du code. À ce stade, ce n'est rien de plus.
- 02
Atteignabilité
L'endroit signalé se trouve sur un chemin appelable depuis l'extérieur.
- 03
Exposition
Le service est réellement joignable : chemin réseau, identité, configuration.
- 04
Exploitabilité
L'attaque a été menée contre l'environnement en fonctionnement et elle a abouti. À partir d'ici, ce n'est plus un soupçon.
- 05
Impact
Ce qui se trouve derrière le chemin décide de l'ordre de correction.
Pourquoi cela fait économiser
Chaque étape sautée sans preuve crée du travail au mauvais endroit. Un constat classé critique sans chemin d'attaque coûte des heures réelles à une équipe de développement et érode la confiance dans le constat suivant. À l'inverse, un chemin prouvé justifie l'arrêt immédiat d'une livraison. On ne peut distinguer les deux que si la validation fait partie du processus et non du débat.
Ce que nous prenons en charge
Nous ne construisons pas d'organisation parallèle. Nous remettons votre chaîne d'outils dans un ordre tenable — et assumons les parties qui exigent une expertise.
Architecture de scanning & évaluation d'outils
Avant d'ajouter un outil de plus, nous clarifions quelle couche a du sens sur quel dépôt.
- Classer les dépôts par exposition et classe de données
- Comparaison neutre de votre stack existante
- Modèle de cadence et de coûts par couche
Introduire et calibrer l'AI SAST
L'analyse sémantique ne vaut que ses critères d'acceptation. Nous les définissons avant la première exécution.
- Pilote sur des dépôts définis
- Calibrage contre des constats connus et déjà corrigés
- Critères d'acceptation plutôt que métriques éditeur
Validation d'exploitabilité & contre-épreuve
Nous vérifions sur le système en fonctionnement si un constat mène vraiment à un chemin d'attaque.
- Preuve sur le système, pas sur un schéma
- Chaîne de preuve par chemin confirmé
- Transmission au développement avec étapes de reproduction
Revue de code pour code généré par IA
Le code d'assistant échoue dans des classes prévisibles. C'est précisément là que la revue commence.
- Autorisation, isolation locataire, gestion d'erreurs
- Guide de revue pour vos code owners
- Risques d'agents et de prompts dans le dépôt lui-même
Remédiation & responsabilité
Le constat le plus abouti ne sert à rien si personne n'est désigné. Nous fermons l'écart entre découverte et correction.
- Cartographie des code owners jusqu'à la personne
- Propositions de correction en pull request
- SLA selon l'exploitabilité et non le seul CVSS
Preuves pour CRA, NIS2 et audits clients
Les mêmes artefacts portent l'audit, le questionnaire client et la preuve d'incident — à condition d'être produits ainsi dès le départ.
- Rapports d'essai pour la documentation technique
- Dette de sécurité avec échéance plutôt que liste d'exceptions
- Indicateurs d'effet plutôt que d'activité
Quatre phases vers un résultat solide
Pas de changement de plateforme, pas de big bang. La démarche fonctionne avec ce dont la plupart des organisations disposent déjà.
- Phase 1 · 2 semaines
État des lieux
Nous examinons dépôts, scanners existants, historique des constats et responsabilités. Résultat : une classification par exposition et classe de données — et une ligne de base honnête.
- Phase 2 · 4 semaines
Pilote
AI SAST sur les dépôts les plus critiques, calibré sur des constats connus. En parallèle les premières validations : quels chemins sont réellement atteignables ?
- Phase 3 · 6 semaines
Ancrage
Gates dans le build, propositions de correction aux code owners, SLA selon l'exploitabilité. Les exceptions sont documentées et reçoivent une date d'expiration.
- Phase 4 · en continu
Exploitation
Analyse frontière périodique pour les applications les plus critiques, reporting d'indicateurs, ajustements. En service managé sur demande.
Ce qui reste sur la table
Des artefacts réutilisables — dans le sprint, dans l'audit et dans le questionnaire client.
Registre de risque des dépôts
Tous les dépôts par exposition, classe de données et responsabilité — la base de toute décision de cadence.
Cible de scanning
Quelle couche sur quel dépôt à quelle fréquence, avec estimation de coût et de durée.
Liste de constats validés
Chemins d'attaque confirmés avec chaîne de preuve et étapes de reproduction — nettement séparés des pistes non confirmées.
Paquets de correction
Propositions à la racine, livrées si possible en pull request aux code owners concernés.
Rapports d'essai et d'évaluation
Dans une forme qui s'intègre à la documentation technique exigée par l'annexe I du CRA.
Rapport d'indicateurs
Part des constats validés, délai découverte–correction, taux d'attribution et dette de sécurité par ancienneté.
Le raccordement aux normes et à la réglementation
Nous travaillons le long de références établies — pour que les résultats convainquent en interne et se prouvent en externe.
EU Cyber Resilience Act
L'annexe I partie II exige un traitement efficace des vulnérabilités sur la période de support ; les rapports d'essai relèvent de la documentation technique.
Règlement (UE) 2024/2847OWASP Top 10:2025
A01 Broken Access Control reste en tête et couvre explicitement BOLA et BFLA. Nouveau en A03 : Software Supply Chain Failures.
owasp.orgOWASP ASVS
Des exigences testables plutôt que des avis : les niveaux de vérification donnent un périmètre défini à la revue et aux tests.
Verification StandardNIST SSDF · SP 800-218
Le cadre de référence des pratiques de développement sécurisé que clients et autorités citent de plus en plus.
csrc.nist.govSLSA
Intégrité de la chaîne d'approvisionnement du source à l'artefact — la couche que l'analyse de code seule ne couvre pas.
slsa.devOWASP SAMM
Modèle de maturité du travail de sécurité : rend le progrès comparable dans le temps et pas seulement rapportable.
owaspsamm.orgLes preuves à consulter
Les affirmations de cette page s'appuient sur des sources primaires et d'opérateurs accessibles publiquement. Les voici dans leur version originale.
- DARPA AI Cyber ChallengeRésultats de la finale 2025 : des systèmes autonomes sur 54 millions de lignes de code.
- Google Project Zero · Big SleepComment un agent IA trouve des vulnérabilités dans du code open source réel.
- VulnCheck State of ExploitationÀ quelle vitesse les vulnérabilités publiées sont réellement exploitées.
- FIRST EPSSPriorisation probabiliste en complément de la seule sévérité.
- CWE Top 25Les classes de faiblesses les plus fréquentes — référence pour la couverture des règles.
- OpenSSF ScorecardÉvaluation automatisée des pratiques de sécurité des dépendances open source.
Approfondir
Pages de connaissance gratuites du domaine Secure Software Development — sans formulaire, sans inscription.
Parlons de vos dépôts.
30 minutes, sans argumentaire commercial. Nous déterminons ensemble quelle couche fait la plus grande différence chez vous — et ce que vous pouvez laisser de côté.