Agentic SAMM pour des agents sécurisés

# ASAMM agentique : Cadre pour le développement sécurisé de systèmes agentiques

L'ASAMM (Agentic SAMM) étend le cadre OWASP SAMM aux systèmes agentiques, où le cycle de vie du logiciel (SDLC) évolue d'un cycle linéaire vers une spirale. Chaque boucle de la spirale revient aux phases de conception, d'implémentation et de vérification, mais avec un modèle de menaces mis à jour tenant compte des changements dans les outils et les environnements. Le cadre aborde une taxonomie des menaces : le contexte comme plan de contrôle (tout contenu lisible par l'agent peut devenir une commande), l'invocation d'outils comme frontière de sécurité, et la fenêtre d'autonomie comme rayon temporel des dommages potentiels.

Un modèle de confiance à deux axes, inspiré du STANAG de l'OTAN, s'applique aux agents, outils, serveurs MCP et sources de contexte. Les niveaux vont de A1 (permissions totales) à F6 (exécution isolée uniquement) et imposent des règles d'interaction strictes.

Principes de conception et 17 contrôles

La conception suit les principes de l'Auftragstaktik : le prompt système définit l'intention (Auftrag), et non des algorithmes rigides. Cela permet aux agents de s'adapter, comme l'a noté Moltke : aucun plan ne survit au premier contact avec l'ennemi.

L'ASAMM propose 17 contrôles répartis sur les 5 fonctions de SAMM, mappés sur le NIST AI RMF et le NCSC. Deux voies d'implémentation sont disponibles :

• Migration depuis un programme de sécurité existant.
• Déploiement green-field pour les nouveaux projets.

Le cadre est open source : les humains contribuent via les Issues et PR GitHub, les agents créent des tickets en repérant des lacunes.

Points clés pour les développeurs intermédiaires/seniors

L'ASAMM met en lumière un changement de paradigme en sécurité :

• La frontière de sécurité a bougé : le SDLC traditionnel protège le code et les artefacts mais ignore les flux de contexte, les appels d'outils, les permissions déléguées et le comportement à l'exécution.
• Contexte = instruction : documents, tâches de suivi, logs CI ou descriptions d'outils peuvent se transformer en commandes. Des contrôles de traçabilité du contexte sont nécessaires au-delà de la validation d'entrée.
• Autorisation ≠ alignement sur la tâche : des agents pleinement privilégiés peuvent dévier des objectifs, contournant les contrôles traditionnels.
• Le temps comme facteur de risque : la fenêtre d'autonomie multipliée par le rayon des outils définit le rayon d'impact potentiel.
• L'environnement de dev est la surface d'attaque : plugins IDE, serveurs MCP, hooks pre-commit et agents CI exigent une modélisation des menaces.

Erreurs courantes en pratique

Les développeurs omettent souvent les subtilités des systèmes agentiques. Erreurs typiques :

• Modèles de menaces exhaustifs mais sans sources de contexte ni chemins d'invocation d'outils.
• Revue de code sur 100 % des PR, ignorant prompts, schémas d'outils et configs d'agents.
• Scans DAST propres mais sans test du comportement en contexte adversarial.
• Moindre privilège sur comptes de service, sans granularité sur les appels d'outils.
• SCA validé mais ignorant dépendances de frameworks, serveurs MCP et fournisseurs de modèles.

Ce qui compte vraiment

• SDLC en spirale : Adapte les modèles de menaces à l'évolution du système et des outils.
• Taxonomie des menaces : Focalisée sur contexte, outils et fenêtre d'autonomie.
• 17 contrôles : Mappés sur NIST AI RMF/NCSC pour une intégration fluide.
• Open source : Contributions via GitHub pour humains et agents.
• GOST R 56939-2024 : Adaptation russe avec mappings disponibles.

L'ASAMM comble les lacunes des cadres existants, couvrant les surfaces d'attaque agentiques. Son implémentation minimise les risques en production avec des agents autonomes.

— Editorial Team