Signing the artifact does not prove who approved the deployment

An auditor asks who authorised the production release. The team offers a container signature. It proves the image is genuine and says nothing at all about the question being asked.

Part of Software supply chain authorization

Two different questions

The top two rows are well served by mature tooling and represent genuine progress against a real class of attack. The bottom two are simply outside scope.

What keyless signing identifies

Sigstore's keyless signing binds an ephemeral certificate to an OIDC identity presented by the build system. In practice that identity is the workflow — a repository, a reference, a job path.

# Roughly what a keyless signature identifies
subject:  https://github.com/org/repo/.github/workflows/release.yml@refs/tags/v2.4.0
issuer:   https://token.actions.githubusercontent.com

# This is an automation identity.
# It tells you which workflow ran.
# It does not tell you which human wanted it to.

That is the correct design. Tying artifact signatures to individual developers would be operationally miserable and would not improve provenance. The identity being an automation identity is a feature, not an oversight.

It does mean that if the workflow can be triggered by anything — a tag push, a scheduled job, an agent — the signature attests to the workflow having run, and nothing more.

Where the gap becomes concrete

Three situations where provenance verifies perfectly and the release was still wrong.

1. Unintended promotion. A correctly built artifact is deployed to production by a misconfigured pipeline. Provenance is intact; nobody chose to ship it.
2. Compromised trigger. An attacker with the ability to push a tag causes a release of genuine source that includes their earlier merged change. Every signature verifies.
3. Wrong environment. An artifact intended for staging reaches production. The artifact is exactly what it claims to be, in the wrong place.

In all three, an audit of the supply chain finds nothing wrong, because nothing in the supply chain was wrong.

What a release signature covers

# Sits beside the artifact signature, answers the other question
{
  "action":      "deploy",
  "artifact":    "sha256:9c1f...a83e",       # the signed image
  "repository":  "platform/payments",
  "ref":         "refs/tags/v2.4.0",
  "commit":      "7f3a91c8e2b7d4056891fa2c73e1b9d40",
  "environment": "production",
  "approver":    "[email protected]",
  "at":          "2026-05-21T16:02:11Z"
}

# Deploy gate requires BOTH:
#   artifact signature verifies  → provenance
#   release signature verifies   → authority

Note that the release statement references the artifact digest. That binding is what prevents an approval for one build being reused for another.

Comparing honestly

The last row is the point. These are not competing designs and choosing between them is a category error.

When you only need one

Plenty of deployments do not need a human release decision. Continuous deployment of low-risk services to production on every merge is a legitimate, well-understood model, and adding an approval prompt to it destroys its value.

Reserve the release signature for environments where someone will eventually be asked who authorised a change: regulated systems, payment paths, anything in audit scope. Elsewhere, provenance alone is the right answer.

Three releases where provenance verified and the deploy was still wrong

Each of these passes a Sigstore verification cleanly, because nothing about the artifact was wrong.

The 2025 npm worm is the clearest illustration at ecosystem scale: a phished credential published hundreds of packages, and every one of them had a legitimate publishing path behind it. Provenance proves the pipeline, and the worm had a pipeline. Our colleague's piece on Sigstore and the missing person works through that incident.

Objections and honest limits

“Keyless signing should identify the developer.” It should not. Tying artifact signatures to individuals would be operationally miserable, would break automated releases, and would not improve provenance. The automation identity is the correct design.

“We do continuous deployment, so a release approval is friction we chose to remove.” Then provenance alone is the right answer and this does not apply to you. Reserve release signatures for environments where somebody will eventually be asked who authorised a change.

What a release signature does not do: establish that the artifact is what it claims to be. That is exactly what Sigstore does, which is why the two belong side by side rather than in competition.

Adding a release signature beside provenance

1. Keep artifact signing exactly as it is. Provenance is solved. Do not couple the two mechanisms.
2. Identify releases that need a decision. Regulated systems, payment paths, anything in audit scope. Low-risk continuous deployment does not qualify.
3. Reference the artifact digest in the release statement. So an approval for one build cannot be replayed for another.
4. Verify both at the deploy gate. Artifact signature for provenance, release signature for authority. Fail closed on either.

Terms used here

Keyless signing

Signing with an ephemeral certificate issued against an OIDC identity, with the record kept in a transparency log. No long-lived key to steal, and the identity is a workflow.

Provenance

A verifiable statement about how an artifact was produced: which source, which builder, which parameters. It says nothing about whether anyone wanted it deployed.

Release decision

The human act of choosing to put a specific artifact into a specific environment. Distinct from building it, and currently unrecorded almost everywhere.

Frequently asked questions

Is artifact signing insufficient? It is sufficient for what it does — establishing provenance. It does not address who authorised a deployment, which is a separate question.

Why does keyless signing identify a workflow rather than a person? Because the signing identity comes from the build system's OIDC token. Tying it to individuals would be operationally painful and would not improve provenance.

Do we need both? In regulated or audit-scope environments, yes. For continuous deployment of low-risk services, provenance alone is appropriate and an approval prompt would be counterproductive.

Why reference the artifact digest in the release statement? So an approval for one build cannot be reused for another. Without that binding, the approval floats free of what actually deployed.

What does a Sigstore signature identify? The workflow that produced the artifact — typically a repository, reference and job path presented as an OIDC identity. It is an automation identity by design.

Do we need both signatures? In regulated or audit-scope environments, yes. For continuous deployment of low-risk services, provenance alone is appropriate and adding approval friction would be counterproductive.

Why reference the artifact digest in the approval? Without it the approval floats free of what actually deployed, and one release's approval could be reused for another build.

Sources and further reading

• Sigstore documentation
• SLSA v1.0 specification
• in-toto attestation framework
• AICPA Trust Services Criteria (SOC 2)