LLMs et sécurité du code : ce qu'il faut savoir

J'ai passé une heure à examiner le code d'un client dans le secteur financier que j'accompagnais. Ils avaient adopté Copilot depuis 3 mois, sans formation sur les risques spécifiques. Dans les 200 premières lignes d'un nouveau service, j'ai trouvé deux credentials AWS hardcodées et une requête SQL construite par interpolation de chaîne. Le code compilait. Les tests passaient. La PR avait été approuvée.

Ce n'était pas de la négligence. C'était de l'ignorance des patterns que les LLMs reproduisent naturellement.

Un LLM génère du code SQL injection et du code parfaitement sécurisé avec la même confiance syntaxique. Il ne distingue pas les deux. Votre processus de review doit le faire, et en 2026, la plupart des équipes n'ont pas adapté leur review au code IA-assisté.

Deux études publiées en 2023 ont documenté le problème. Stanford University : 40% du code suggéré par Copilot dans des contextes de sécurité spécifiques contient des vulnérabilités. NYU : les développeurs qui utilisent des assistants IA tendent à produire du code moins sécurisé que sans assistant, parce qu'ils font plus confiance au code généré et le reviewent moins rigoureusement. Ce chiffre est contre-intuitif mais cohérent avec ce que j'observe sur le terrain.

Pourquoi les LLMs génèrent du code vulnérable

L'explication est simple mais souvent ignorée : les LLMs sont entraînés sur du code public. Le code public contient des vulnérabilités courantes. Les LLMs reproduisent les patterns du code sur lequel ils ont été entraînés.

Le résultat : les patterns vulnérables les plus fréquents dans le code public (injections, secrets hardcodés, dépendances non vérifiées) sont aussi les plus fréquemment générés par les LLMs. Pas par malveillance. Par statistique.

Vulnérabilité type 1 : Injections (SQL, prompt, command)

Les LLMs génèrent facilement du code vulnérable aux injections, surtout quand le prompt ne spécifie pas explicitement l'usage de requêtes paramétrées.

# ❌ Code généré par LLM sans précision sur la sécurité
def get_user(username: str):
    query = f"SELECT * FROM users WHERE username = '{username}'"  # SQL injection
    return db.execute(query)

# ✅ Code correct (que le LLM génère si le prompt est précis)
def get_user(username: str):
    query = "SELECT * FROM users WHERE username = %s"
    return db.execute(query, (username,))

La prompt injection est spécifique au code qui intègre des LLMs dans des applications : si votre application passe de l'input utilisateur directement dans un prompt, un attaquant peut modifier le comportement du modèle via des instructions injectées. C'est une vulnérabilité nouvelle, documentée par l'OWASP Top 10 for LLM Applications depuis 2023.

Garde-fou : lors de la review de tout code qui touche à la gestion des inputs utilisateurs, vérifier systématiquement que les requêtes sont paramétrées et que les inputs ne sont pas interpolés directement dans des strings.

Vulnérabilité type 2 : Gestion des secrets et credentials

C'est le pattern de vulnérabilité le plus fréquemment généré par les LLMs : credentials hardcodées, tokens dans les logs, secrets dans les fichiers de configuration versionnés.

// ❌ Pattern fréquemment généré
const client = new S3Client({
    accessKeyId: "AKIAIOSFODNN7EXAMPLE",      // credential hardcodée
    secretAccessKey: "wJalrXUtnFEMI/K7MDENG" // credential hardcodée
});

// ❌ Pattern de logging qui expose des secrets
console.log(`Connecting to DB with password: ${process.env.DB_PASSWORD}`);

// ✅ Pattern correct
const client = new S3Client({
    credentials: fromEnv()  // lecture depuis les variables d'environnement
});

La raison : les LLMs ont été entraînés sur du code d'exemple qui contient fréquemment des credentials "de test" hardcodées. Ils reproduisent ce pattern naturellement.

Garde-fou : outil SAST (Semgrep, GitHub Secret Scanning, Gitleaks) dans la CI qui détecte les patterns de credentials hardcodées avant le merge. Ce check doit être bloquant.

Vulnérabilité type 3 : Dépendances obsolètes ou hallucinations

Quand un LLM génère du code qui importe des librairies externes, deux risques spécifiques apparaissent :

Dépendances avec CVE connus : le LLM suggère une version d'une librairie qui avait des vulnérabilités connues au moment de son entraînement, et qui ont pu être corrigées depuis, mais la version vulnérable reste dans le code généré.

Package hallucination : les LLMs peuvent inventer des noms de packages plausibles qui n'existent pas (ou qui existent sous un nom de typosquat malveillant). C'est le vecteur de l'attaque "dependency confusion", documentée par de nombreux chercheurs en sécurité depuis 2021.

# LLM suggère d'importer "utility-helper-crypto" — package qui n'existe pas
# Un attaquant peut publier ce package sur npm avec du code malveillant
npm install utility-helper-crypto  # ❌ vérifier l'existence avant d'installer

Garde-fou : ne jamais installer un package suggéré par un LLM sans vérifier son existence sur le registre officiel et son score de sécurité (npm audit, Snyk, Socket.dev).

Les 5 garde-fous à mettre en place

Garde-fou 1 : SAST dans la CI

SonarQube, Semgrep, ou GitHub Advanced Security détectent les patterns de vulnérabilités courants indépendamment de l'origine du code, qu'il soit humain ou IA. Ce check doit être bloquant sur les vulnérabilités Critical et High.

Garde-fou 2 : Checklist de review spécifique au code IA

Au-delà de la review standard, les reviewers vérifient explicitement pour le code IA-assisté (voir la checklist complète en 12 points) :

• Aucune credential hardcodée
• Toutes les requêtes DB sont paramétrées
• Les dépendances importées ont été vérifiées
• Les inputs utilisateurs sont validés et sanitisés

Garde-fou 3 : Politique de prompt

Documentez quelles données peuvent et ne peuvent pas être incluses dans les prompts envoyés à des services IA externes : pas de données personnelles, pas de données clients, pas de credentials, pas de secrets d'infrastructure.

Garde-fou 4 : Formation des développeurs

Une session de 2 heures sur les patterns de vulnérabilités spécifiques au code LLM-généré suffit à doubler la détection lors des reviews. Découvrez comment intégrer l'IA dans votre code review tout en renforçant la sécurité. Les développeurs qui connaissent les patterns les cherchent. Ceux qui ne les connaissent pas ne les voient pas. C'est aussi simple que ça.

Garde-fou 5 : Audit trimestriel du code IA-assisté

Auditer trimestriellement un échantillon du code développé avec assistance IA pour identifier des patterns systémiques de vulnérabilité. C'est une pratique préventive, pas réactive.

Dans ce même client (18 développeurs), l'introduction de GitHub Advanced Security + une checklist de review spécifique au code IA a détecté en 3 mois 12 instances de secrets hardcodés et 8 vulnérabilités d'injection qui auraient atteint la production. Coût de l'implémentation : 5 jours. Coût évité (estimation conservatrice basée sur le coût moyen d'un incident de sécurité dans le secteur financier) : plus de 500 000€.

L'IA accélère la production. Elle ne remplace pas le jugement de sécurité.

FAQ sur la sécurité du code LLM