Attestation, SBOM, and supply chain: what to verify before installing

The software you install is the supply chain you inherit. Most developers verify a download the way they verify a stranger’s claim: they trust the source and move on. For a credential broker — a tool that reads your password store and hands secrets to subprocesses — that habit is the vulnerability. A tampered binary does not need a zero-day; it just needs to be what you ran. Attestation and SBOMs exist to make installation verifiable instead of trusting.

What attestation actually proves

Signature attestation answers one question: did the artifact come from the project that claims to publish it? Cosign keyless signing does this without a long-lived private key — the publisher’s identity is bound through OIDC at build time, and the signature is stored alongside the release. Running cosign verify confirms the binary was signed by the expected identity. That is a meaningful statement: it rules out a lookalike release, a compromised mirror, or a file swapped in transit. It is not a statement about code quality. Attestation proves provenance, not virtue.

What an SBOM gives you

An SBOM is an inventory: every component inside the artifact, with versions. For a compiled Go binary, that means the modules that went in. The inventory is what makes vulnerability scanning possible — you can only match a CVE against components you know are present. It also tells you something about the size of the attack surface. A binary with one external module has a smaller surface to review than one with dozens of transitive dependencies, and a static binary with no runtime dependencies removes an entire class of installation issues.

What to check before installing

A practical pre-install checklist for a security CLI:

• Checksum. Verify the downloaded file matches the published digest. Cheap, and it catches truncation and mirror tampering.
• Signature. Run cosign verify against the release. This is the attestation step; skip it only if you are willing to trust a file you cannot authenticate.
• SBOM. Confirm one exists and read it. The contents should match the project’s stated dependency story, not surprise you.
• Version traceability. The version should be injected at build time, so the running binary can be matched to a tag and a release. A binary that cannot tell you its version cannot be audited.
• Test evidence. Published test results — for example, a stated test count run with the race detector — are weak evidence, but not nothing; they indicate the project treats correctness as a gate.

The special case of a credential broker

Supply-chain rigor is not equally important for every tool. A linter with a compromised release is an annoyance. A credential broker with a compromised release is a keylogger with a nicer name — it reads your existing pass store or Bitwarden session and injects secrets into the processes it spawns. The blast radius is your entire credential set. That is why these verification steps are not bureaucracy for a tool in this category; they are the difference between using a broker and being used by one.

A short checklist for your next install

Verify the checksum, verify the signature, read the SBOM, and confirm the version is traceable to a release. Ten minutes of checks beats explaining a compromise.

trustless is a zero-dependency Go CLI shipped as a single static binary with one external module (go-toml/v2), tested with 321 tests under -race, with Cosign keyless-signed releases and an SBOM, and the version injected at build time via ldflags — so every check above is possible and expected.

What did you verify the last time you installed a CLI that could read your secrets — and would you know if the binary changed between release and run?