OWASP SAMM reçoit l'extension Agentic SAMM pour le développement sécurisé avec des agents AI

Autour d'OWASP SAMM, a émergé un nouveau projet draft appelé Agentic SAMM, ou ASAMM — une extension pour les équipes qui construisent des produits avec des agents IA et utilisent des modèles dans le développement. Son objectif est de fermer les risques que le SDLC sécurisé classique voit mal : contexte malveillant, invocations d'outils dangereuses et fenêtres d'autonomie trop longues.

Pourquoi l'ancien SAMM ne suffit pas

Le OWASP SAMM classique fonctionne bien là où les principaux objets de protection sont le code, la construction, la libération et l'infrastructure de livraison. Mais dans les systèmes d'agents, la surface d'attaque s'étend plus loin : dans les documents, les tâches du suivi, les descriptions d'outils, les résultats de recherche web, les logs CI et tout autre contenu que le modèle lit comme partie de son contexte de travail. Si ce contexte influence le comportement de l'agent, il devient déjà partie du plan de contrôle, pas simplement des données d'entrée.

C'est pourquoi l'auteur d'ASAMM propose de voir le développement non pas comme une boucle fermée, mais comme une spirale. L'équipe passe à nouveau par la conception, la mise en œuvre et l'examen, mais à chaque itération, le système, les outils et les menaces eux-mêmes changent. Dans ce schéma, il ne suffit plus de vérifier que l'agent a reçu les bonnes permissions. Même un agent entièrement autorisé peut effectuer une action qui ne correspond pas à la tâche d'origine si le contexte ou la logique de délégation le dévient.

Ce qu'ASAMM offre

ASAMM n'est pas conçu comme un remplacement pour OWASP SAMM, mais comme une extension pour les équipes déployant des agents IA, des serveurs MCP et l'automatisation avec des permissions déléguées. Le framework ajoute une couche séparée de garanties là où s'arrête la révision de code traditionnelle : à la limite des invocations d'outils, dans le flux de contexte, aux points de contrôle d'approbation et dans le comportement du système pendant l'exécution. Il n'annule pas les pratiques de base de SAMM, mais les étend au comportement au moment de l'exécution et aux actions déléguées.

• Une taxonomie des menaces pour les systèmes d'agents, où le contexte est traité comme une commande potentielle
• Un modèle de confiance à deux axes pour les agents, outils, serveurs MCP et sources de contexte
• Un ensemble de contrôles sur les cinq fonctions de SAMM avec niveaux de maturité et scénarios de mise en œuvre
• Deux chemins de déploiement : migration depuis un programme de sécurité existant ou déploiement à partir de zéro
• Mappage vers NIST AI RMF et recommandations NCSC pour les équipes ayant besoin de compatibilité avec des cadres déjà familiers

Un accent particulier est mis sur l'environnement de développement. Les plugins IDE, les hooks pre-commit, les agents CI et les connecteurs MCP externes fonctionnent avec les privilèges des développeurs, mais vivent souvent en dehors d'un modèle de menace complet. Pour ASAMM, ce n'est pas un élément accessoire, mais une cible d'analyse à part entière : si un agent peut lire, invoquer et modifier plus que ce que l'équipe suit réellement, les statuts verts sur les tableaux de bord cessent de rien garantir. En fait, l'environnement de développement devient la production pour l'agent lui-même.

Où les équipes font déjà des erreurs

Le matériel énumère les erreurs typiques qui sont particulièrement visibles dans le développement d'agents. Une équipe peut considérer le modèle de menace comme complet, même s'il ne contient aucune source de contexte et aucun chemin d'invocation d'outils. L'examen du code peut couvrir tout le code dans une PR, mais ne pas toucher les invites système, les schémas d'appels d'outils et les configs d'agents. DAST peut montrer un résultat propre, même si personne n'a testé comment l'agent se comporte avec un contexte adversarial. Et le privilège minimal est souvent implémenté uniquement au niveau du compte de service, sans restreindre les actions réelles autorisées via les outils.

"Aucun plan ne survit au premier contact."

L'auteur utilise cette idée comme un principe de conception : l'invite système doit définir l'intention, pas essayer de décrire rigidement tout l'algorithme de comportement. D'où un autre paramètre de risque critique : le produit de la fenêtre d'autonomie et du rayon d'explosion des outils disponibles. Plus longtemps un agent agit sans point de contrôle humain et plus large son ensemble de capacités, plus élevé le dommage potentiel même avec des droits d'accès formellement corrects. C'est pourquoi les fenêtres d'autonomie deviennent un paramètre architectural, pas seulement opérationnel.

Ce que cela signifie

Agentic SAMM capture un changement qui s'est déjà produit dans le développement d'IA : la sécurité vérifie maintenant non seulement le code mais le comportement du système après la libération. Pour les équipes qui construisent des produits basés sur des agents et le vibe coding, c'est un signal pour revoir les modèles de menace, l'examen du code et le contrôle des outils avant que la première erreur autonome ne devienne un incident complet.