Published artifacts carry build provenance
Provenance links the published artifact back to the commit and workflow that built it, so a consumer can tell a legitimate release from one uploaded by whoever held the token.
Observable check
the exact published artifact has verifiable provenance tied to the expected repository and workflow. Prefer a registry-served record: verify npm provenance for an installed exact package version, PyPI provenance through its Integrity API, or a RubyGems attestation through its attestation API. Where a registry cannot serve provenance, verify a forge attestation for the exact published artifact and report the registry limitation; OIDC authentication alone is not provenance.
Where this comes from
- https://docs.npmjs.com/generating-provenance-statements
- https://docs.npmjs.com/trusted-publishers/
- https://docs.pypi.org/api/integrity/
- https://guides.rubygems.org/trusted-publishing/
- https://hex.pm/docs/publish
Last read against these sources on 2026-07-28.
npm confirms what provenance attests to, that npm audit signatures verifies it, and that trusted publishing generates it automatically for public packages. PyPI's Integrity API is the verification endpoint: GET /integrity/<project>/<version>/<filename>/provenance, returning attestation bundles with signatures, certificates, transparency log entries, and publisher identity, 404 when a file has no provenance. RubyGems, crates.io, and Hex are all checked negatives: their publishing documentation covers authentication only and documents no attestation or provenance for the published artifact, so on those three registries this rule falls back to a forge attestation and the registry limitation the Check already tells an auditor to report. Hex is the weakest of the three, because it serves no provenance and offers no OIDC either, leaving the forge attestation as the only link between a published tarball and the workflow that built it. Its page was read on 2026-07-31; the other sources were last read on the verified date.