AI
Why Build Artifacts Need Signatures
A compiled artifact, whether a Java jar, a Python wheel, or a container image, can be several gigabytes. A single changed byte is undetectable by eye. Signatures fix that: a private key signs the build, producing a few hundred bytes. If any byte in the artifact changes, the signature fails to verify.
Attackers already know this. Source repositories are harder targets now that pull requests and MFA are standard. So they moved downstream, targeting build instructions, post-build artifact storage, PyPI uploads, and container registries. Signing covers that window, from build completion until the artifact runs in production.
Why Traditional Signing Never Got Adopted
Software signing has existed for decades. It never got widely adopted because running it is expensive.
Before Artifact Attestations, signing started with a key generation decision: which algorithm, which parameters. Then came the operational burden. The private key had to stay locked down. The public key had to be distributed widely. When anyone with private key access joined or left the organization, you rotated everything and redistributed. As Steindler put it:
“Operationally, this is a giant pain”
Signing and Verifying Builds with Artifact Attestations
Artifact Attestations cuts the key management problem entirely. GitHub issues a short-lived identity at build time. Adding two permissions (id-token: write and attestations: write) plus one action step to an existing workflow is the entire signing change, as shown in the container image signing demo (05:01).
Verification is one command: gh attestation verify. The critical flag is --owner, which locks the attestation to your GitHub organization. Steindler warns that skipping it is dangerous:
“The presence of an attestation does not mean that the workload is secure.”
For stricter enforcement, the OPA policy verification demo (08:39) shows piping the verification JSON to opa eval with a Rego policy that defaults fail-closed and checks specific provenance fields.
Scaling Attestation Policy Across an Organization
Once attestations are in place, a central build team can raise the bar org-wide. GitHub’s reusable workflows let security-approved build logic live in one repository. Application teams replace their job steps with a single uses: pointer. Build provenance records which reusable workflow ran, down to the exact commit. Policy can enforce that, blocking anything not built through the vetted workflow before it reaches production.
Start by signing a few builds, then add policy in audit mode. Use the log as a burndown list. Block deploys only after coverage is solid.
Notable Quotes
The presence of an attestation does not mean that the workload is secure. Zach Steindler · ▶ 6:28
Operationally, this is a giant pain Zach Steindler · ▶ 4:38
Don’t feel like you have to, you know, melt the whole iceberg at once. Zach Steindler · ▶ 13:02
Key Takeaways
- Attackers now target build pipelines and registries, not just source code, so signing must cover the artifact after it leaves CI.
- Artifact Attestations replaces long-lived key management with a one-step GitHub Actions addition and a single CLI flag to verify.
- Start by signing a few builds and logging policy violations before blocking deploys, then expand incrementally across repositories.