Software teams need more than vulnerability scanners to decide whether a release is trustworthy. A strong supply-chain baseline connects each production artifact to its source commit, build process, dependencies, and release record. Software bills of materials (SBOMs), signed provenance, immutable releases, and verification policies provide that connection.
Start with artifact identity
Every release should have a stable identity that does not depend on a mutable label such as latest or production. Use a cryptographic digest for container images, packages, binaries, and deployment manifests. A digest identifies the exact bytes that were tested and approved.
This matters during incident response. If someone moves a tag after approval, an administrator may believe the same software is running even though the underlying artifact has changed. Pinning deployments to digests also makes audit records more precise because they identify the exact artifact rather than only its name and version.
Publish an SBOM with releases
An SBOM is a structured inventory of the software components inside a product. It can include package names, versions, licenses, suppliers, and security references. The SPDX project describes its specification as an international open standard, ISO/IEC 5962:2021, for representing software supply-chain information.
Generate the SBOM from the built artifact, not only from a developer workstation or a lockfile. The built artifact may contain operating-system packages, compiled libraries, generated code, or dependencies added during image creation. Store the SBOM beside the release and associate it with the artifact digest.
Teams should also define what makes an SBOM usable. At minimum, it should identify the artifact, include component versions, use a supported format such as SPDX or CycloneDX, and remain available long enough to investigate vulnerabilities in older releases. An SBOM is an inventory, not proof that the software is safe.
Sign build provenance
Provenance records explain where and how an artifact was produced. The SLSA 1.2 specification describes provenance as verifiable information about an artifact’s source, build process, and other inputs. Useful fields include the source repository, commit, builder identity, workflow, build parameters, dependencies, and output digest.
For GitHub Actions users, artifact attestations create cryptographically signed claims about build provenance and can include an SBOM. GitHub says its attestations record information such as the repository, organization, environment, commit SHA, and triggering event. GitHub also notes that attestations do not guarantee an artifact is secure. Instead, they connect the artifact to the source and build instructions so a consumer can apply its own policy.
permissions:
contents: read
id-token: write
attestations: write
steps:
- name: Generate artifact attestation
uses: actions/attest@v4
with:
subject-path: path/to/releaseGitHub’s documentation shows the actions/attest@v4 action for generating provenance for a binary. For container images, the workflow uses a fully qualified image name, a SHA-256 digest, and the push-to-registry: true option when the attestation should be published with the image. The exact workflow should match the organization’s platform and release process.
Verify before deployment
Signing is useful only when another system verifies the signature and evaluates the claims. GitHub’s supply-chain guidance recommends verifying attestations for dependencies and describes using deployment controls, such as a Kubernetes admission controller, to block unattested builds.
Begin with an audit-only policy. This lets the team measure how many releases lack provenance, use mutable tags, or come from unapproved builders. Then enforce a small set of rules for production: the artifact must have a valid signature, the signer must be an approved build identity, the source repository must be allowed, and the commit must meet the organization’s review policy. Keep exceptions time-limited and record an owner, reason, and expiration date.
Protect the release record as well as the build. GitHub’s immutable releases prevent published release assets and associated tags from being changed after publication. The feature also creates a release attestation containing the release tag, commit SHA, and release assets.
The goal is not to create paperwork for every test build. Sign software that people will run or deploy, retain its SBOM and provenance, and make verification part of the release path. This gives administrators a reliable answer to three operational questions: what is running, where did it come from, and can the organization prove that it has not changed?
References
GitHub. (n.d.). Artifact attestations. GitHub Docs. https://docs.github.com/en/actions/concepts/security/artifact-attestations
GitHub. (n.d.). Using artifact attestations to establish provenance for builds. GitHub Docs. https://docs.github.com/en/actions/how-tos/secure-your-work/use-artifact-attestations/use-artifact-attestations
GitHub. (n.d.). Immutable releases. GitHub Docs. https://docs.github.com/en/code-security/concepts/supply-chain-security/immutable-releases
GitHub. (n.d.). Supply chain security. GitHub Docs. https://docs.github.com/en/code-security/concepts/supply-chain-security/supply-chain-security
SPDX Project. (n.d.). Specifications. https://spdx.dev/use/specifications/
SLSA. (n.d.). SLSA specification, version 1.2. https://slsa.dev/spec/v1.2/