A build artifact is not just something to deploy.
It is evidence.
When a production issue, security review, or customer audit asks what shipped, the artifact should answer clearly. Which commit produced it? Which dependencies were included? Which tests passed? Who approved it? Was it signed? Where was it deployed?
The artifact should carry the story of its own creation.
Provenance Matters
Artifact provenance connects source code to runtime.
Useful provenance includes commit SHA, repository, branch or tag, build system, build time, dependency lockfile, compiler or runtime version, test results, scan results, and signer identity. Without that chain, teams rely on logs and memory.
Supply chain confidence needs evidence that survives the release.
Sign What You Ship
Signatures help verify that an artifact came from the expected pipeline and was not altered.
Signing is not a complete security program, but it creates a stronger boundary between trusted and unknown output. Deployment systems can reject unsigned or incorrectly signed artifacts before they reach production.
The build pipeline becomes part of the trust model.
Store The Metadata
Evidence should be queryable.
Teams should be able to ask which deployments included a vulnerable dependency, which artifact ran in a region, which release changed a service, or which build introduced a regression. That requires structured metadata, not only filenames.
Observability should include artifact identity.
Make Audits Routine
Supply chain evidence is most useful when it is produced automatically.
Do not wait for an incident to gather it. Make the pipeline emit the record every time. Then audits become confirmation, not archaeology.
The artifact is the receipt for the change. Keep it complete.