La sécurité du code généré par IA est devenue un sujet d’audit dédié en 2026. Les PR (Pull Requests) rédigées avec Copilot, Claude Code ou Cursor entrent en production tous les jours, et elles introduisent des classes de vulnérabilités spécifiques : dépendances hallucinées, secrets en clair recopiés depuis des exemples, validation lâche par défaut, boilerplate sécu daté. Cet article livre un protocole en sept contrôles à appliquer sur toute PR IA-aware, avec les outils 2026 et un workflow GitHub Actions complet à intégrer en CI sans tout bloquer.
Pourquoi le code IA mérite un audit dédié
Le modèle ne « connaît » pas votre projet. Il complète des patterns vus pendant l’entraînement, qui datent souvent de 2022-2024. Trois conséquences : il propose des bibliothèques qui n’existent pas, il copie du code-exemple où les secrets sont en clair pour la lisibilité, et il reproduit des patterns OWASP (Open Web Application Security Project) considérés vulnérables aujourd’hui. Une revue humaine standard ne capte pas ces signaux : ils ressemblent à du code propre. Un protocole dédié s’impose.
L’OWASP Top 10 for LLM Applications (édition 2025) référence ces classes de risque côté applicatif. Pour les fondamentaux web, voyez aussi notre OWASP Top 10 2026 et, sur le versant performance et infrastructure, notre Core Web Vitals 2026 (pilier dev-moderne).
Les 5 classes de vulnérabilités spécifiques
Dépendances hallucinées (slopsquatting)
Le slopsquatting est un terme apparu en 2025 pour désigner l’enregistrement par un attaquant de noms de packages que les LLM hallucinent souvent. Un modèle suggère npm install request-promise-async-v2 ; le package n’existe pas, mais un attaquant l’a enregistré sur npm, contenant un payload malveillant. Le développeur l’installe sans réfléchir. C’est la chaîne d’attaque type 2025-2026, déjà documentée par plusieurs chercheurs et reprise par OWASP.
Validation lâche par défaut
L’IA produit souvent des handlers Express ou FastAPI qui acceptent un objet JSON sans validation de type, sans schéma Zod ou Pydantic, sans whitelist des champs autorisés. Le résultat : mass assignment, contournement des règles métier, injection de propriétés inattendues. La validation par défaut doit être stricte ; toute dérogation doit être justifiée.
Secrets en clair dans les exemples copiés
Les exemples de documentation contiennent des clés type sk_test_xxx ou YOUR_API_KEY_HERE. L’IA les recopie tels quels, parfois en oubliant le placeholder. Une fois pushé, le secret est public. Détectable trivialement par un scan, mais encore trop souvent absent du pipeline CI.
Boilerplate sécu obsolète
L’IA propose toujours du md5 ou du sha1 pour hasher des mots de passe parce que ces patterns saturent ses corpus d’entraînement. Elle propose jsonwebtoken sans jose alors que la première bibliothèque a accumulé les CVE. Elle suggère des en-têtes CORS permissifs « pour le dev » qui passent en prod. Le boilerplate vieillit ; l’IA suit ce vieillissement avec retard.
Logique d’authz incomplète
L’IA implémente correctement l’authentification (qui êtes-vous), bien moins l’autorisation (avez-vous le droit). Une route GET /orders/:id qui vérifie qu’un user est connecté mais pas que l’order lui appartient : c’est l’IDOR (Insecure Direct Object Reference) classique, et c’est la première faille découverte sur les apps livrées avec génération IA massive.
Le protocole d’audit en 7 contrôles
Contrôle 1 — Audit des dépendances
Toute nouvelle dépendance dans package.json, requirements.txt ou Cargo.toml est suspecte. Vérifier : existence sur le registre officiel, statistiques de téléchargement (un package à 12 downloads/jour est un drapeau rouge), date de publication, mainteneurs identifiables, dépendances transitives. Outils : OSV-Scanner, Trivy, npm-audit, Dependabot.
Contrôle 2 — Scan de secrets
gitleaks ou TruffleHog en pre-commit hook et en CI. Bloquer le push si un secret est détecté, avec rotation immédiate de toute clé qui a transité par un commit même non poussé. Le hash du commit suffit à l’attaquant qui surveille les forks publics.
Contrôle 3 — SAST avec règles IA-aware
SAST (Static Application Security Testing, analyse statique de sécurité) sur la diff de PR. Semgrep avec les rulesets p/owasp-top-ten, p/secrets, p/javascript ou p/python. Le moteur Semgrep est rapide et permet d’écrire des règles maison ciblant les patterns 2026 (par exemple : tout eval() sur input non validé, tout fetch() avec credentials: 'include' et CORS *). CodeQL en complément pour les analyses inter-procédurales profondes.
Contrôle 4 — Review humaine guidée
Le reviewer humain reçoit une checklist de 10 questions : la PR introduit-elle une nouvelle dépendance, un nouvel endpoint, une nouvelle vérification d’authz, du parsing d’entrée utilisateur, du hashing, de la cryptographie, de l’exécution de commande shell, de l’écriture en base de données, un appel HTTP sortant, un changement de configuration ? Chaque oui déclenche une revue ciblée. La checklist condense l’expérience.
Contrôle 5 — Tests de propriété pour authz
Sur les routes sensibles, des tests de propriété qui génèrent aléatoirement des paires (user, ressource) et vérifient l’invariant « accès autorisé si et seulement si propriétaire ou rôle admin ». Plus efficace qu’une suite de tests cas par cas. Le couplage avec notre stratégie de tests générés par IA rend l’effort raisonnable.
Contrôle 6 — Pentest ciblé sur les nouveautés
Un pentest annuel ne suffit plus quand on livre 200 PR par mois. Mettre en place un pentest ciblé sur les zones impactées par chaque release majeure, avec une enveloppe de 2 à 5 jours par trimestre. Les outils DAST (Dynamic Application Security Testing) comme OWASP ZAP en mode automatisé attrapent une partie des faciles ; un pentester humain capte le reste.
Contrôle 7 — Trace et reproductibilité
Tracer dans la PR : modèle utilisé, prompt principal, commit avant et après. En cas d’incident sécu, retrouver l’origine du pattern accélère la remédiation et la communication réglementaire (DORA, NIS2). Cette trace est aussi exigée par certains audits ISO 27001 récents.
Outils 2026 par contrôle
| Contrôle | Risque visé | Outil principal | Outil complémentaire |
|---|---|---|---|
| 1. Dépendances | Slopsquatting, vulns transitives | OSV-Scanner | Trivy, Dependabot, Snyk |
| 2. Secrets | Clés en clair | gitleaks | TruffleHog |
| 3. SAST | Patterns vulnérables | Semgrep | CodeQL |
| 4. Review humaine | Décisions architecturales | Checklist 10 questions | Pair review |
| 5. Tests authz | IDOR, élévation | fast-check, Hypothesis | Vitest property mode |
| 6. Pentest | Failles de logique | Pentester humain | OWASP ZAP DAST |
| 7. Trace | Reproductibilité | Tag PR + commit | SBOM (CycloneDX) |
Intégration en CI sans tout bloquer
Le piège classique : tout passer en bloquant et faire fuir les contributeurs. La règle pratique : bloquer les classes de risque non négociables (secrets en clair, vulns critiques connues), en mode warning sur le reste, avec dashboard agrégé. Voici un workflow GitHub Actions condensé qui couvre les contrôles 1, 2 et 3.
# .github/workflows/ai-aware-audit.yml
name: AI-aware security audit
on: pull_request
jobs:
audit:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with: { fetch-depth: 0 }
- name: Secret scan (blocking)
uses: gitleaks/gitleaks-action@v2
with: { args: detect --source=. --redact }
- name: Dependency scan (blocking on critical)
uses: google/osv-scanner-action@v2
with: { fail-on-vuln: critical }
- name: SAST Semgrep (warning only)
uses: returntocorp/semgrep-action@v1
with: { config: 'p/owasp-top-ten p/secrets' }
continue-on-error: true
- name: SBOM CycloneDX
run: npx @cyclonedx/cyclonedx-npm --output-file sbom.jsonCas concret WebCreatid : sur une mission d’audit pour un client SaaS B2B, le scan OSV-Scanner a détecté un package npm prétendument suggéré par Copilot, enregistré 11 jours auparavant, 47 téléchargements, mainteneur anonyme. Bloqué en CI, signalé à l’équipe sécurité, package retiré du registre par npm dans la semaine. Sans le contrôle 1, le payload aurait atteint la prod. Pour cadrer la stack DevOps autour, voyez notre stack DevOps solo sécurisée.
Questions fréquentes
Le code généré par IA est-il moins sûr que le code humain ?
Pas systématiquement, mais il introduit des classes de risque spécifiques : dépendances hallucinées, validation lâche par défaut, secrets recopiés, boilerplate sécu daté, authz incomplète. Le risque global dépend du protocole d’audit en place. Un code IA passé par les sept contrôles décrits dans cet article est généralement plus robuste qu’un code humain non audité.
Qu’est-ce que le slopsquatting ?
Le slopsquatting est l’enregistrement par un attaquant de noms de packages que les LLM hallucinent. L’attaquant publie un package malveillant sous le nom suggéré ; le développeur l’installe sans vérifier. Mitigation : OSV-Scanner ou Trivy en CI, vérification manuelle de toute nouvelle dépendance proposée par l’IA, allowlist d’écosystèmes pour les contextes sensibles.
Quels outils SAST détectent les failles spécifiques au code IA ?
Semgrep est le plus accessible et le plus rapide à intégrer, avec des rulesets dédiés OWASP. CodeQL pousse plus loin sur les analyses inter-procédurales et les flux de données. Les deux sont complémentaires : Semgrep en gate de PR pour la rapidité, CodeQL en passe nocturne pour la profondeur.
Comment intégrer l’audit IA-aware dans la CI sans tout bloquer ?
Bloquer uniquement les non-négociables (secrets en clair, vulns critiques OSV avec exploit connu). Passer le reste en warning avec dashboard agrégé. Mettre en place une règle d’équipe : les warnings doivent être traités sous 7 jours ou commentés explicitement. La friction reste basse, la qualité monte.
Faut-il une code review humaine systématique sur les PR générées par IA ?
Oui, sans exception. La revue humaine guidée par checklist (contrôle 4) reste le filet à plus haute valeur. Les outils automatisés captent les patterns connus ; l’humain capte les décisions architecturales et les manques de logique. Sur des PR sensibles (paiement, authz, données personnelles), exiger deux reviewers.
Sept contrôles, une posture mature
Trois prises à retenir. Premièrement, les vulnérabilités du code IA forment un ensemble identifiable : slopsquatting, validation lâche, secrets recopiés, boilerplate daté, authz incomplète. Deuxièmement, le protocole en sept contrôles s’intègre en CI avec un effort initial de quelques jours-homme. Troisièmement, le coût de la non-mise-en-place est asymétrique : un seul slopsquatting réussi vaut plusieurs années de travail d’audit. L’équipe WebCreatid installe ce protocole en 1 à 2 jours selon la stack ; le formulaire de contact est ouvert pour discuter de votre cas.
