LLM security pour AppSec - Étendre sa pratique aux applications IA

Un AppSec engineer confirmé en 2026 ne peut plus ignorer la sécurité des applications LLM : la majorité des entreprises déploient désormais des chatbots, assistants, agents et copilots qui sortent de la grille classique OWASP Web. Bonne nouvelle : 60-70 % des compétences AppSec se transposent directement (threat modeling, code review, SDLC, IAM, supply chain, monitoring). Mauvaise : les 30-40 % restants relèvent d'un nouveau corpus (prompt injection, RAG security, embedding poisoning, model supply chain, guardrails) qu'il faut acquérir méthodiquement. Ce guide trace le pont pour un profil AppSec existant : ce qui se transpose, ce qui change, l'outillage à étendre, les nouveaux réflexes, et un plan de montée en compétence sur 3-6 mois.

1. Bonne nouvelle - ce qui se transpose

Beaucoup de fondamentaux AppSec restent applicables sans bouleversement.

1.1 La méthode AppSec ne change pas

• Shift-left : intervenir à la conception, pas en post-prod.
• Defense in depth : empiler les contrôles, pas en empiler un seul.
• Least privilege : tools, IAM, accès données.
• Validation aux frontières : input ↔ contexte LLM ↔ output.
• Secure by default : guardrails actifs, pas opt-in.
• Monitoring + audit log : tracer pour pouvoir investiguer.
• Threat modeling systématique avant code.

1.2 Vulnérabilités classiques persistantes dans les apps LLM

Les apps LLM hébergent toujours :

• API REST/GraphQL → toutes les vulnérabilités API (BOLA/IDOR, BFLA, injection, mass assignment, rate limiting). OWASP API Top 10 2023 reste pleinement pertinent.
• Auth (JWT, OAuth, sessions) → mêmes pièges qu'avant.
• Stockage (vector DB, Postgres, S3) → IAM, chiffrement, RLS.
• Front-end → XSS, CSRF, CSP.
• Conteneurs et orchestration → image scanning, RBAC Kubernetes, secrets management.
• Pipeline CI/CD → SLSA, SBOM, signing.

Le 80 % du périmètre sécurité d'une app LLM reste de l'AppSec / DevSecOps classique.

1.3 Outils existants encore utiles

Tous ces outils restent nécessaires sur une app LLM. Ils deviennent insuffisants seuls.

2. Mauvaise nouvelle - ce qui change

Le delta avec un projet web classique se concentre sur 5 dimensions.

2.1 La validation de l'input est partielle

Sur une API REST, on valide : type, longueur, regex, schéma JSON. Sur un prompt LLM, on ne peut pas valider de la même façon - la grammaire est le langage naturel, l'attaque circule en clair.

Conséquence : la sécurité bascule sur l'output et sur l'architecture (least privilege, sandboxing) plus que sur l'input filtering.

2.2 La sortie est non déterministe

Aucun assertEquals possible. Les tests deviennent probabilistes (similarité sémantique, LLM-as-judge, distributions). Voir l'article Comment tester une application LLM dans la même catégorie.

2.3 Nouvelle classe de vulnérabilités

OWASP a créé un Top 10 LLM dédié justement parce que les vecteurs sortent du périmètre OWASP Web/API :

• Prompt injection (LLM01) : pas équivalent web direct.
• System prompt leakage (LLM07) : analogie avec leak de config interne, mais via le LLM.
• Vector & embedding weaknesses (LLM08) : nouveau totalement.
• Excessive agency (LLM06) : analogie avec SSRF (LLM appelle un endpoint contrôlé par attaquant) mais via tool calls.
• Model & data poisoning (LLM04) : analogie avec supply chain compromise, mais sur ML.
• Unbounded consumption (LLM10) : analogie avec DoS classique mais coût économique direct (tokens facturés).

2.4 Nouvelle supply chain

Un projet web classique gère SBOM (npm, pip, gem). Un projet LLM ajoute :

• Modèles (Hugging Face, model hubs, fine-tunes maison).
• Datasets (training, fine-tune, eval).
• Embeddings models (text-embedding-3, voyage, bge, jina).
• Vector stores (Pinecone managed, Qdrant self-hosted).
• LLM providers (OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI).
• Guardrails (Llama Guard, Lakera, NeMo).
• Tools / MCP servers (function calling, Model Context Protocol).

Chaque composant ajoute une surface. AI BOM (Bill of Materials AI) émerge en 2025-2026 comme extension de SBOM.

2.5 Nouveau cadre normatif

OWASP Web Top 10 + ASVS restent. S'ajoutent :

• OWASP LLM Top 10 2025.
• MITRE ATLAS (TTP IA).
• NIST AI RMF 1.0 + GenAI Profile.
• ISO/IEC 42001:2023 (AI Management System).
• AI Act EU (entrée en vigueur étalée 2025-2027).
• Sigstore for ML, SLSA for ML (provenance, signature).

L'AppSec engineer doit comprendre ces référentiels pour dialoguer avec compliance, DPO, juridique.

3. Mapping OWASP LLM Top 10 ↔ OWASP Web/API

Pour faciliter l'apprentissage, partir des analogies :

Cette table doit être affichée dans toute war room AppSec qui démarre sur un projet LLM.

4. Threat modeling LLM-aware

L'AppSec engineer maîtrise déjà STRIDE, PASTA, Attack Trees. Étendre la méthode aux apps LLM.

4.1 STRIDE adapté

4.2 Diagramme de flux à compléter

Sur le diagramme classique d'une app, ajouter explicitement :

• Frontière entre data RAG et instruction system.
• Frontière entre output LLM et tool execution.
• Identité propagée jusqu'au filter retrieval.
• Provider LLM externe (transfert hors UE → analyse RGPD).
• Vector store et son IAM.
• Guardrails (input, output) avec leurs zones de couverture.

4.3 Questions à poser systématiquement

• Qui peut écrire dans le corpus RAG ?
• Le système prompt contient-il des secrets ?
• Quels tools le LLM peut appeler, avec quels arguments ?
• Quelles données utilisateur sortent vers le provider LLM ?
• Que devient un canary token PII inséré dans le RAG ?
• Que se passe-t-il si le LLM répond 100 000 tokens ?
• Que se passe-t-il si l'utilisateur boucle l'agent 100 fois ?
• Comment révoque-t-on un document RAG ingéré (RGPD) ?

5. Code review LLM-aware

L'AppSec engineer relit du code Python/JS/TS où vivent les apps LLM. Anti-patterns à détecter en priorité.

5.1 Anti-pattern 1 - System prompt avec secrets

# MAUVAIS
SYSTEM_PROMPT = """Tu es un assistant. Notre clé interne est XYZ-123.
N'utilise JAMAIS la clé en dehors de ce contexte."""
 
# BON
SYSTEM_PROMPT = """Tu es un assistant. Tu peux appeler le tool 'lookup_data'
qui gère les credentials côté serveur."""

5.2 Anti-pattern 2 - Tool sans validation

# MAUVAIS
def execute_sql(query: str) -> list:
    return db.execute(query).fetchall()
 
# BON
def lookup_user(user_id: int) -> dict:
    if not isinstance(user_id, int):
        raise ValueError
    return db.execute(
        "SELECT id, name FROM users WHERE id = %s",
        (user_id,)
    ).fetchone()

LLM ne doit jamais avoir un tool de SQL libre. Tool = endpoint RPC strict, jamais shell ni SQL libre.

5.3 Anti-pattern 3 - RAG sans filtre serveur

# MAUVAIS (filtre côté client - bypassable)
chunks = vector_db.query(embedding, top_k=20)
chunks = [c for c in chunks if c.tenant == request_tenant]
 
# BON (filtre côté serveur, forcé)
chunks = vector_db.query(
    embedding,
    top_k=5,
    filter={"tenant_id": authenticated_user.tenant_id},
)

5.4 Anti-pattern 4 - Output exécuté sans validation

# MAUVAIS
code = llm.complete("Generate Python to plot this data")
exec(code)  # RCE garantie sur prompt injection
 
# BON
code = llm.complete("Generate Python to plot this data")
sandbox = E2BSandbox(timeout=10, network=False)
result = sandbox.run(code)

5.5 Anti-pattern 5 - Pas de guardrail

# MAUVAIS
response = llm.complete(user_input)
return response
 
# BON
if guardrail_input.is_attack(user_input):
    return refusal_message
response = llm.complete(user_input)
if guardrail_output.contains_pii(response):
    return sanitize(response)
return response

5.6 Anti-pattern 6 - Pas de timeout / quota

# MAUVAIS
response = llm.complete(prompt)  # peut tourner 60s, coûter 100K tokens
 
# BON
response = llm.complete(
    prompt,
    timeout=30,
    max_tokens=2000,
)
quota_manager.check_and_consume(user, estimated_cost)

6. Outils nouveaux à ajouter au tool belt

Au-delà des SAST/DAST/SCA classiques, en 2026 un AppSec engineer LLM-aware utilise :

Pas obligation d'adopter tout - choisir 4-5 selon son contexte.

7. Pentest et bug bounty LLM

7.1 Différences avec un pentest classique

• Reconnaissance : identifier le modèle (parfois deviné via fingerprinting), le RAG, les tools.
• Tests: prompt injection (direct, indirect, multi-tour), jailbreak, system prompt extraction, ACL bypass via retrieval, tool abuse, DoS économique.
• Méthodologies : OWASP LLM Top 10 + MITRE ATLAS comme grilles de référence.
• Rapport : impact différent (réputationnel et juridique souvent prédominants), recommandations souvent architecturales (cloisonnement, guardrails) plus que patch ponctuel.

7.2 Plateformes bug bounty avec scope LLM

• HackerOne : nombreux programmes IA depuis 2023 (OpenAI, Anthropic, Google AI, Microsoft AI Red Team).
• Bugcrowd : programmes dédiés LLM depuis 2024.
• Programmes privés : la plupart des grands éditeurs LLM acceptent des reports avec rémunérations dans les 4-5 chiffres pour vulnérabilités majeures (ex. exfiltration cross-tenant, jailbreak universel).

7.3 Disclosure responsable

L'écosystème mature lentement. Reporting recommandé :

• Reproduce reliable (pas une seule occurrence stochastique).
• Impact business clair.
• Suggestion de mitigation si possible.
• Pas de tweet du PoC avant patch (pratique standard sécurité).

8. Plan de montée en compétence (3-6 mois)

Pour un AppSec engineer expérimenté qui démarre en LLM security.

8.1 Mois 1 - Fondamentaux conceptuels

• Lire OWASP LLM Top 10 2025 intégralement.
• Lire MITRE ATLAS (au moins introduction et techniques principales).
• Lire NIST AI RMF 1.0 Section Manage.
• Suivre 2-3 chaînes YouTube : Embrace the Red (Rehberger), AI Snake Oil, DEF CON AI Village talks.
• Comprendre le RAG, les agents, le tool calling, MCP. Construire un mini-RAG perso (LangChain ou LlamaIndex).

8.2 Mois 2 - Outillage

• Installer et tester Promptfoo sur un mini-projet.
• Lancer garak sur une app LLM publique ou perso.
• Tester Lakera Guard ou Llama Guard en intégration.
• Intégrer un tracing (Langfuse self-hosted).
• Lire la documentation de 1 vector DB principal (Pinecone ou Qdrant).

8.3 Mois 3 - Pratique offensive

• Faire 10-20 challenges Gandalf (Lakera), Prompt Airlines (Wiz), HackTheBox AI Red Team paths.
• Reproduire 5 cas publics (Bing Sydney, Air Canada-style, EchoLeak).
• Écrire un writeup public (blog perso, LinkedIn) - cristallise l'apprentissage.

8.4 Mois 4 - Pratique défensive

• Auditer un projet LLM réel (interne ou open source).
• Implémenter le hardening RAG d'une app existante (voir article Comment sécuriser une application RAG).
• Mettre en place tests sécurité en CI sur cette app.

8.5 Mois 5 - Compliance et gouvernance

• Étudier les obligations AI Act applicables à votre organisation.
• Lire ISO/IEC 42001:2023 (résumé exécutif au moins).
• Construire un AI BOM sur un projet (CycloneDX 1.5+).
• Participer à une revue compliance avec DPO et juridique.

8.6 Mois 6 - Spécialisation

Choisir un sous-domaine selon affinités :

• Red teaming LLM : approfondir PyRIT, HarmBench, recherche académique.
• Defense engineering : approfondir guardrails, architecture sécurisée, incident response.
• Compliance / governance : approfondir AI Act, ISO 42001, NIST RMF.
• MLSecOps : approfondir model supply chain, signature, AI BOM, MLOps secure.

À 6 mois, profil opérationnel sur la majorité des projets LLM, capable de challenger un design et de tester une app en production.

9. Questions à poser en entretien LLM Security Engineer

Pour AppSec engineer postulant à un rôle LLM Security :

• "Comment sécurisez-vous le pipeline RAG dans cette app ?" → savoir parler de multi-tenancy, ACL propagées, sanitization, spotlighting.
• "Que mettez-vous dans le system prompt et que n'y mettez-vous jamais ?" → secrets jamais, instructions claires + canary, refus explicite.
• "Comment validez-vous qu'un LLM ne révèle pas son prompt ?" → 8 payloads connus, test en CI, canary token.
• "Comment évaluez-vous la qualité des réponses ?" → golden dataset, Ragas metrics, LLM-as-judge.
• "Quel est votre plan AI BOM et provenance modèle ?" → CycloneDX 1.5, Sigstore for ML, whitelist HF.
• "Comment gérez-vous la conformité AI Act sur ce projet ?" → identifier classe de risque, obligations applicables, plan de mise en conformité.

Une équipe sérieuse pose ces questions. Si elles ne sont pas posées, c'est un signal sur la maturité du futur employeur.

10. Pièges fréquents pour un AppSec qui démarre

• Sous-estimer la part « identique » : penser que tout est nouveau et négliger les fondamentaux d'IAM, secrets management, IaC scan.
• Surestimer la nouveauté magique : penser qu'un guardrail unique remplace tout. C'est une couche, pas un firewall.
• Confondre prompt injection et jailbreak : ce sont des choses différentes (cibles, vecteurs, défenses).
• Tester uniquement en mode mono-tour : la majorité des vraies attaques sont multi-tour.
• Oublier le coût économique : LLM10 (Unbounded Consumption) est une vraie classe de risque, parfois sous-estimée.
• Ignorer la dérive provider : OpenAI / Anthropic / Google modifient les modèles régulièrement. Tester en continu.
• Ne pas dialoguer avec compliance : AI Act et ISO 42001 ne sont pas optionnels.

11. FAQ

11.1 Faut-il être ML engineer pour faire de la LLM security ?

Non. Comprendre les concepts ML (entraînement, fine-tuning, inférence, embedding) suffit. Pas besoin de savoir coder un transformer from scratch ni de connaître les architectures GPU. Un AppSec engineer avec 3-6 mois de pratique LLM est plus opérationnel sur la sécurité qu'un ML engineer pur sans formation sécurité.

11.2 Quel langage privilégier ?

Python dans 90 % des cas (tout l'écosystème LLM est en Python : LangChain, LlamaIndex, transformers, openai, anthropic, mistralai, ragas, deepeval, garak). Connaître TypeScript/JS utile car certains frameworks (Vercel AI SDK, LlamaIndex.TS) y existent et beaucoup de chatbots front sont en Next/Remix/SvelteKit.

11.3 OWASP Web Top 10 reste-t-il pertinent ?

Absolument. La majorité d'une app LLM est une web app classique - elle a tous les risques OWASP Web/API. OWASP LLM Top 10 complète, ne remplace pas. Maintenir l'expertise sur les deux.

11.4 Faut-il s'investir sur les LLM open source self-hosted ?

Selon le contexte. La majorité des entreprises consomment des APIs (OpenAI, Anthropic via Bedrock, Azure OpenAI, Vertex). Connaître la sécurité des LLM API-consommés suffit pour 70 % des cas. Pour les projets sensibles (santé, défense, gouvernance), connaître le self-hosting (Llama, Mistral, Qwen, DeepSeek) devient indispensable - et la surface est différente (model supply chain, GPU isolation, etc.).

11.5 Comment se positionner face à un projet LLM mal cadré ?

Comme face à n'importe quel projet AppSec mal cadré : exiger un threat model, un design review, un golden dataset, des tests sécurité en CI, un audit log avant mise en prod. Les arguments ne changent pas - l'expertise LLM permet de les justifier sur le bon vocabulaire.

11.6 Quelle veille suivre ?

• OWASP LLM Top 10 working group (mises à jour annuelles).
• Embrace the Red (Johann Rehberger), recherche pratique.
• Simon Willison's Weblog (vulgarisation IA + sécurité).
• NVIDIA garak releases (nouvelles probes).
• Bluesky / X : @rharang (HiddenLayer), @dotnetscan, @latentspace, @pirxthepilot, @rez0__ (red team).
• DEF CON AI Village, Black Hat AI track, AI Safety conferences.

L'AppSec engineer qui investit 3-6 mois sur la LLM security en 2026 ne change pas de métier - il étend son périmètre vers une couche stratégique nouvelle. La méthode reste la même (shift-left, defense in depth, threat modeling), les outils s'enrichissent (Promptfoo, garak, guardrails), le vocabulaire s'élargit (prompt injection, RAG, embeddings, AI BOM). C'est un investissement à fort ROI : pénurie de profils, salaires tirés vers le haut, et une discipline qui ne fait que croître. Les six pièges du §10 évités, le plan du §8 suivi sérieusement, l'AppSec engineer devient un asset rare sur le marché 2026-2027.