Signature et intégrité
Le problème
Un fichier JSON posé à côté d’un artefact n’engage personne. Rien n’y prouve :
- qui l’a produit ;
- quand il a été produit ;
- à quel artefact exactement il correspond ;
- qu’il n’a pas été modifié depuis.
Un SBOM non signé est une déclaration, pas une preuve. Pour un dossier technique destiné à être opposé dix ans plus tard à une autorité, la différence est décisive.
Les mécanismes
Signature du document
Signer le SBOM lui-même, en attachant la signature à l’artefact dans le registre. Deux approches courantes : signature détachée classique avec une clé de l’organisation, ou signature via une infrastructure de signature de chaîne d’approvisionnement du type Sigstore / cosign, avec identité éphémère et journal de transparence.
L’apport du journal de transparence est spécifique : il rend la signature vérifiable publiquement et horodatée, ce qui répond directement à la question « ce SBOM existait-il bien à cette date ».
Empreinte de l’artefact
Le SBOM doit contenir l’empreinte cryptographique de l’artefact qu’il décrit, et l’artefact doit être retrouvable par cette empreinte. C’est ce lien qui permet de démontrer, des années plus tard, que ce SBOM décrit bien ce binaire.
Attestations de provenance
Une attestation est une déclaration signée sur la manière dont l’artefact a été produit : dépôt source, révision, chaîne de construction, paramètres, dépendances. Le modèle in-toto en fournit la structure ; le cadre SLSA en définit des niveaux progressifs.
Le cadre SLSA définit, pour sa piste « construction », quatre niveaux nommés :
| Niveau | Ce qui est exigé |
|---|---|
| Build L0 | Aucune exigence — l’absence de SLSA |
| Build L1 | Le processus de construction est cohérent et une provenance existe, décrivant la plateforme, le processus et les entrées de premier niveau. Elle est distribuée aux consommateurs |
| Build L2 | La construction s’exécute sur une infrastructure dédiée, pas sur un poste individuel, et la provenance y est rattachée par une signature dont l’authenticité est vérifiable en aval |
| Build L3 | La plateforme empêche les exécutions de s’influencer entre elles, et rend le matériel de signature inaccessible aux étapes définies par l’utilisateur |
Les builds reproductibles ne constituent pas un niveau de cette piste : c’est une propriété distincte, décrite ci-dessous, qui renforce la vérifiabilité par un tiers.
Builds reproductibles
Deux constructions du même code produisent des artefacts bit à bit identiques. C’est l’objectif le plus exigeant, et le plus probant : il permet à un tiers de vérifier que le binaire livré correspond bien au code source publié.
Pour un produit soumis à une période de support de dix ans, la reproductibilité a un second intérêt, souvent décisif : elle oblige à figer et documenter l’environnement de construction, donc à pouvoir reconstruire dans huit ans.
Le lien avec les exigences du règlement
| Exigence | Ce que la signature apporte |
|---|---|
| Annexe I, partie I — protection de l’intégrité | Vérification à l’installation et à la mise à jour |
| Annexe I, partie II, point 7 — diffusion sécurisée des mises à jour | Canal authentifié, correctifs signés, protection contre le retour arrière |
| Annexe VII — dossier technique | Preuve datée et non modifiable de ce qui a été livré |
Ce qu’il faut mettre en place
- Signer chaque SBOM à la construction, dans le pipeline, sans intervention humaine.
- Générer une attestation de provenance pour chaque artefact.
- Stocker signatures et attestations avec l’artefact, indexées par empreinte.
- Vérifier la signature avant tout déploiement et avant toute publication.
- Gérer les clés : rotation, révocation, conservation des clés publiques historiques — sans la clé publique de 2027, une signature de 2027 ne se vérifie plus en 2035.
- Tester la restitution : un exercice annuel consistant à retrouver, vérifier et présenter le SBOM signé d’une version ancienne.
Ce dernier point est le seul qui prouve que le dispositif fonctionne. Voir Conservation des preuves.