Vérifier vos téléchargements

Les binaires bits s'exécutent sur vos hôtes avec une visibilité privilégiée, et bitcollector produit les preuves sur lesquelles vous et votre auditeur vous appuyez. Une preuve ne vaut jamais plus que l'instrument qui l'a produite.

Avant toute installation, vous devez donc pouvoir prouver exactement quels octets vous êtes sur le point d'exécuter. Cette page vous montre comment, avec des outils publiés uniquement, hors ligne.

Si une vérification échoue

N'installez pas le binaire. Ne « retentez pas le téléchargement en espérant que ça passe ». Conservez les fichiers et écrivez à [email protected] en indiquant la version publiée et la sortie de la commande qui a échoué.

Ce qui accompagne chaque version publiée

Fichier	De quoi il s'agit
bitcollector-<os>-<arch>	Le binaire lui-même
bitcollector-<os>-<arch>.sbom.json	SBOM CycloneDX — tout ce que contient ce binaire
bitcollector-<os>-<arch>.sig	Bundle de signature cosign portant sur ces octets exacts
bitcollector-<os>-<arch>.att	Attestation cosign liant le SBOM à ces octets exacts
SHA256SUMS	Sommes de contrôle de chacun des fichiers ci-dessus
SHA256SUMS.sig	Signature cosign de SHA256SUMS
release-provenance.json	Commit, chaîne d'outils Go et plateformes à partir desquels la version a été compilée

Les versions de bitscanner, bitenforcer et bitmapper ont la même structure, avec leur propre nom à la place de bitcollector. Les quatre produits sont signés avec la même clé de publication, donc une seule vérification de clé couvre toute la famille — et une clé qui changerait entre deux d'entre eux serait une raison de s'arrêter, pas de mettre à jour votre copie.

Étape 0 — se procurer les outils

Il vous faut cosign v3 ou plus récent, et sha256sum (fourni par coreutils ; sur macOS, shasum -a 256 ou brew install coreutils).

cosign version

Étape 1 — récupérer la clé publique, et vérifier que c'est la bonne clé

Téléchargez la clé de signature de publication à côté du répertoire de la release, et non dedans :

# depuis le répertoire qui CONTIENT votre répertoire de release
# DNS route — works from a CLI and inside CI. The HTTPS copy of this key is
# currently behind a bot challenge, so `curl` cannot fetch it; see the note below.
dig +short TXT _cosign-key.cert-ix.com | tr -d '"' | sed 's/.*key=//' \
  | base64 -d | openssl pkey -pubin -inform DER -out cosign.pub

Placez la clé à côté de la release, pas à l'intérieur

verify-release.sh considère tout fichier présent dans un répertoire de release comme un fichier qui devrait être signé. Y déposer cosign.pub lui fait signaler un fichier non justifié — ce qui ressemble exactement à une release altérée, alors qu'il n'en est rien. Gardez la clé un niveau au-dessus. Pour la même raison, indiquez-la par chemin absolu : le script se place dans le répertoire de la release, un --key cosign.pub relatif cesse donc d'être résolu, et l'échec affiché est indiscernable d'une mauvaise signature.

→ cosign.pub

Ne sautez pas cette étape. C'est elle qui donne un sens à tout le reste.

Un attaquant capable de remplacer un binaire sur notre site web peut remplacer la clé publique qui se trouve à côté. La vérification passerait alors — contre sa clé. Vous exécuteriez son binaire et obtiendriez une coche verte.

Une vérification de signature ne vaut que l'ancre de confiance qui la sous-tend. Confirmez l'empreinte de la clé auprès d'une seconde source indépendante avant de lui faire confiance. C'est tout l'objet des quelques lignes qui suivent, et c'est l'étape que la plupart des instructions de vérification omettent.

L'empreinte

Calculez l'empreinte de la clé que vous avez téléchargée :

# The robust form: SHA-256 of the DER-encoded public key.
# Independent of PEM whitespace, so copy-paste through a browser cannot change it.
openssl pkey -pubin -in cosign.pub -outform DER | sha256sum

Elle doit valoir exactement :

552839f6b1b1eb0934557e1886326c7270584fa602fbf56f84754a98be3de822

Si vous préférez hacher le fichier tel quel :

sha256sum cosign.pub
# 150eacccc1bc26a83c746a1e441b0b0bdc8104c3ef07efd75c62deb5b069f914

Cette seconde valeur couvre les octets exacts du fichier publié, saut de ligne compris : elle ne correspond donc que si vous avez téléchargé le fichier plutôt que d'en coller le contenu.

La clé elle-même est assez courte pour être lue. La voici en entier :

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEPA6gi66NIBXbSwYS3CL16Ien3sho
wCNOR8dRivdd07SQWto107QMDelUKMeebJQHSlOchNO4PJSWjCcrsUYb5w==
-----END PUBLIC KEY-----

C'est une clé publique ECDSA P-256 (prime256v1). Vous pouvez le confirmer vous-même :

openssl pkey -pubin -in cosign.pub -text -noout | head -2
# Public-Key: (256 bit)

Secondes sources pour l'empreinte

Ne prenez pas l'empreinte sur la même page que celle qui vous a servi la clé, si vous pouvez l'éviter. Recoupez-la avec au moins l'une de ces sources :

• Un enregistrement DNS, servi par une infrastructure différente de ce site web. La même empreinte est publiée dans un enregistrement TXT sur _cosign.cert-ix.com, et une seule commande suffit à le vérifier : dig +short TXT _cosign.cert-ix.com. C'est le recoupement qui vaut la peine d'être fait : un attaquant ayant pris le contrôle de ce serveur web devrait aussi prendre le contrôle de notre DNS pour que les deux concordent — deux systèmes distincts, avec des identifiants distincts. En cas de divergence, arrêtez-vous : n'exécutez pas les binaires et écrivez à [email protected].
• Votre contact Cert-IX, hors bande. Demandez à votre interlocuteur commercial ou sécurité de vous relire l'empreinte par un canal qui n'est pas ce site web — un appel téléphonique, un courriel signé depuis [email protected], ou votre canal de support existant.
• Une clé que vous possédez déjà. Si vous avez vérifié une version bits précédente, comparez avec la clé que vous avez conservée. Une clé de publication qui change sans annonce est une raison de s'arrêter et de poser la question, pas une raison de mettre votre copie à jour.

Une fois l'empreinte confirmée, conservez votre copie de la clé et réutilisez-la. La valeur d'une ancre de confiance vient du fait qu'elle ne change pas.

Étape 2 — vérifier d'abord le manifeste de sommes de contrôle

L'ordre compte. Vérifiez la signature portant sur SHA256SUMS avant de faire confiance à la moindre somme de contrôle qu'il contient — un fichier de sommes de contrôle non signé ne prouve rien, car quiconque peut remplacer un binaire peut tout aussi facilement remplacer une simple liste de sommes de contrôle.

cosign verify-blob --key cosign.pub --bundle SHA256SUMS.sig \
  --insecure-ignore-tlog=true SHA256SUMS

Sortie attendue :

WARNING: Skipping tlog verification is an insecure practice that lacks transparency and
auditability verification for the blob.
Verified OK

Cet avertissement est attendu — voici exactement ce qu'il signifie

Cert-IX est une plateforme européenne souveraine et n'exploite aucun journal de transparence Sigstore public. Les signatures reposent sur des clés. Sans --insecure-ignore-tlog=true, cosign v3 cherche une entrée de journal de transparence qui, intentionnellement, n'existe pas, et signale « no signatures found ».

Cette option n'affaiblit pas la vérification de la signature elle-même. Ce qu'elle signifie, en revanche, c'est que vous ne disposez d'aucun registre indépendant et en ajout seul attestant que cette signature a jamais existé — le recoupement d'empreinte de l'étape 1 fait donc le travail qu'un journal de transparence ferait sinon pour vous. Voilà le compromis, énoncé clairement.

Étape 3 — vérifier que chaque fichier correspond à sa somme de contrôle

sha256sum -c SHA256SUMS

Étape 4 — vérifier le binaire que vous êtes sur le point d'installer

cosign verify-blob --key cosign.pub --bundle bitcollector-linux-amd64.sig \
  --insecure-ignore-tlog=true bitcollector-linux-amd64

Étape 5 — vérifier que le SBOM décrit bien ces octets

cosign verify-blob-attestation --key cosign.pub --bundle bitcollector-linux-amd64.att \
  --type cyclonedx --insecure-ignore-tlog=true bitcollector-linux-amd64

Le SBOM est ce qui vous permet de savoir ce que contient le collecteur qui produira vos preuves. Un binaire dont l'attestation ne correspond pas à ses octets est un binaire dont vous ne pouvez pas énumérer le contenu.

Le tout en une seule commande

Cert-IX livre le script de vérification qu'il exécute lui-même contre ses propres versions avant publication, à l'emplacement ci/verify-release.sh du dépôt :

./verify-release.sh "$PWD/bitcollector-release" "$PWD/cosign.pub"

[verify-release] verifying the signature over SHA256SUMS
[verify-release]   SHA256SUMS signature OK
[verify-release] verifying checksums of every artefact
[verify-release]   all checksums OK
[verify-release]   bitcollector-darwin-amd64 signature OK
[verify-release]   bitcollector-darwin-amd64 SBOM attestation OK
[verify-release]   bitcollector-darwin-arm64 signature OK
[verify-release]   bitcollector-darwin-arm64 SBOM attestation OK
[verify-release]   bitcollector-linux-amd64 signature OK
[verify-release]   bitcollector-linux-amd64 SBOM attestation OK
[verify-release]   bitcollector-linux-arm64 signature OK
[verify-release]   bitcollector-linux-arm64 SBOM attestation OK
[verify-release]   bitcollector-windows-amd64.exe signature OK
[verify-release]   bitcollector-windows-amd64.exe SBOM attestation OK
[verify-release] VERIFIED: 5 binary/binaries, checksums, and signatures all valid
[verify-release] built from commit 8819759 with go1.25.12
OK: 5 verified

Un code de sortie 0 et une ligne indiquant OK: <n> verified signifient que chaque binaire est authentique et intact. Tout autre résultat signifie ne pas installer.

Passez des chemins absolus

Le script se place dans le répertoire de la version publiée avant de commencer son travail : un chemin relatif vers la clé publique cesse donc de se résoudre et toutes les vérifications de signature échouent avec :

[verify-release] REFUSED: the signature over SHA256SUMS is NOT valid for this key.

Ce refus se lit exactement comme une version altérée. Si vous le voyez, relancez avec des chemins absolus ("$PWD/cosign.pub") avant de conclure quoi que ce soit — et si cela échoue encore avec un chemin absolu, traitez-le comme réel et contactez [email protected].

Deux détails méritent votre attention, car ce sont eux qui font la différence entre une vérification et un rituel :

• Il rapporte un décompte. Une vérification qui ne trouve rien à vérifier ne doit pas signaler un succès : le script refuse donc lorsque le répertoire ne contient aucun binaire, et il affiche combien il en a réellement vérifié.
• Il refuse en cas de signature manquante. Un binaire non signé posé dans une version signée, c'est exactement à quoi ressemble une attaque sur la chaîne d'approvisionnement : le script échoue donc au lieu de l'ignorer.

Ce que la signature prouve aujourd'hui

Soyez précis sur ce point, car « signé » est souvent entendu comme plus qu'il ne l'est.

Ce qu'elle prouve : ces octets exacts ont été produits par la chaîne de publication Cert-IX et signés par le détenteur de la clé dont vous avez vérifié l'empreinte à l'étape 1, et ils n'ont pas changé depuis. Combinée à SHA256SUMS et à l'attestation du SBOM, elle vous permet d'énumérer ce que contient le binaire et d'avoir la certitude que cette énumération correspond aux octets.

Ce qu'elle ne prouve pas, dit honnêtement :

• La clé de signature réside actuellement sur l'hôte de compilation, protégée sous forme de fichier avec une phrase secrète conservée hors du contrôle de source. Elle n'est pas dans un module matériel de sécurité (HSM). La signature prouve donc « c'est le binaire produit par cette compilation » — elle ne prouve pas que l'hôte de compilation lui-même n'était pas compromis au moment de la signature.
• Il n'existe aucun journal de transparence. Vous ne pouvez pas consulter un registre indépendant et en ajout seul pour voir si une signature portant sur un autre binaire a jamais été émise sous cette clé.

Ces deux points sont précisément la raison pour laquelle la compilation reproductible ci-dessous compte, et pour laquelle le recoupement d'empreinte de l'étape 1 n'est pas facultatif.

Recompiler le binaire vous-même

Vous n'êtes pas obligé de nous croire sur parole quant au contenu du binaire — vous pouvez le recompiler et comparer. Les versions bits sont reproductibles : le même commit, compilé avec la même chaîne d'outils Go, produit une sortie identique au bit près.

Partez de release-provenance.json, qui consigne exactement à partir de quoi la version a été compilée :

{
  "service": "bitcollector",
  "version": "0.1.0-ga",
  "commit": "8819759",
  "go_toolchain": "go1.25.12",
  "source_date_epoch": 1786277293,
  "build_time": "2026-08-09T12:08:13Z",
  "platforms": ["linux/amd64", "linux/arm64", "darwin/amd64", "darwin/arm64", "windows/amd64"],
  "reproducible": true,
  "signed": true
}

Avec les sources et la chaîne d'outils qui y sont nommées :

git checkout <commit from release-provenance.json>

SOURCE_DATE_EPOCH=<source_date_epoch from release-provenance.json>
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath \
  -ldflags="-s -w -buildid= \
    -X main.version=<version> \
    -X main.buildTime=$(date -u -d @$SOURCE_DATE_EPOCH +%Y-%m-%dT%H:%M:%SZ) \
    -X main.gitCommit=<commit>" \
  -o bitcollector-linux-amd64 ./cmd/bitcollector

sha256sum bitcollector-linux-amd64   # must equal the value in SHA256SUMS

Une empreinte identique signifie que le binaire publié ne contient rien qui ne soit dans les sources que vous venez de lire.

Versions actuelles

Les quatre bits sont publiés, et les quatre sont signés avec la même clé — celle dont vous avez vérifié l'empreinte à l'étape 1. Une seule vérification de clé couvre la famille.

Produit	Version	Commit	Chaîne d'outils	Plateformes
bitcollector	0.1.0-ga	8819759	go1.25.12	linux amd64/arm64, macOS amd64/arm64, Windows amd64
bitscanner	0.1.3-ga	7db3d4c	go1.25.12	linux amd64/arm64
bitenforcer	0.1.0-ga	4c6ce93	go1.25.12	linux amd64/arm64
bitmapper	0.1.0-ga	64ebc64	go1.25.12	linux amd64

Les colonnes « plateformes » ne sont pas identiques, et les différences sont délibérées. Lorsqu'une plateforme manque, c'est parce que l'agent n'y ferait pas son travail, non parce que la compilation a été oubliée. Chaque page produit en donne la raison :

Produit	Ce qui est retenu, et pourquoi
bitcollector	Rien. Il est publié sur les cinq — plateformes
bitscanner	Pas de macOS/Windows : ses lecteurs de voisinage et de routes sont des implémentations Linux, et une table de voisins vide se lirait comme un segment calme — plateformes
bitenforcer	Pas de macOS/Windows : toute sa surface est iptables/sysctl/systemd/SELinux, donc une compilation là-bas rapporterait chaque module en NOT EXAMINED — plateformes
bitmapper	linux amd64 uniquement : la capture exige une libpcap liée à la compilation, donc elle ne peut pas être compilée de manière croisée. Windows compile mais n'y a jamais été exécuté, il est donc retenu comme lacune de test — plateformes

Vérifiez la version que vous avez réellement téléchargée

Les commits ci-dessus sont ceux à partir desquels les versions actuelles ont été compilées. release-provenance.json, dans votre répertoire de version, fait foi pour ce répertoire — comparez-le au tableau plutôt que de supposer, et le binaire lui-même affiche les mêmes valeurs depuis les octets que vous allez exécuter. Si les trois divergent, arrêtez-vous et écrivez à [email protected].

La commande n'est pas la même sur les quatre binaires. Utilisez celle du binaire que vous avez :

Binaire	Commande qui affiche sa version
bitcollector	bitcollector --version
bitscanner	bitscanner version
bitenforcer	bitenforcer version
bitmapper	bitmapper version

Utilisez exactement ces orthographes : la mauvaise ne se contente pas d'afficher une erreur.

• Sur bitcollector jusqu'à la version 0.1.0-ga incluse, bitcollector version n'est pas une commande de version. L'argument est ignoré et le binaire DÉMARRE L'AGENT : il crée sa clé d'identité dans le répertoire de données et commence à collecter. Si vous l'avez lancée, arrêtez le processus et supprimez le répertoire de données (/var/lib/bitcollector sauf modification) avant d'enrôler réellement l'hôte. bitcollector --version affiche puis quitte, et l'a toujours fait.
• Sur bitscanner, bitenforcer et bitmapper, --version n'existe pas : la commande échoue avec unknown flag: --version. Celle-là est sans danger, seulement inutile.

Les binaires et leur clé de signature sont sur la page de téléchargement. Les étapes ci-dessus fonctionnent hors ligne sur n'importe quel répertoire de version en votre possession : vous pouvez donc vérifier sur une machine qui ne touche jamais notre site web.

Étapes suivantes

• bitcollector — ce qu'il collecte, et comment sa chaîne de preuves est vérifiée (une autre clé, et une vérification distincte).
• bitenforcer — ce que la v1 fait et ne fait pas.
• Vue d'ensemble de bits — commencez ici si vous êtes arrivé d'abord sur cette page.