SBOM & attestations
These are the compliance artifacts attached to versions. Two policy
rules build on them: sbom and attestations (see the
Policy rules reference).
Haven generates a CycloneDX SBOM for published versions from the crate’s metadata and dependencies, and you can upload your own SBOM per version if your build pipeline produces a richer one.
Each version’s SBOM can be downloaded through the API and viewed from the crate page. Auditors and downstream consumers get it from the same URL scheme as the crate itself, under the same access rules:
GET /ns/acme/api/v1/crates/my-crate/1.2.3/sbomLicense report
Section titled “License report”Per version, Haven reports the declared license expression and how it
evaluates against the namespace’s SPDX allowlist, so you can see why
the license rule passed or held before touching policy.
Attestations
Section titled “Attestations”An attestation is an identity’s signed statement about a version (“this passed our review”, “this was built by our CI”). Two ways to attach one:
- Token-based: any entitled identity attests through the API with its token.
- Keyless (OIDC): CI systems attest with their workload identity (for example a CI job’s OIDC token), no long-lived secret involved. Available when the instance has OIDC issuers configured.
The attestations policy rule counts attestations from distinct
identities, so one bot attesting three times does not satisfy a
threshold of two.
Verifying downstream
Section titled “Verifying downstream”The haven-verify companion tool runs on the consumer side, in CI. It
reads a Cargo.lock, finds the packages pinned to your Haven
registry, and fails the build if a package’s checksum diverges from
the registry index or its attestations no longer verify:
haven-verify --lockfile Cargo.lock \ --registry https://haven.example.com --token $HAVEN_TOKEN