Ce guide vous explique comment configurer Witness pour instrumenter votre build, puis comment utiliser SBOMit pour générer un fichier SBOM enrichi à partir du fichier attestation obtenu.
Conditions préalables
Partie 1 : Witness
Witness encapsule votre processus de compilation et enregistre l’attestations signée, qui constitue une piste d’audit cryptographique.
1. Installer « Witness »
bash <(curl -s https://raw.githubusercontent.com/in-toto/witness/main/install-witness.sh)
Ou téléchargez un fichier binaire depuis la page des versions de Witness.
2. Créer une paire de clés de signature
Witness signe chaque fichier « attestation » à l’aide d’une clé privée. Pour effectuer un test rapide en local :
openssl genpkey -algorithm ed25519 -outform PEM -out testkey.pem
openssl pkey -in testkey.pem -pubout > testpub.pem
> Astuce : Witness prend également en charge la signature sans clé via SPIRE/SPIFFE et > Sigstore Fulcio pour les environnements CI/CD.
3. Configurer Witness
Créez un fichier .Witness.yaml à la racine de votre projet. Ce fichier est généralement ajouté au contrôle de version en même temps que votre
clé publique :
# .witness.yaml
run:
signer-file-key-path: testkey.pem
trace: false
verify:
attestations:
- "attestation.json"
policy: policy-signed.json
publickey: testpub.pem
Les options de ligne de commande ont priorité sur les valeurs du fichier de configuration. Exécutez « Witness help » pour afficher toutes les options.
4. Enveloppez votre montage
Ajoutez « Witness run » au début de votre commande de compilation pour générer un fichier « attestation » :
witness run --step build -o attestation.json -- <your-build-command>
Projet Go :
witness run --step build -o attestation.json -- go build -o myapp .
Projet Python :
witness run --step build -o attestation.json -- pip install -r requirements.txt
Witness exécute toujours un ensemble de base d’
attestateurs — voir Witness attestors list pour la liste complète.
> Astuce : Pour les compilations qui génèrent de nombreux fichiers (par exemple, node_modules), utilisez
> --dirhash-glob node_modules/* afin de calculer le hachage du contenu du répertoire plutôt que celui de chaque fichier individuellement.
5. Vérifier l’attestation
Le fichier « attestation » est une enveloppe DSSE signée. Pour afficher le contenu :
cat attestation.json | jq -r .payload | base64 -d | jq
Vous verrez une collection « attestation » contenant des attestations de type : material, command-run,
product, environment et, éventuellement, network-trace. Il s’agit des données utilisées par l’SBOMit.
Partie 2 : SBOMit
À partir d’un fichier « attestation », SBOMit génère un fichier « SBOM » enrichi en exécutant des résolveurs de paquets spécifiques à chaque langage sur les données de compilation Witness observées.
1. Installer « SBOMit »
go install github.com/sbomit/sbomit@latest
2. Générer une «SBOM » enrichie
# SPDX 2.3 (default)
sbomit generate attestation.json
# SPDX 2.2
sbomit generate attestation.json -f spdx22
# CycloneDX 1.5
sbomit generate attestation.json -f cdx15
# CycloneDX 1.4
sbomit generate attestation.json -f cdx14
3. (Facultatif) –catalog pour générer l’arborescence des dépendances
SBOMit peut faire appel à Syft comme source de catalogue supplémentaire, en fusionnant ses résultats avec les données issues d’attestation :
sbomit generate attestation.json --catalog syft --project-dir /path/to/project
SBOMitgénère (pour l’instant) une liste plate de dépendances : il sait ce qui a été installé et utilisé, mais ne reconstitue pas l’arborescence complète des dépendances. Syft, pour les écosystèmes où il peut déterminer la structure arborescente (par exemple, les modules Go ou npm), conserve cette relation parent-enfant dans sa sortie.
En passant l’option --catalog syft, SBOMit utilise l’arborescence des dépendances de Syft comme base, puis
la complète avec tout ce que Syft ne peut pas détecter : les versions réelles installées au moment de la compilation,
les bibliothèques natives, les fichiers non gérés par un gestionnaire de paquets, ainsi que la provenance des appels réseau capturée
par Witness.
