Générer et piloter : les deux niveaux

C’est le malentendu le plus coûteux du sujet, et la page qui conditionne la compréhension de tout le reste. Beaucoup d’organisations achètent une plateforme sans avoir de génération fiable, ou génèrent des milliers de SBOM que personne n’agrège.

Le schéma

┌─────────────────────────────────────────────────────────────────┐
│  NIVEAU 1 — APPLICATION / ÉQUIPE              « GÉNÉRER »        │
│                                                                  │
│  Où ?     Dans la chaîne CI/CD, à chaque construction            │
│  Qui ?    L'équipe de développement, le DevSecOps                │
│  Quoi ?   Produire un inventaire fidèle de CET artefact          │
│  Outils   Syft · Trivy · Grype · cdxgen · osv-scanner ·          │
│           plugins natifs Maven, Gradle, npm, .NET, Cargo         │
│  Sortie   Un fichier CycloneDX ou SPDX signé, lié à l'artefact   │
│  Maille   1 SBOM = 1 artefact = 1 construction                   │
│  Temps    Instantané, figé, immuable                             │
└──────────────────────────────┬──────────────────────────────────┘
                               │  ingestion automatisée (API)
                               ▼
┌─────────────────────────────────────────────────────────────────┐
│  NIVEAU 2 — ORGANISATION / PORTEFEUILLE       « PILOTER »        │
│                                                                  │
│  Où ?     Dans une plateforme centrale, en continu               │
│  Qui ?    RSSI, PSIRT, Conformité, Direction produit             │
│  Quoi ?   Agréger, historiser, corréler chaque jour, décider     │
│  Outils   OWASP Dependency-Track · Snyk · FOSSA ·                │
│           Black Duck · Mend · Sonatype · JFrog Xray              │
│  Sortie   Vue portefeuille, alertes ciblées, VEX, rapports,      │
│           pièces pour le dossier technique et les autorités      │
│  Maille   N produits × M versions × K composants                 │
│  Temps    Continu, historisé, réévalué chaque jour               │
└─────────────────────────────────────────────────────────────────┘

Les six différences

	Niveau application — générer	Niveau organisation — piloter
Question posée	« Que contient cet artefact ? »	« Lesquels de vos produits contiennent ce composant ? »
Déclencheur	Une construction	Une vulnérabilité nouvellement publiée
Propriétaire	Équipe produit	PSIRT, RSSI, Conformité
Fréquence	À chaque construction publiable	Réévaluation quotidienne du parc
Sortie	Un fichier	Un tableau de bord, des alertes, des rapports, une API
Sans lui	Aucune donnée : rien n’est possible	Des milliers de fichiers inexploitables

Ce que chaque niveau démontre au regard du CRA

Exigence	Niveau qui la couvre
Annexe I, partie II, point 1 — inventaire des composants	Génération
Annexe VII — SBOM au dossier technique	Génération (+ archivage)
Annexe I, partie II, point 2 — traiter les vulnérabilités sans délai	Pilotage
Annexe I, partie II, point 3 — tests et revues réguliers	Les deux
Annexe I, partie II, point 4 — publier les avis	Pilotage
Art. 14 — signaler sous 24 h en connaissant le périmètre affecté	Pilotage
Réponse à une demande d’autorité portant sur une version ancienne	Pilotage (+ archivage)

Le CRA exige les deux. Le point 1 impose l’inventaire ; les points 2, 3, 4 et 7 imposent un processus continu, qu’un fichier posé à côté d’un artefact ne peut pas démontrer.

L’erreur classique, nommée

« On a mis un scanner dans la CI, on est conformes. »

Non. Un scanner en CI vous dit ce qui va mal maintenant, ici, dans cette construction. Il ne vous dit pas :

quelles versions déjà livrées chez des clients contiennent le composant vulnérable ;
ce qui est devenu vulnérable depuis la dernière construction, sans qu’aucun code n’ait changé ;
quel est le périmètre affecté à déclarer dans une alerte à 24 heures ;
ce que contenait la version 4.2.1 livrée en 2028, interrogée par une autorité en 2033.

L’erreur symétrique existe aussi : acheter une plateforme sans génération fiable. La plateforme affiche alors une couverture trompeuse, alimentée par des SBOM partiels produits manuellement.

Le message par public

Pour le Juridique. Le niveau 1 produit la pièce du dossier technique. Le niveau 2 produit la preuve du processus continu. Sans le premier, le dossier est incomplet ; sans le second, on ne peut ni répondre à une autorité, ni tenir un délai de 24 heures.

Pour la Cyber. Ne pas confondre le scanner et la plateforme. Ce ne sont pas deux produits concurrents : c’est une chaîne, et le maillon manquant est presque toujours le second.

Pour la Direction. Deux lignes budgétaires, deux propriétaires, deux calendriers. Le niveau 1 se déploie par équipe, progressivement. Le niveau 2 est une plateforme transverse qui doit exister avant que les SBOM ne s’accumulent sans destination.

L’ordre de déploiement

Choisir le format pivot et figer l’outillage par famille de produits.
Déployer la plateforme de pilotage, même minimale, avant de généraliser la génération.
Généraliser la génération, en publiant systématiquement vers la plateforme.
Activer la surveillance continue une fois la couverture significative.
Ajouter les politiques bloquantes, en avertissement d’abord, en blocage ensuite.

Déployer dans cet ordre évite la situation la plus fréquente : des équipes qui génèrent consciencieusement des SBOM depuis dix-huit mois, sans que personne ne puisse répondre à la question qui compte.