Le cycle de vie du SBOM
La règle de base
Un SBOM par construction. Immuable une fois produit, versionné, associé à l’artefact par son empreinte cryptographique.
Corollaires :
- on ne modifie jamais un SBOM émis ; on en émet un nouveau ;
- un SBOM « du produit », sans référence de version ni de construction, n’a pas de valeur ;
- deux constructions du même code à deux dates différentes peuvent produire deux SBOM différents, si les dépendances ont été résolues différemment — ce qui est en soi une information utile.
Les étapes
| Étape | Où | Ce qui est produit |
|---|---|---|
| Génération | Pipeline de construction | Build SBOM |
| Validation | Pipeline | Score de qualité, échec sous le seuil |
| Signature | Pipeline | SBOM signé, attestation de provenance |
| Publication | Plateforme de pilotage | Ingestion, corrélation initiale |
| Attachement | Registre d’artefacts | SBOM indexé par empreinte, à côté de l’image |
| Surveillance | Plateforme | Réévaluation quotidienne contre les sources |
| Enrichissement | PSIRT | Ajout des VEX au fil des analyses |
| Archivage | Coffre de preuves | Conservation longue durée, immuable |
| Restitution | Sur demande | Extraction d’une version historique |
| Suppression | Fin de la durée de conservation | Purge tracée |
La durée de conservation
Alignée sur celle du dossier technique : au moins dix ans après la mise sur le marché du produit, ou pendant la période de support si celle-ci est plus longue.
Cela signifie qu’un SBOM produit aujourd’hui pour un produit encore commercialisé dans cinq ans devra être restituable dans quinze ans. Les conséquences pratiques sont sous-estimées :
- le format doit rester lisible — d’où l’intérêt de formats normalisés plutôt que propriétaires ;
- les clés publiques de vérification des signatures doivent être conservées ;
- le support de stockage doit être migré au moins une fois ;
- l’indexation doit survivre au changement de plateforme.
L’indexation
Un SBOM inaccessible équivaut à un SBOM absent. L’index minimal :
| Clé | Pourquoi |
|---|---|
| Produit et version commerciale | Point d’entrée d’une demande d’autorité ou de client |
| Référence de construction | Lien avec la chaîne CI |
| Empreinte de l’artefact | Preuve de correspondance |
| Date de construction et de mise sur le marché | Point de départ des dix ans |
| Format et version du format | Choix de l’outil de lecture |
| Signature et clé | Vérification |
| VEX associés | Contexte de la décision de traitement |
La comparaison entre versions
Le différentiel de SBOM entre deux versions répond à des questions récurrentes :
- quels composants ont été ajoutés, et par quel chemin de dépendance ?
- quels composants ont été mis à jour, et cela corrige-t-il des vulnérabilités connues ?
- quelles licences ont fait leur apparition ?
- la surface augmente-t-elle version après version ?
Cette comparaison alimente utilement la revue de changement, et détecte les introductions non intentionnelles — un candidat sérieux au tableau de bord d’ingénierie.
Le test qui compte
Une fois par an, un exercice de restitution : choisir au hasard une version livrée il y a plus de deux ans, et produire en moins d’une journée son SBOM signé, sa signature vérifiée, ses VEX et son dossier technique.
Tant que cet exercice n’a pas été réussi, le dispositif d’archivage est une hypothèse.