Domaine de recherche · Sécurité de la chaîne d'approvisionnement
De la nomenclature logicielle à l'agent de codage : rendre les chaînes d'approvisionnement vérifiables
Logiciels, modèles et services proviennent aujourd'hui de nombreuses sources. Vami Research étudie comment rendre cette chaîne d'approvisionnement vérifiable : avec SBOM, VEX et provenance SLSA, avec des AI-SBOM pour les modèles et les données d'entraînement, avec une nomenclature pour les agents de codage et avec des évaluations de prestataires selon les orientations de l'EBA et les catalogues de la Cloud Security Alliance.
- SBOM & VEX
- AI-SBOM
- SLSA
- Slopsquatting
- Agents de codage
- Risque lié aux tiers
- CSA CAIQ & AICM
- Deep Dives
- 6
- Livres blancs
- 3
- Solutions
- 1
La chaîne d'approvisionnement ne s'arrête plus au gestionnaire de paquets
Un logiciel se compose de bibliothèques, de frameworks et de services de tiers. Depuis Log4Shell au moins, une chose est claire : sans transparence sur les composants, impossible de dire si et où une nouvelle vulnérabilité frappe. Le Cyber Resilience Act rend la nomenclature logicielle obligatoire pour les produits comportant des éléments numériques – dans le cadre de la documentation technique, au moins pour les dépendances de premier niveau. Les obligations de notification s'appliquent depuis le 11 septembre 2026, les obligations principales à partir du 11 décembre 2027.
Avec l'IA, de nouveaux maillons s'ajoutent. Les modèles, les poids et les données d'entraînement déterminent le comportement d'un système d'IA, mais n'apparaissent pas dans une SBOM classique. Les attaques qui les visent sont documentées : en février 2024, JFrog a découvert sur Hugging Face environ 100 modèles piégés dont le code malveillant s'exécute dès le chargement. Les agents de codage étendent la chaîne aux serveurs MCP, aux skills et aux extensions d'éditeur – le 29 octobre 2026, une extension Claude Code manipulée sur la marketplace de Cursor a montré à quel point ce canal de distribution est lui aussi vulnérable.
S'y ajoutent les prestataires ainsi que les fournisseurs cloud et d'IA. Avec NIS2 et DORA, l'évaluation des fournisseurs directs est devenue obligatoire. Publiées le 18 septembre 2026, les orientations EBA/GL/2026/09 établissent un cadre pour les services non-TIC à l'intention des établissements de crédit, des entreprises d'investissement, des établissements de paiement et d'autres entités financières ; leur date d'application n'est pas encore fixée. Vami Research associe des preuves techniques telles que SBOM, VEX et provenance à des évaluations standardisées selon le CSA CAIQ et l'AI Controls Matrix.
Les questions ouvertes du terrain
- 01
Comment faire d'une SBOM, simple document, un système d'alerte précoce pour les nouvelles vulnérabilités ?
Notre approche
Nous misons sur une génération au moment du build, par exemple avec cdxgen ou Syft, versionnée par release et idéalement signée. Ce qui compte ensuite, c'est le rapprochement continu avec NVD, OSV et les GitHub Advisories ; VEX consigne si un composant vulnérable affecte réellement le produit. VamiAppSec surveille chaque SBOM livrée afin de détecter les vulnérabilités activement exploitées, notamment via CISA KEV, et priorise avec EPSS.
- 02
Que doit contenir la nomenclature d'un système d'IA dont le comportement évolue sans modification du code ?
Notre approche
Outre les bibliothèques, nous inventorions les modèles, les poids ainsi que les données d'entraînement et d'évaluation, provenance comprise. Depuis la version 1.5, CycloneDX traite les modèles et les données comme des composants à part entière, SPDX 3.0 propose un profil AI et un profil Dataset, et les model cards deviennent lisibles par machine. Une AI-SBOM tenue à jour fournit le socle de données nécessaire aux obligations de documentation découlant du Cyber Resilience Act et de l'AI Act.
- 03
Comment introduire des agents de codage sans perdre le contrôle de la chaîne d'approvisionnement ?
Notre approche
Comme toute autre modification : les nouvelles dépendances et les modifications des fichiers de lock nécessitent une validation nominative lors de la revue des dépendances, imposée par un proxy de registre interne avec liste d'autorisation. Pour les entités financières soumises au cadre complet de DORA, les normes techniques de réglementation exigent de séparer l'approbation et la mise en œuvre des modifications – un agent qui fusionne ses propres pull requests ne cadre pas avec cette exigence.
- 04
Comment les organisations pilotent-elles les risques liés aux tiers – TIC, non-TIC, cloud et services d'IA – dans un seul cadre ?
Notre approche
Par un cycle de vie : recenser les tiers, les classer selon leur criticité, évaluer leurs pratiques de sécurité et les encadrer contractuellement – de l'achat jusqu'à la sortie. Nous évaluons les services d'IA selon l'AI Controls Matrix de la CSA, qui couvre notamment l'empoisonnement de modèles et l'injection de prompt. Les orientations de l'EBA attendent expressément des entités financières une approche globale couvrant TIC et non-TIC.
Ce que nous retenons
- 01
Une SBOM ne porte ses fruits qu'en exploitation
Générer un fichier une seule fois ne constitue pas encore une gestion des SBOM. La nomenclature ne déploie son utilité que dans le rapprochement continu avec les données de vulnérabilités : face à une nouvelle CVE, on peut alors dire immédiatement quels produits contiennent des composants concernés. VEX complète la SBOM par la déclaration du fabricant indiquant si un composant vulnérable affecte réellement le produit.
Source: Gestion des SBOM
- 02
Les modèles d'IA peuvent changer sans que le code ne bouge
Le comportement d'un système d'IA dépend du modèle, des poids et des données d'entraînement – des artefacts qu'une SBOM classique ne recense pas. Un réentraînement ou un fine-tuning peut modifier un modèle en profondeur, alors que le code et les versions des paquets restent identiques. Une AI-SBOM selon CycloneDX ML-BOM ou SPDX 3.0 rend ces éléments évaluables.
Source: AI-SBOM
- 03
Un inventaire d'agents limité aux noms devient obsolète en silence
Les agents de codage apportent leurs propres maillons à la chaîne d'approvisionnement : outil, modèle et fournisseur, serveurs MCP, skills et fichiers de règles. Les serveurs MCP distants peuvent changer sans que l'organisation s'en aperçoive. Nous recommandons donc une nomenclature des agents lisible par machine, avec version ou hachage pour les serveurs MCP et les skills – tenue à côté de la SBOM de chaque release.
- 04
L'évaluation des fournisseurs est un processus, pas un questionnaire
Un questionnaire rempli décrit un fournisseur à une date de référence. L'évaluation ne devient solide qu'en tant que processus continu : classer la criticité, exploiter les réponses CAIQ ou AICM ainsi que les certificats et rapports d'audit, et lier les réévaluations à des déclencheurs définis – complétée, pour les fonctions critiques, par une analyse du risque de concentration et une stratégie de sortie selon DORA.
Notre démarche
Vami Research considère la chaîne d'approvisionnement comme une chaîne de preuves : ce que contient un artefact, comment il a été construit, qui le livre et quels agents ont le droit de le modifier.
SBOM au moment du build
Générer les nomenclatures en CycloneDX ou SPDX directement lors du build, les versionner par release et les stocker avec les artefacts – par exemple avec cdxgen ou Syft.
VEX et rapprochement des vulnérabilités
Rapprochement continu avec NVD, OSV et les GitHub Advisories ; les documents VEX et CSAF consignent quelles découvertes affectent réellement un produit.
AI-SBOM
Recenser modèles, poids et jeux de données comme composants : CycloneDX ML-BOM, profils SPDX 3.0 pour AI et Datasets, model cards lisibles par machine.
Provenance SLSA
Preuves de provenance sous forme d'attestations in-toto, signées et vérifiées avant le déploiement ; progression selon les niveaux L1 à L3 du Build Track.
Nomenclature des agents
Pour chaque agent de codage, consigner de manière lisible par machine l'outil et sa version, le modèle et le fournisseur, les serveurs MCP, les skills et les fichiers de règles – serveurs MCP et skills avec version ou hachage.
Évaluation des fournisseurs selon des catalogues
CSA CCM et CAIQ pour les fournisseurs cloud, AI Controls Matrix pour les services d'IA – exploités conjointement avec les certificats et rapports d'audit disponibles.
Pour démarrer
- 1Constituer l'inventaireRecenser composants, modèles, extensions et prestataires et les classer selon leur criticité – comme base de toute évaluation.
- 2Ancrer les contrôlesSBOM et provenance dans le build, validations pour les nouvelles dépendances et extensions, obligations contractuelles pour les fournisseurs et les prestataires.
- 3Surveiller en continuRapprocher les SBOM livrées de CISA KEV et prioriser avec EPSS, réévaluer les fournisseurs lors de déclencheurs définis, tenir les preuves pour le CRA, NIS2 et DORA.
Deep Dives, livres blancs et analyses
Deep Dives 6
Livres blancs 3
Du domaine à la mise en œuvre
Domaines de recherche connexes
Vérifier votre chaîne d'approvisionnement, de la SBOM à l'agent de codage ?
Nous évaluons avec vous le processus SBOM, les composants d'IA, les politiques relatives aux agents et les prestataires critiques, et rattachons les résultats au CRA, à NIS2 et à DORA. Contactez-nous pour un premier entretien sans engagement.