Intégrer la sécurité des agent skills dans une chaîne DevSecOps

⏱️

Temps de lecture estimé
~10 minutes

Cet article clôt la série OWASP Agentic Skills Top 10. Il propose un workflow DevSecOps outillé pour traiter, en avril 2026, l’ensemble des risques AST01 à AST10 dans une chaîne CI/CD existante.

La quasi-totalité des chaînes DevSecOps embarquent déjà du SAST, du SCA, du container scanning et un contrôle de signature des artefacts. Aucun de ces outils, pris isolément, ne couvre les agent skills. Les payloads ne se cachent plus uniquement dans du code exécutable : ils transitent par du langage naturel embarqué dans des fichiers Markdown, par des manifestes incomplets, par des permissions mal mappées entre plateformes. Cet article propose une intégration en quatre étapes, adossée à des outils réels disponibles en avril 2026.

Sécuriser les skills d’agents, ce n’est pas ajouter un scanner de plus. C’est étendre la chaîne DevSecOps existante avec des contrôles spécifiques au langage naturel, à la provenance et à la gouvernance.

Pourquoi les chaînes existantes ne suffisent pas

On constate trois angles morts dans les chaînes DevSecOps « classiques » face aux agent skills.

D’abord, le SAST et le SCA ignorent le langage naturel. Semgrep, Bandit, Gitleaks, Trivy, Grype et OSV-Scanner analysent du code source, des dépendances ou des images ; ils ne raisonnent pas sur les instructions en français ou en anglais qui se cachent dans un SKILL.md, un AGENTS.md ou un MEMORY.md. Un payload de prompt injection passe sans déclencher la moindre alerte.

Ensuite, la provenance des skills n’est pas vérifiée par défaut. Les workflows de signature (Sigstore, cosign, SLSA) sont mûrs côté conteneurs et binaires, mais leur usage sur les artefacts de skills reste minoritaire. La plupart des installations passent par un git clone ou un copier-coller depuis un registre communautaire, sans la moindre attestation.

Enfin, les skills sont absents de l’inventaire de production. SBOM applicatif, SBOM conteneurs, SBOM dépendances : aucun ne liste les skills installés sur les postes de développement ou activés dans les agents. Les obligations de NIS2, DORA, EU AI Act et ISO/IEC 42001 portent pourtant explicitement sur l’ensemble des composants IA, skills compris.

Tant que les skills ne sont ni inventoriés, ni scannés sémantiquement, ni vérifiés en provenance, le reste de la chaîne DevSecOps est aveugle sur une surface d’attaque entière.

Étape 1 - Inventorier tous les skills

L’inventaire est le contrôle zéro de toute la chaîne (AST09). On vise une couverture exhaustive des trois surfaces :

Le dépôt : tous les fichiers SKILL.md, skill.json, manifest.json, AGENTS.md, SOUL.md, MEMORY.md quelle que soit leur arborescence.
Les postes de développement : skills installés via Claude Code, OpenAI Apps SDK, Cursor, Continue, Cline, Roo, Copilot Studio, OpenClaw Skills Hub.
Les agents en production : skills activés dans les pipelines RAG, dans les agents A2A, dans les workflows Composio ou LangChain.

Type de fichier	Plateformes typiques	Risques AST associés
`SKILL.md`	OpenClaw, Claude Skills	AST01, AST04
`skill.json`	Claude Code, OpenAI Apps SDK	AST03, AST05
`manifest.json`	Cursor, Codex, Continue	AST04, AST10
`AGENTS.md`, `SOUL.md`, `MEMORY.md`	Agents persistants	AST01, AST06

Côté outillage open source, on s’appuie sur CycloneDX 1.6 pour publier un AI-BOM listant les skills comme composants à part entière, en parallèle du SBOM applicatif. Le fait que CycloneDX 1.6 supporte nativement les types machine-learning-model et data permet de rester sur un format unique pour l’ensemble de la chaîne. On peut alors générer le SBOM/AI-BOM avec Syft, l’interroger avec Dependency-Track, le corréler aux CVE via OSV-Scanner, et déclencher des alertes via Trivy ou Grype.

Étape 2 - Scanner avec un outil hybride

Le scan d’un skill doit couvrir trois surfaces simultanément (AST08) :

Le code exécutable embarqué (Python, Bash, Node, expressions sandbox-ées). C’est le terrain de Semgrep, Bandit, Gitleaks et des linters open source associés.
Le langage naturel des instructions, descriptions et exemples. C’est là qu’interviennent les outils open source spécialisés agents : garak et Promptfoo côté tests offensifs et red teaming, ModelScan (Protect AI, OSS) pour l’analyse statique des artefacts ML, LLM Guard (Protect AI, OSS) et Vigil pour la détection de prompt injection, NeMo Guardrails (NVIDIA, OSS) et Rebuff côté garde-fous, Giskard et DeepEval côté évaluation continue.
Les métadonnées du manifeste : permissions déclarées, signature, hash, tier de risque, plateformes supportées, compatibilité de scopes (AST04).

Un scanner qui ne fait que du pattern-matching regex sur des mots-clés du type « ignore previous instructions » ne couvre que la couche la plus visible. Les payloads observés en 2025-2026 utilisent obfuscation Unicode, instructions multi-tours et conditionnement par variables d’environnement.

L’analyse sémantique LLM-as-judge devient un standard pratique : on fait évaluer chaque skill par un modèle entraîné à détecter les structures de prompt injection, les escalades de privilèges déguisées et les comportements conditionnels. La sortie est consommée comme n’importe quel résultat de scanner dans la chaîne (SARIF, JUnit, ou format propre intégrable dans DefectDojo).

Étape 3 - Isoler à l’exécution

Tout skill installé devrait s’exécuter dans un environnement isolé (AST06). L’exécution directe sur la machine hôte avec accès complet au système de fichiers est encore le comportement par défaut de plusieurs plateformes, et c’est ce qui rend la plupart des incidents observés exploitables à grande échelle.

En pratique, on combine :

Conteneurs éphémères (Docker, Podman) avec --read-only, --network=none ou allow-list réseau, --memory et --cpus plafonnés, tmpfs pour /tmp.
MicroVM type Firecracker, Kata Containers ou gVisor pour les skills à risque élevé (tier high) afin d’obtenir une isolation au niveau noyau.
Bubblewrap ou Landlock côté Linux desktop pour les skills exécutés sur poste développeur.
Allow-list de domaines sortants gérée via un proxy ouvert (par exemple Squid, Envoy ou mitmproxy en mode mTLS) plutôt qu’un accès Internet ouvert.
Filtrage strict des variables d’environnement : aucun secret cloud (AWS_, AZURE_, GCP_*, GH_TOKEN) ne doit fuiter dans l’environnement d’un skill, conformément à AST03.
Approbation explicite pour tout skill demandant un accès hôte, écrit en clair dans le manifeste de gouvernance (AST09).

Étape 4 - Gouverner comme des dépendances logicielles

On gagne en maturité dès qu’on traite les skills exactement comme on traite déjà les dépendances npm, pip ou Maven.

Pratique	Dépendances logicielles	Agent Skills
Lock file	`package-lock.json`, `poetry.lock`, `go.sum`	Pinning par hash SHA-256 du contenu complet du skill
Registry privé	Harbor, Gitea Packages, OCI Distribution	Skills Hub interne basé sur OCI, miroir des skills approuvés
Review obligatoire	Renovate + revue humaine	Revue manuelle du `SKILL.md` + scan sémantique
SBOM / AI-BOM	CycloneDX, SPDX	AI-BOM CycloneDX 1.6 incluant les skills
Audit	`pip-audit`, OSV-Scanner, Trivy	Logs structurés des actions de chaque skill
Signature	Sigstore / cosign, SLSA, in-toto	Signature cosign + attestation SLSA du manifeste
Vulnérabilités	OSV.dev, GHSA	Suivi via Dependency-Track + flux AST OWASP

Côté workflow, on s’appuie sur OPA / Gatekeeper ou Kyverno pour formaliser les règles d’approbation, sur OpenSSF Scorecard et deps.dev pour qualifier la confiance amont des skills open source, et sur in-toto / SLSA pour rendre la chaîne de production des skills attestable bout en bout.

Workflow DevSecOps proposé

On peut intégrer les quatre étapes dans une chaîne CI/CD existante en l’augmentant des contrôles spécifiques aux skills, sans casser ce qui fonctionne déjà côté code applicatif. Pour rester lisible, on présente d’abord la vue macro des quatre maillons, puis le détail de chaque maillon dans son propre schéma.

Vue d’ensemble

flowchart LR
    Dev["👨‍💻 Dev<br/>(import / édition skill)"] --> CI["🔁 CI<br/>(scan hybride + provenance)"]
    CI --> Gov["📋 Gouvernance<br/>(tier + approbation)"]
    Gov --> Prod["🚀 Production<br/>(sandbox + audit)"]
    Prod -. "revalidation forcée" .-> Gov

Maillon 1 - Poste développeur

flowchart LR
    A[Modification ou import de skill] --> B[Pre-commit hooks]
    B --> C[Lint manifeste : permissions / scopes]
    C --> D[Vérif locale signature cosign]
    D --> E[Push vers le pipeline CI]

Maillon 2 - Pipeline CI

flowchart LR
    A[Build et tests applicatifs] --> B[SAST / SCA / Container scan]
    B --> C[Inventaire skills + AI-BOM CycloneDX 1.6]
    C --> D[Manifest lint + mapping de scopes]
    D --> E[Vérif provenance : cosign + SLSA + in-toto]
    E --> F[Scan hybride : code + NL + métadonnées]
    F --> G[Test en sandbox : Firecracker / gVisor / Kata]
    G --> H{Résultat}
    H -- échec --> X[Pipeline bloqué]
    H -- succès --> Y[Vers Gouvernance]

Maillon 3 - Gouvernance

flowchart LR
    A[Skill validé par la CI] --> B{Tier de risque}
    B -- low --> C[Registry interne approuvé]
    B -- medium / high --> D[Approbation OPA / Kyverno + revue humaine]
    D --> C
    C --> E[Publication AI-BOM dans Dependency-Track]
    E --> F[Vers Production]

Maillon 4 - Production et boucle de revalidation

flowchart LR
    A[Activation du skill] --> B[Allow-list registres + proxy sortant]
    B --> C[Sandbox runtime + secrets filtrés]
    C --> D[Audit logging vers SIEM]
    D --> E[Revalidation périodique selon tier]
    E -. "skill expiré, orphelin ou anormal" .-> F((Retour Gouvernance))

On retient trois principes structurants pour l’ensemble de ce workflow.

Principe 1 - Échec par défaut. Tout skill qui ne passe pas l’une des étapes (manifest incomplet, provenance non vérifiable, scan hybride en alerte, sandbox impossible) est bloqué, pas signalé pour information.

Principe 2 - Asservissement au tier de risque. Le tier (low / medium / high) déclaré dans le manifeste détermine la profondeur des contrôles. Un skill « high » exige une isolation Firecracker/gVisor, une revue humaine, une revalidation trimestrielle. Un skill « low » peut se contenter d’un conteneur read-only et d’une revalidation semestrielle.

Principe 3 - Boucle de revalidation. L’AI-BOM en production est rebouclé vers la gouvernance : tout skill expiré, orphelin (auteur supprimé), ou présentant un comportement anormal en runtime déclenche une revalidation forcée, en cohérence avec AST07 et AST09.

Outils open source recommandés en avril 2026

On retient ci-dessous une sélection d’outils strictement open source, organisée par étape de la chaîne. Aucun de ces outils n’est imposé ; l’idée est de montrer qu’il existe pour chaque maillon une réponse libre, intégrable, et auditable.

Maillon de la chaîne	Outils open source utiles en avril 2026
Inventaire / AI-BOM	CycloneDX 1.6, Syft, Dependency-Track, OSV-Scanner, Trivy, Grype
Scan code	Semgrep, Bandit, Gitleaks, OSV-Scanner
Scan NL et IA	garak, Promptfoo, ModelScan (Protect AI), LLM Guard (Protect AI), Vigil, NeMo Guardrails (NVIDIA), Rebuff, Giskard, DeepEval
Provenance / signature	Sigstore / cosign, SLSA, in-toto, OpenSSF Scorecard, deps.dev
Sandbox	Docker, Podman, Firecracker, Kata Containers, gVisor, Bubblewrap, Landlock
Registry / supply chain	Harbor, Gitea Packages, OCI Distribution, Renovate
Gouvernance / policy-as-code	OPA / Gatekeeper, Kyverno, Conftest
Runtime / observabilité agents	Falco, Tetragon, OpenTelemetry, Langfuse, Phoenix (Arize)
SIEM / SOC	Wazuh, OpenSearch Security Analytics, TheHive, Cortex, MISP
Triage / suivi vulnérabilités	DefectDojo

Le bon réflexe n’est pas d’empiler les outils, mais de relier la chaîne existante (SAST/SCA/SBOM/SIEM) à un scanner hybride open source dédié aux skills et à un AI-BOM CycloneDX 1.6 partagé.

Mapping étape par étape avec les risques AST10

Étape du workflow	Risques couverts	Contrôle principal
Inventaire / AI-BOM	AST09	Détection des shadow skills et des orphelins
Manifest lint + scope mapping	AST03, AST04, AST10	Permissions excessives, métadonnées falsifiées, mapping cross-plateforme
Provenance (cosign / SLSA)	AST01, AST02, AST07	Skills malveillants, supply chain, dérive de version
Scan hybride (code + NL)	AST01, AST05, AST08	Payloads NL, désérialisation dangereuse, évasion de scanner
Sandbox runtime	AST06	Isolation processus, fichiers, réseau
Governance gate (OPA/Kyverno)	AST09, AST10	Approbation, revalidation cross-plateforme, registry shopping
Boucle de revalidation	AST07, AST09	Détection de dérive, désactivation des skills orphelins

Quelques références pour aller plus loin

✓ À retenir 📌

✓ Quatre étapes à intégrer dans la chaîne DevSecOps existante : inventorier (AI-BOM CycloneDX 1.6), scanner en hybride (code + langage naturel + métadonnées), isoler en sandbox, gouverner comme des dépendances.

✓ Le scan regex est un minimum viable, jamais une cible. L'analyse sémantique open source du langage naturel (garak, Promptfoo, ModelScan, LLM Guard, Vigil, NeMo Guardrails, Rebuff, Giskard, DeepEval) est aujourd'hui le seul moyen de couvrir les payloads observés en production.

✓ Les skills sont des dépendances critiques : registry interne basé OCI (Harbor, Gitea Packages), pinning par hash, signature cosign, attestation SLSA, AI-BOM partagé, sandbox par défaut, audit logging dans Wazuh/OpenSearch, gouvernance OPA/Kyverno.

✓ Le workflow DevSecOps proposé échoue par défaut, asservit la profondeur des contrôles au tier de risque, et reboucle l'AI-BOM de production vers la gouvernance pour traiter dérive, orphelins et imports cross-plateforme.