ESAA-Security: An Event-Sourced, Verifiable Architecture for Agent-Assisted Security Audits of AI-Generated Code

L'article présente ESAA-Security, une architecture de vérification basée sur l'événement qui transforme l'audit de sécurité du code généré par l'IA en un processus gouverné, reproductible et traçable, en séparant la cognition heuristique des agents de mutations d'état déterministes via un journal immuable et une vérification par rejeu.

L'essentiel

Voici une explication simple de ce papier, imagée comme si nous parlions d'une équipe de construction très spéciale.

Le Problème : Le Bâtiment "Magique" mais Fragile

Imaginez que vous avez un architecte très doué, un robot (l'IA) capable de dessiner des plans de maison en quelques secondes. C'est génial ! La maison est construite super vite.

Mais il y a un gros souci : l'architecte robot dessine parfois des portes qui s'ouvrent toutes seules, ou des fenêtres qui ne verrouillent jamais. Le robot dit : "La maison est fonctionnelle, on peut y vivre !" Mais en réalité, n'importe qui peut entrer.

Le problème actuel, c'est que quand on demande à un autre robot (une IA de sécurité) de vérifier la maison, il répond souvent de manière floue : "Euh, il y a peut-être un problème ici, ou là, je ne suis pas sûr, mais voici un texte long et compliqué." On ne peut pas prouver qu'il a bien vérifié chaque coin, et on ne peut pas refaire exactement le même examen plus tard pour voir si on obtient le même résultat. C'est comme essayer de vérifier un compte bancaire en regardant juste un dessin fait à la main.

La Solution : ESAA-Security (Le Journal de Bord Inaltérable)

L'auteur propose une nouvelle méthode appelée ESAA-Security. Au lieu de laisser les robots discuter librement, on leur impose un règlement strict et un journal de bord magique.

Voici comment ça marche, avec une analogie simple :

1. Le Journal de Bord "Inaltérable" (Event Sourcing)

Imaginez que chaque fois qu'un robot fait une action (comme "vérifier la serrure de la porte"), il ne modifie pas directement la maison. Au lieu de cela, il écrit une phrase dans un carnet de notes spécial qui ne peut jamais être effacé ni modifié.

• Si le robot dit "J'ai trouvé un trou", il l'écrit dans le carnet.
• Un chef d'équipe (l'Orchestrateur) lit le carnet. Si la phrase respecte les règles, il valide l'entrée.
• Si le robot essaie de mentir ou de changer le passé, le chef refuse d'écrire dans le carnet.

C'est comme un journal de bord de capitaine de navire : une fois écrit, c'est la vérité. On peut relire tout le voyage à n'importe quel moment pour voir exactement ce qui s'est passé.

2. Le Plan de Mission en 4 Étapes (Le Pipeline)

Au lieu de dire au robot "Vérifie cette maison", on lui donne un plan de mission très précis, comme une recette de cuisine :

1. Reconnaissance : "Regarde d'abord de quoi est faite la maison (briques, bois, verre)."
2. Inspection : "Maintenant, vérifie la cuisine, puis la salle de bain, puis le garage, une pièce à la fois."
3. Classement des dangers : "Si tu trouves un problème, dis-moi s'il est grave (incendie) ou léger (une peinture écaillée)."
4. Rapport Final : "Écris un rapport clair pour le propriétaire avec les solutions."

Le robot ne peut pas sauter d'étapes. Il doit suivre le plan, étape par étape.

3. Les "Contrats" (Les Règles du Jeu)

C'est la partie la plus importante. Les robots ne peuvent pas dire n'importe quoi. Ils doivent utiliser un langage codé et structuré.

• Au lieu de dire : "Je pense qu'il y a un risque de vol."
• Ils doivent dire : "Tâche #42 : Serrure porte arrière. Statut : FAIL. Preuve : Pas de verrou. Risque : Élevé."

C'est comme si les robots devaient remplir un formulaire administratif au lieu d'écrire un roman. Cela force l'IA à être précise et à fournir des preuves concrètes.

Pourquoi c'est génial ? (Les Avantages)

1. On peut rejouer le film : Comme tout est écrit dans le journal de bord, on peut demander à l'ordinateur de "rejouer" tout le processus de vérification. Si on le rejoue 10 fois, on obtient exactement le même résultat. C'est la reproductibilité.
2. Pas de "hallucinations" : Si le robot invente un problème, le système le repère parce que le robot n'a pas suivi les règles strictes pour le prouver.
3. Rapport clair : À la fin, on n'a pas un pavé de texte incompréhensible. On a un rapport avec des scores (comme une note sur 100), une liste de problèmes classés par dangerosité, et des solutions concrètes pour réparer la maison.

En Résumé

Ce papier dit : "Arrêtons de demander aux IA de faire de la sécurité comme si elles étaient dans une conversation de café. Faisons-le comme un audit bancaire ou une inspection de chantier."

ESAA-Security transforme l'audit de sécurité en une machine à preuves :

• Pas de discussions libres.
• Tout est noté dans un journal inviolable.
• Tout est vérifiable et reproductible.
• Le résultat final est un rapport fiable, pas une opinion floue.

C'est une façon de dire : "Ne me dis pas que la maison est sûre, prouve-le-moi en suivant ce plan précis, et montre-moi ton journal de bord."

Résumé technique

Résumé Technique : ESAA-Security

1. Le Problème Identifié

L'essor de la génération de code assistée par l'IA (LLM) a considérablement accéléré le développement logiciel, mais a exacerbé un problème d'ingénierie persistant : des systèmes fonctionnellement corrects peuvent être structurellement non sécurisés. Les approches actuelles de révision de sécurité basées sur des invites (prompts) libres avec des LLM souffrent de plusieurs défauts critiques :

• Couverture inégale et implicite : Les modèles peuvent omettre des domaines de risque critiques.
• Manque de reproductibilité : Les résultats dépendent du contexte de la conversation et ne sont pas facilement reproductibles.
• Absence de traçabilité : Il n'y a pas de piste d'audit immuable reliant les découvertes aux preuves de code.
• État mutable et non vérifiable : Les agents modifient l'état du système de manière probabiliste, rendant les étapes intermédiaires difficiles à auditer.

Le papier soutient que la révision de sécurité ne doit pas être modélisée comme une conversation libre avec un LLM, mais comme un processus d'audit orienté vers les preuves, régi par des contrats et des événements.

2. Méthodologie et Architecture

ESAA-Security est une spécialisation du domaine de l'architecture ESAA (Event-Sourced, Agent-Assisted), conçue pour transformer l'audit de sécurité en un pipeline d'exécution gouverné.

Principes Fondamentaux :

• Event Sourcing (Sourcing d'événements) : La source de vérité n'est pas l'instantané du dépôt de code, mais un journal d'événements en append-only (ajout uniquement). L'état actuel est reconstruit par projection déterministe de ces événements.
• Séparation Cognition/État : Les agents (LLM) émettent des intentions structurées sous des contrats stricts. Un orchestrateur valide ces intentions avant qu'elles ne soient persistées. Les agents ne modifient pas directement l'état du système.
• Vérification par Rejeu (Replay) : L'intégrité est garantie par la capacité de rejouer le journal d'événements pour reconstruire et vérifier l'état de l'audit.

Le Pipeline d'Exécution (4 Phases, 26 Tâches, 16 Domaines, 95 Contrôles) :
L'audit est structuré en un flux de travail sérialisé avec des invariants stricts (ex: "réclamer avant de travailler", "compléter après vérification") :

1. Reconnaissance : Identification de la pile technologique, de l'architecture, des flux de données et des surfaces d'attaque.
2. Exécution de l'Audit de Domaine : Exécution de "playbooks" guidés pour chaque domaine de sécurité (ex: authentification, validation des entrées, gestion des secrets, sécurité IA/LLM).
3. Classification des Risques : Consolidation des découvertes en inventaires de vulnérabilités, attribution de sévérités (CRITICAL à INFO) et génération de matrices de risques.
4. Rapport Final : Génération de remédiations techniques, de guides de bonnes pratiques, de résumés exécutifs et de rapports finaux (Markdown/JSON).

Invariants d'Exécution :
Le protocole impose des règles strictes pour éviter les états corrompus :

• Verrouillage de propriété : Seule l'entité qui a réclamé une tâche peut la compléter.
• Cohérence de l'état antérieur : L'agent doit déclarer l'état dans lequel il opère pour éviter les conflits de contexte.
• Immuabilité des tâches terminées : Une fois une tâche marquée comme terminée, elle ne peut être réouverte silencieusement ; les corrections doivent passer par des flux d'issues explicites.

3. Contributions Clés

Le papier propose quatre contributions majeures :

1. Spécialisation Architecturale : Présentation d'ESAA-Security comme une extension du noyau de gouvernance ESAA, adaptée spécifiquement à l'audit de sécurité des dépôts générés ou modifiés par l'IA.
2. Pipeline Gouverné : Définition d'un processus combinant des sorties d'agents contraintes, une persistance d'événements en append-only, une reprojection déterministe et une vérification par rejeu.
3. Opérationnalisation de l'Audit : Structuration de l'audit en 4 phases, 26 tâches et 95 contrôles exécutables couvrant 16 domaines de sécurité (incluant la sécurité spécifique aux LLM).
4. Nouveau Cadre d'Évaluation : Proposition d'évaluer les audits non seulement par le nombre de vulnérabilités trouvées, mais par la traçabilité, la reproductibilité, l'explicitation de la couverture, l'exhaustivité des artefacts et l'utilité des remédiations.

4. Résultats et Artefacts de Sortie

Le système produit une cascade de sorties structurées, où le rapport final n'est pas une narration libre, mais la projection terminale d'un pipeline de preuves :

• Preuves de niveau contrôle : Objets structurés liant un identifiant de contrôle, un statut, une sévérité, des extraits de code/config, et des guides de remédiation.
• Inventaire de Vulnérabilités : Transformation des découvertes locales en état de sécurité systémique.
• Matrice de Risque : Classement des problèmes par sévérité, impact (CIA) et pertinence de la remédiation.
• Rapports : Un rapport technique détaillé, un rapport JSON structuré, et un résumé exécutif incluant un score de sécurité (0-100).

L'architecture garantit que le rapport final est auditable par construction, car chaque affirmation remonte à un événement validé dans le journal immuable.

5. Signification et Implications

La contribution la plus forte d'ESAA-Security n'est pas une nouvelle liste de contrôle (checklist), mais un changement de paradigme sur la nature d'un audit de sécurité assisté par l'IA :

• De l'Opinion à l'État Gouverné : Le passage d'une "opinion de modèle libre" à un "état d'audit valide par protocole et vérifiable par rejeu".
• Confiance et Gouvernance : Dans un contexte de "vibe coding" (développement rapide par IA), ESAA-Security offre un mécanisme pour préserver la cohérence de l'état, la réversibilité et la responsabilité (accountability).
• Limites et Avenir : Le papier reconnaît que la qualité dépend de celle des "playbooks" et que le système ne remplace pas les tests d'intrusion manuels. Cependant, il établit une base solide pour l'audit interne mature. Les travaux futurs visent l'intégration de CVSS, l'audit multi-dépôts et la comparaison temporelle entre les runs d'audit.

En résumé, ESAA-Security propose une architecture où la sécurité est traitée comme un problème d'exécution gouvernée plutôt que comme un problème de prompt engineering, assurant ainsi que les audits de sécurité dans l'ère de l'IA générative soient explicites, structurés et vérifiables.