Supply chain et CI/CD
Sécuriser le code généré par les agents IA
Un agent de développement écrit du code, ajoute des dépendances, modifie de l'infrastructure et peut exécuter ce qu'il produit. La question n'est pas la qualité du modèle, mais le chemin entre sa proposition et la production.
Le code généré par une IA doit être traité comme un artefact non fiable jusqu'à validation.
Par Sécurité Agentique · Publié le
01
Hermes ouvre une pull request
- Hermes
- contrôles de sécurité
- dépôt
- pull request
- CI/CD
- tests
- security gates
- revue
- déploiement
Chaque étape est un point où un artefact non conforme peut être arrêté. L'objectif : empêcher qu'un artefact ne respectant pas les contrôles attendus atteigne l'étape suivante.
02
Secrets
Un agent reproduit volontiers ce qu'il a vu dans son contexte : une clé présente dans un fichier .env lu pendant la tâche peut réapparaître en clair dans le code proposé.
- clés d'API
- mots de passe
- tokens
- credentials
- certificats
- secrets en dur
La détection intervient avant le push quand c'est possible, et au plus tard à la pull request. Un secret poussé est un secret exposé : il se révoque, il ne se supprime pas seulement de l'historique.
03
Code et dépendances
Selon la chaîne existante, les contrôles portent sur :
- Vulnérabilités
- Dans le code écrit par l'agent.
- Dépendances
- Versions vulnérables, bibliothèques abandonnées.
- Packages
- Noms proches d'un paquet connu, paquets inexistants proposés par le modèle.
- SBOM
- Inventaire à jour de chaque artefact.
- Images
- Images de base et couches ajoutées.
- IaC et configuration
- Ports ouverts, droits excessifs, chiffrement désactivé.
AccuKnox est un exemple de solution couvrant certaines capacités de sécurité de pipeline, de SBOM, de sécurité cloud et runtime appliquées au code produit.
04
Le pipeline reste l'autorité
Hermes propose. Son identité sur le dépôt ne doit pas lui donner implicitement le droit de contourner :
- tests
- revues
- quality gates
- security gates
- protection de branche
- approbations
Si le compte de l'agent peut fusionner sans revue ou désactiver un contrôle, la chaîne entière ne vaut que ce que vaut le modèle.
05
Et si le code doit être exécuté ?
Beaucoup d'agents exécutent le code qu'ils écrivent pour tester, analyser des données ou automatiser une tâche. L'analyse statique ne suffit plus : il faut limiter ce que le code peut faire.
- Sandbox
- Environnement jetable, séparé des systèmes de production.
- Accès fichiers
- Seuls les répertoires de travail, aucun secret monté.
- Accès réseau
- Sortie bloquée ou limitée à une liste.
- Isolation des processus
- Pas de lancement de shell ni d'élévation.
- Restrictions runtime
- Politique appliquée au workload, voir sécurité runtime.
Scanner le code répond à « ce code semble-t-il dangereux ? ». Restreindre le runtime répond à « que peut-il effectivement faire une fois lancé ? ».
06
Exemple : le script Python
Hermes génère un script Python pour consolider des fichiers. Le script passe l'analyse statique. À l'exécution, il tente :
- Lecture d'un secret
- Ouverture d'un fichier de credentials hors du répertoire de travail. Refusée par la politique d'accès fichiers.
- Connexion externe
- Ouverture d'une connexion vers une destination inconnue. Bloquée par la politique réseau.
Le contrôle runtime empêche l'effet même si le code a passé certaines analyses. Les deux tentatives produisent des événements exploitables pour la détection, décrite dans détecter un agent qui sort de son périmètre.
07
Supply chain
Le code de l'agent n'est qu'un maillon. La même vigilance s'applique à ce qu'il assemble et à ce dont il dépend :
- packages
- images
- modèles
- artefacts
- provenance
- dépendances
La provenance permet de savoir d'où vient un artefact et qui l'a produit, agent compris. Les outils que l'agent utilise pour coder (serveurs MCP, extensions) font partie de cette chaîne : voir sécuriser les MCP. Vue d'ensemble dans l'architecture complète.
FAQ
Questions fréquentes
Peut-on laisser une IA pousser directement en production ?
Ce serait lui donner un chemin qui évite tous les contrôles de la chaîne. Un agent de développement propose des changements ; les tests, analyses, revues, protections de branche et approbations restent ceux de n'importe quelle contribution, et son identité ne doit pas pouvoir les contourner.
Comment détecter des secrets dans du code généré ?
Avec un scanner de secrets exécuté avant le commit ou à l'ouverture de la pull request, puis dans la CI : clés d'API, mots de passe, tokens, certificats, chaînes de connexion. Un secret détecté bloque la fusion et doit être considéré comme exposé s'il a été poussé.
Qu'est-ce qu'un SBOM ?
Un Software Bill of Materials : l'inventaire des composants, bibliothèques et versions contenus dans un artefact. Il permet de savoir si une vulnérabilité publiée concerne un livrable, y compris lorsque la dépendance a été ajoutée par un agent.
Comment sandboxer du code généré par IA ?
L'exécuter dans un environnement isolé : système de fichiers restreint, aucun secret monté, réseau sortant bloqué ou limité à une liste, processus confiné, ressources plafonnées, durée limitée. Le but est de limiter ce que le code peut faire, quelle que soit la qualité de l'analyse préalable.
Quelle différence entre SAST et runtime security ?
Le SAST analyse le code source sans l'exécuter et signale des constructions dangereuses. La sécurité runtime observe et restreint ce que fait le processus pendant l'exécution : fichiers ouverts, connexions, processus lancés. L'un repère des risques, l'autre en contient l'effet.
Comment sécuriser un agent de développement ?
Lui donner une identité dédiée sur le dépôt, sans droit de fusion ni de contournement des protections de branche, des tokens courts limités aux dépôts utiles, un environnement d'exécution isolé, et soumettre chacune de ses contributions à la même chaîne de contrôle qu'un développeur.
Une revue humaine suffit-elle ?
Elle est nécessaire mais ne voit pas tout : un secret dans un fichier de configuration, une dépendance typosquattée, une image de base vulnérable échappent facilement à la lecture. Elle complète les analyses automatiques et les contrôles runtime, elle ne les remplace pas.
Continuer l'exploration
Où votre agent peut-il réellement agir ?
Cartographions ses modèles, données, outils, API, identités et effets pour identifier les contrôles utiles.