How Supply Chain Signing Actually Works

Software supply chain signing gets described far too loosely. People say an image is signed, a package is trusted, a build is verified, or a release is provenance-backed, as if those were all one thing. They are not. They are separate claims about different parts of the path from source tree to running artefact.

At the bottom, signing is straightforward. Take an exact blob of bytes, hash it, sign the hash, and let someone else verify the signature with a public key. The complexity appears one layer up. Which bytes did you sign? Who was allowed to sign them? Where did the verifier get the public key or certificate? Can an attacker sign from a forked repository or a different workflow? Can they reuse a valid signature on a different tag? Can they keep a signing event invisible by never publishing it anywhere observers can audit later? Can the deployment gate tell the difference between "signed by somebody" and "signed by the build identity this service trusts for this repository on this branch"?

That is why supply chain signing is a trust-chain problem rather than a crypto-checkbox problem. The signature primitive matters, but the operational value comes from the whole chain around it: immutable artefact digests, signer identity, certificate or key distribution, transparency logs, provenance attestations, and a verification policy that names what is acceptable.

This article walks that chain end to end. We will start with the exact thing a signature covers, then move into signer identity, keyless CI signing, transparency logs, provenance claims, verification policy, and the failure modes that still remain when everything looks green in a dashboard. The examples use OCI images and modern CI systems because that is where these ideas are easiest to see, but the same mechanics apply to binaries, packages, firmware, and release archives.

The first job is to name the exact artefact, not the release label

Before signing means anything, the system needs a stable name for the exact bytes under discussion. Human release labels are not stable enough.

payments-api:prod is a label. v2.4.1 is a label. latest is a label pretending to be a coordinate. None of them identify one immutable artefact. They identify whatever some registry, package host, or release process currently maps that label to.

A signature that says "I signed latest" is almost useless. The verifier needs to know the exact content the signer saw. That is what the digest is for.

For a container image, the useful identifier is the content digest:

registry.example.eu/platform/payments-api@sha256:4c4dc1a8898f2d8a1e7b5037a84bf0f0d9f0e8a4ddf0d0d0ec1f3f52d0af6c7b

That digest is derived from bytes, not from intention. If any byte changes, the digest changes. If the digest is the same, the content is the same.

This is the first place teams lose the plot. They think signing protects a tag. It does not. Signing protects a digest.

A good verification pipeline therefore starts with content addressing:

1. resolve the label to a digest
2. treat the digest as the artefact identity from that point on
3. verify signatures, attestations, and policy against that digest
4. deploy by digest, not by tag

If step 4 does not happen, a mutable label can quietly undo the rest.

Imagine a registry where payments-api:stable pointed to digest A when the CI job signed it. Later somebody with registry write access retags payments-api:stable to digest B. The old signature over A still exists and still verifies perfectly. It just no longer proves anything useful about what :stable means now.

That is not a cryptographic failure. It is a naming failure.

A short table helps separate the common claims:

That table is the real shape of supply chain signing. It is a stack of answers, not one answer.

A digital signature only says that one identity vouched for one digest

Once the artefact has a stable digest, the cryptographic part begins.

The signing side computes a digest of the artefact bytes, then uses a private key to produce a signature. The verifying side uses the corresponding public key to check that the signature matches the digest.

Conceptually:

artefact bytes -> hash -> digest
private key + digest -> signature
public key + digest + signature -> valid or invalid

The important thing here is what the verifier actually learns.

A valid signature says:

• this signature was produced by the holder of the corresponding private key
• the signature covers this exact digest
• if the digest was computed from these bytes, those bytes were the thing signed

A valid signature does not say:

• the artefact is safe
• the source repository was trustworthy
• the build ran in the expected CI workflow
• the build dependency graph was clean
• the signer was authorised by your organisation
• the artefact you are about to deploy came from the expected tag

That gap between cryptographic validity and operational trust is where most confusion lives.

It helps to contrast software signing with TLS certificate validation. In TLS, once the browser verifies the certificate chain and hostname, it has a direct operational decision to make: continue or reject the connection. In supply chain signing, a raw signature check is too weak to drive the operational decision on its own. The deployment gate needs stronger context.

Consider two equally valid signatures over the same digest:

1. one was produced by the release workflow in your GitHub repository on the protected main branch
2. one was produced by a developer's laptop with a personal export of an old signing key

Cryptographically they can look identical: valid signature, expected public key, expected digest.

Operationally they are not identical at all. One came from the controlled release path. One bypassed it.

That is why serious signing systems wrap the signature with more structure than "here is a detached signature blob". The verifier needs enough metadata to answer:

• which signing identity produced this
• under which issuer or PKI
• in which repository or project
• from which branch, tag, or workflow
• at what time
• with what build claims attached
• with what log evidence attached

In other words, the signature primitive solves authenticity of bytes. The surrounding system solves authenticity of process.

Long-lived signing keys were the old answer, and they created their own supply chain risk

Historically, software signing often meant maintaining a long-lived private key somewhere in a release environment. That key might sign Debian repository metadata, RPM packages, Windows binaries, mobile application bundles, or container artefacts. The trust model was simple:

• keep the private key secret
• distribute the public key or certificate to verifiers
• accept artefacts whose signatures validate under that key

That model still exists everywhere, and for some ecosystems it remains necessary. It also has obvious operational problems.

The key becomes a crown jewel

A long-lived signing key is not just another credential. It is a machine that can mint trust. If an attacker steals it, they do not need to compromise your source tree or build runner every time. They can sign arbitrary malicious releases until the key is revoked or rotated.

Revocation is often slow and messy

If a signing key leaks, every verifier that trusts it needs updated revocation or replacement data. That update path is not always fast. Air-gapped systems, embedded devices, cached repository metadata, and pinned trust bundles can all lag.

Human-operated signing ceremonies do not scale cleanly

Teams respond by pushing the key into an HSM, an offline ceremony, or a release-management enclave. That helps key custody, but it can also create brittle handoffs. If the signing step becomes a manual afterthought, engineers start inventing exceptions.

Shared organisational keys flatten identity

One key per company or per product line tells the verifier very little about which workflow actually produced the artefact. Every valid signature collapses into the same statement: someone with access to the organisational key signed this. That is useful, but not sufficient for modern CI-heavy environments.

This problem is what modern keyless signing systems are trying to fix. The goal is not to remove signatures. The goal is to remove the need for every CI pipeline to carry a durable signing secret that lives longer than the build itself.

Keyless signing turns CI identity into a short-lived certificate, then signs with an ephemeral key

A common modern pattern, used in systems such as Sigstore, treats workload identity rather than key custody as the primary trust source.

The rough flow looks like this:

1. a CI job proves its identity to an OIDC issuer
2. the signing system verifies that identity token
3. the signing system issues a very short-lived certificate binding that CI identity to an ephemeral public key
4. the CI job signs the artefact digest with the matching ephemeral private key
5. the signature, certificate, and log evidence are stored together for later verification

That sounds more complicated than a plain static key, but it changes the risk shape in useful ways.

The private signing key can be short-lived

The build can generate an ephemeral key pair for one signing event. If that private key leaks later, it does not keep minting trust forever.

The certificate can carry workload identity claims

Instead of saying only "key X signed this", the certificate can say something closer to:

• repository: eu-example/payments-api
• workflow: .github/workflows/release.yml
• ref: refs/heads/main
• issuer: https://token.actions.githubusercontent.com
• validity: a few minutes

Now the verifier has a richer statement. It can check not just that the signature is mathematically valid, but that the signer identity belongs to the workflow it expected.

The trust anchor moves to identity issuer plus policy

With a long-lived static key, the trust anchor is usually the distributed public key or certificate chain. With keyless systems, the trust decision often becomes:

• do I trust this certificate issuer
• do I trust this log
• do I trust signatures from this repository and workflow subject
• do I trust this provenance predicate

That is closer to how modern organisations actually reason about build trust.

A simplified certificate view might look like this:

Subject: https://github.com/eu-example/payments-api/.github/workflows/release.yml@refs/heads/main
Issuer:  https://token.actions.githubusercontent.com
SAN:     URI:https://github.com/eu-example/payments-api/.github/workflows/release.yml@refs/heads/main
NotBefore: 2026-06-21T09:13:01Z
NotAfter:  2026-06-21T09:23:01Z
PublicKey: ephemeral ECDSA key for this signing event

If the verifier later sees a signature with a valid certificate from refs/pull/184/merge instead of refs/heads/main, that should usually fail policy even though the crypto is fine.

That distinction matters a lot in public-forge CI.

An attacker who can run code in a forked pull request, a non-release workflow, or a misconfigured self-hosted runner may be able to obtain some workload identity. The whole point of verification policy is to require the right workload identity.

This is why keyless signing is not "trust any ephemeral cert from GitHub Actions". That would be absurd. It is "trust certificates from this issuer only when the embedded subject, repository, workflow, branch, and sometimes event type match my policy".

Transparency logs make signing events auditable instead of private facts

If the story ended with "CI got a certificate and signed the digest", an important problem would remain: invisible signing.

Suppose an attacker gains temporary signing ability. They may produce a malicious artefact, sign it, and distribute it only to a narrow victim set. If the signing event leaves no public trace, defenders have a hard time answering basic questions later:

• how many artefacts were signed during the compromise window
• which certificate identities were used
• were there signatures over unexpected digests or branches
• did a suspicious certificate ever exist at all

Transparency logs address that by making signing events append-only and auditable.

The basic idea is borrowed from Certificate Transparency in the web PKI world. Instead of trusting that every legitimate signing event will be noticed by the right people privately, the system records events in a log whose consistency can be checked later.

A transparency log entry for software signing generally includes some combination of:

• artefact digest
• signature
• signing certificate or public key material
• integrated timestamp
• inclusion proof or receipt
• log index and tree information

The value is not that the log magically makes a bad signature good. The value is that it becomes harder to keep a signing event secret.

That changes incident response.

Without transparency, a defender may need to recover scattered CI logs, HSM audit trails, cloud logs, and release notes to estimate what was signed.

With transparency, the defender can also ask:

• show me every entry for this repository identity during the incident window
• show me every entry for this digest
• show me every certificate subject that signed under this issuer last night
• prove the log has not hidden or rewritten entries by checking tree consistency

A minimal structured view looks like this:

{
  "digest": "sha256:4c4dc1a8898f2d8a1e7b5037a84bf0f0d9f0e8a4ddf0d0d0ec1f3f52d0af6c7b",
  "certificateSubject": "https://github.com/eu-example/payments-api/.github/workflows/release.yml@refs/heads/main",
  "integratedTime": "2026-06-21T09:13:08Z",
  "logIndex": 84219017,
  "signatureAlgorithm": "ecdsa-p256-sha256"
}

The important question is not the exact JSON shape. The important question is whether independent observers can later verify that the event existed and that the log has behaved consistently.

Transparency does not eliminate the need for trust in the operator of the log, but it reduces the amount of blind trust required. Hidden equivocation becomes harder. Retrospective investigation becomes more grounded.

It also changes public accountability. If your release process signs a test build from a private branch by mistake, the artefact may be blocked by policy later, but the evidence that it happened can still matter. That is healthier than a world where trust events disappear into vendor-specific control planes.

Provenance attestations sign claims about the build, not just the output bytes

A plain artefact signature answers one narrow question: who vouched for these bytes?

Supply chain security usually needs another question answered: how were these bytes produced?

That is where provenance attestations come in.

An attestation is a signed statement about something. For software supply chains, the statement often says that a specific builder ran a specific workflow against a specific source revision and produced a specific artefact digest.

A provenance attestation might carry claims such as:

• repository URL
• commit SHA
• build workflow path
• builder identity
• build start and finish times
• parameters or environment
• artefact digest or subject list

A schematic example:

{
  "predicateType": "https://slsa.dev/provenance/v1",
  "subject": [
    {
      "name": "registry.example.eu/platform/payments-api",
      "digest": {
        "sha256": "4c4dc1a8898f2d8a1e7b5037a84bf0f0d9f0e8a4ddf0d0d0ec1f3f52d0af6c7b"
      }
    }
  ],
  "predicate": {
    "builder": {
      "id": "https://github.com/actions/runner"
    },
    "buildDefinition": {
      "externalParameters": {
        "workflow": ".github/workflows/release.yml",
        "ref": "refs/heads/main"
      },
      "resolvedDependencies": [
        {
          "uri": "git+https://github.com/eu-example/payments-api",
          "digest": {
            "sha1": "8c7dbf5f6f37d9a7138db6e6c0a1fbe9d8f9172e"
          }
        }
      ]
    }
  }
}

Again, the exact schema varies by ecosystem, but the mechanism is consistent. The attestation binds descriptive claims to the artefact digest under a signature the verifier can evaluate.

This matters because many real attacks are not "attacker swapped the final bytes in the registry after release". They are:

• attacker manipulated the build workflow
• attacker used an unexpected runner or builder image
• attacker built from a fork or unauthorised branch
• attacker injected a dependency or input not allowed by policy
• attacker used a debug workflow to produce a release-looking artefact

A digest signature alone cannot describe any of that. Provenance can.

This is the point where software supply chain signing stops being "binary notarisation" and starts becoming an evidence system. The verifier is no longer limited to saying "the same organisation signed this". It can say:

• this image digest was produced from this repository
• at this commit
• by this workflow
• using this builder identity
• and the attestation itself was signed under the expected trust root

That is a much stronger operational statement.

It is also why provenance has to be tied back to the same immutable subject digest. If the attestation describes digest A and the deployment system pulls digest B, the attestation is irrelevant. Provenance without subject binding is paperwork.

Verification policy is where signatures become an allow or deny decision

Everything up to this point produces evidence. Verification policy is what turns evidence into a control.

A deployment gate, admission controller, package installer, or release promotion tool needs a rule set. That rule set expresses which combinations of signature, certificate, provenance, and log evidence are acceptable for a given artefact.

A useful policy typically says much more than "signature valid".

For example:

Allow this image only if:
- the image digest matches the deployed subject exactly
- at least one signature is valid
- the signing certificate chains to the expected issuer
- the certificate subject is the release workflow in eu-example/payments-api
- the workflow ref is refs/heads/main
- the signature has transparency-log inclusion proof
- a provenance attestation exists for the same digest
- the provenance says the source repo is eu-example/payments-api
- the provenance commit is reachable from the protected release branch

That is the real trust chain. Notice how little of it is "do ECDSA correctly".

A verifier that checks only signature validity is easy to fool with a valid but irrelevant signer.

A verifier that checks only repository identity but not workflow path may accept an experimental CI job that never went through release hardening.

A verifier that checks workflow path but not branch may accept pull-request merge refs or preview branches.

A verifier that checks all of that but ignores digest equality between attestation and artefact may accept evidence about the wrong object.

Policy is also where organisations encode environment-specific rules.

A production cluster may require:

• signatures from the release workflow only
• provenance present and valid
• log inclusion present
• no expired certificate at signing time
• no deprecated builder image

A development cluster may allow:

• signatures from any repository workflow under the same org
• provenance optional
• preview branch refs permitted

The crypto evidence can be identical in both cases. The policy changes the decision.

This is why teams should stop asking "is it signed?" and start asking "what does our policy require this signature to mean?"

A concrete policy evaluation often looks more like identity matching than like crypto work:

Policy is the difference between a supply chain control and a decorative signature badge.

The ecosystem is layered: package metadata, repository trust, signing frameworks, and update frameworks solve different problems

Another source of confusion is that people treat every signing system as a direct substitute for every other one. They are often complementary.

Package-manager metadata signing

APT, RPM, Homebrew taps, and similar systems often sign repository metadata rather than every package file in isolation. The important trust object may be the index or metadata manifest that maps package names to checksums. That can be a perfectly sensible design, because the client uses trusted signed metadata to decide which package blob digest to fetch.

The trust chain is:

• trust the repository metadata key
• trust the signed mapping from package name and version to digest
• fetch the package blob and verify its checksum against that metadata

That is different from simply downloading an arbitrary .deb from somewhere and checking a detached signature.

Update frameworks such as TUF

The Update Framework exists because signing alone does not solve rollback, freeze, fast key revocation, threshold signing, and repository compromise scenarios cleanly.

TUF introduces signed roles, delegations, metadata expiry, version counters, and threshold rules. Its purpose is not just "make signatures available". Its purpose is to structure update trust so clients can resist a wider class of repository and key compromise attacks.

If you need secure update distribution to many clients over time, TUF answers problems a basic signature log does not.

in-toto style attestations

in-toto focuses on describing steps in a software supply chain and attaching signed statements to them. It is especially useful when you want evidence about multiple build stages, not only the final release artefact.

That is closer to process attestation than to classic package signing.

Sigstore style keyless signing and transparency

Sigstore's main contribution is not inventing digital signatures. It is combining workload identity, short-lived certificates, and a transparency log so that signing can fit modern cloud-native CI workflows without every pipeline hoarding a durable private key.

Those pieces can work with OCI images, blobs, binaries, and attestations, but they do not replace the need for local policy or for update-framework style protections where those are required.

A production environment may therefore combine several layers:

• TUF or signed repository metadata to distribute trusted references
• keyless artefact signatures to identify who built a release
• provenance attestations to describe how it was built
• admission policy to decide what may run in each environment

The practical lesson is simple: ask which problem each layer solves before declaring one of them the winner.

Signing, SBOMs, and reproducible builds are related but not interchangeable

One more source of confusion is the tendency to treat signing, SBOM generation, and reproducible builds as if each one automatically implied the other two.

They answer different questions.

• Signing asks: who vouched for this exact digest?
• SBOMs ask: what components and packages are claimed to be inside or used by this artefact?
• Reproducible builds ask: can an independent party rebuild from the same source and get the same output bytes?

Those three ideas reinforce each other, but none of them subsumes the others.

An SBOM can be unsigned. In that case it is only a statement someone produced, not one the verifier can tie to a trusted identity. A signed SBOM is better, but it still may not describe the exact digest being deployed if the subject binding is loose or if the document was generated for a slightly different build.

A signed artefact can still have a weak or incomplete SBOM. The signature tells you who vouched for the bytes, not whether they enumerated every transitive dependency, bundled library, or generated component accurately.

A reproducible build can tell you that independent rebuilders arrived at the same bytes from the same declared source inputs. That is extremely valuable, especially for high-trust package ecosystems. But reproducibility does not tell you whether the original release workflow was the one your production policy expects, whether the signing event was logged, or whether the repository identity matched the maintainer path you trust.

In practice, a strong supply chain story often looks like this:

1. sign the final artefact digest
2. sign the provenance that explains where it came from
3. sign or otherwise bind the SBOM to the same subject digest
4. where possible, support reproducible or at least verifiable rebuilds
5. make policy check the pieces that matter for the environment

That sequence matters because operators often need to answer several different questions during an incident.

• Was the production image the one the release workflow signed?
• Did the provenance say it came from the protected repository and branch?
• Did the SBOM claim the vulnerable package was present?
• Could an independent rebuilder reproduce the same bytes from the claimed source?

Those are related checks, but they are not duplicates. Treating them as separate evidence layers keeps the trust model honest.

If a vendor says "we have supply chain security because we sign releases", the next question should be "what binds the signature to provenance, dependency inventory, and the exact deployed digest?" If they cannot answer that cleanly, the signing layer may still be useful, but it is not the whole control.

A real verification pipeline checks evidence in a strict order

It is useful to walk a realistic path from source commit to production admission.

Imagine a release of payments-api built in a CI system for a company based in Amsterdam.

1. Source is fixed

The release workflow runs on commit 8c7dbf5f6f37d9a7138db6e6c0a1fbe9d8f9172e from refs/heads/main in eu-example/payments-api.

2. Build output is materialised and hashed

The workflow builds an OCI image and gets digest:

sha256:4c4dc1a8898f2d8a1e7b5037a84bf0f0d9f0e8a4ddf0d0d0ec1f3f52d0af6c7b

From here onward, that digest is the subject.

3. The workflow obtains a short-lived signing identity

The CI job presents an OIDC token to a certificate-issuing service, which returns a short-lived certificate binding the workflow identity to an ephemeral public key.

4. The workflow signs the digest

The ephemeral private key signs the artefact subject. The signature plus certificate are persisted.

5. The signing event is logged

The signature and certificate are submitted to a transparency log, which returns an inclusion proof or equivalent receipt.

6. Provenance is generated and signed

The workflow emits a provenance attestation describing source repository, commit, builder identity, workflow path, and subject digest, then signs that attestation as well.

7. The artefact, signature, and attestation are published

The registry contains the artefact digest. The associated signature and attestations are discoverable through the chosen distribution mechanism.

8. The deployment system resolves the reference to a digest

Production does not deploy payments-api:stable and hope for the best. It resolves that reference, obtains the digest actually about to run, and verifies evidence against that digest.

9. The policy engine evaluates

The verifier checks:

• digest equality between artefact and evidence
• signature validity
• certificate issuer
• certificate subject identity
• branch or workflow claims
• log inclusion proof
• provenance signature validity
• provenance subject digest equality
• provenance claims about source and builder

10. Only then does admission happen

If all checks pass, the image is allowed into production. If any fail, the gate should say exactly which trust condition failed.

That final point matters. Security controls that fail opaquely train engineers to route around them. A useful gate should produce messages like:

• rejected: signature valid but certificate subject was preview workflow
• rejected: provenance subject digest did not match image digest
• rejected: log inclusion proof missing
• rejected: signature from trusted issuer but repository identity mismatched

Those are not luxury error messages. They are the only way operators can distinguish attack surface from normal release friction.

Supply chain signing still fails in predictable ways

The current wave of supply chain tooling is useful, but it is also surrounded by marketing language that implies more certainty than the mechanism supports. A few failure modes are worth naming directly.

Signing can bless malicious output if the build path itself was compromised

If an attacker modifies the source branch, steals maintainer review authority, compromises the CI runner, or tampers with build inputs before signing, the resulting artefact can be perfectly signed and perfectly logged.

The trust chain will then accurately report that the trusted workflow produced malicious output. That is still valuable evidence, but it is not prevention.

Signing proves who vouched for the bytes, not that the bytes were good.

Policy that is too broad quietly removes the benefit

A rule like "accept any signature issued by GitHub Actions" is nearly equivalent to not having a meaningful rule at all.

A rule like "accept any signature from this organisation" can still be too broad if dozens of unrelated repositories and workflows share the trust boundary.

The narrower the operational requirement, the more specifically the policy should name it.

Mutable references can bypass careful evidence handling

Teams sometimes verify one digest in CI, then deploy a mutable tag later in CD. That breaks the chain between verified subject and deployed subject.

If the deployment engine does not pin the exact digest it verified, it can end up running something else.

Provenance can become paperwork if nobody enforces it

Generating attestations is easy to demonstrate and easy to ignore. If admission policy never checks them, the organisation has created an archive, not a control.

Log availability and trust assumptions still matter

Transparency logs help, but they are infrastructure. Clients need trust roots, inclusion verification logic, and availability assumptions. A verifier that says "log optional" gets less incident value than one that requires evidence.

Tooling abstraction can hide the threat model

When a platform UI says "verified publisher" or "signed image", engineers may assume a lot more than the badge means. Some badges mean the signature was cryptographically valid. Others mean the account owner passed some publisher check months ago. Others say nothing about branch, build path, or provenance.

The safe habit is to ask: what exact statement did the verifier test?

Offline and private ecosystems still have different constraints

Public transparency and cloud OIDC flows fit internet-connected CI well. Air-gapped build systems, firmware update pipelines, and regulated environments may need private roots, staged logs, or explicit offline signing ceremonies. The mechanism changes. The trust questions do not.

What signing is good at, and what it cannot solve by itself

Supply chain signing is excellent at a specific class of problem.

It is good at proving that:

• the artefact you see now is byte-for-byte the artefact that was signed
• the signature was produced by a key or certificate identity the verifier can evaluate
• a build claim or provenance statement was attached to that artefact digest
• the signing event can be made visible for later audit if transparency is part of the design

It is not sufficient by itself to prove that:

• the source commit was safe
• the code review process was honest
• the CI runner was uncompromised
• the dependencies were benign
• the build was reproducible
• the release policy was sensible

That list is not an argument against signing. It is an argument for using signing in the right slot.

A mature supply chain control plane usually combines:

• source protection and review controls
• dependency management and pinning
• isolated or hardened build environments
• artefact signing
• provenance attestation
• policy enforcement at promotion or admission time
• observability and incident response around trust events

If signing is presented as the whole programme, the programme is underspecified.

If signing is presented as one strong evidence layer in a broader system, it is extremely useful.

The practical mental model is digest, identity, evidence, policy

Most confusion disappears if you reduce the topic to four questions asked in order.

1. Digest

What exact bytes are we talking about?

If the answer is a tag, a filename, or a release label, you are not ready to reason about signatures yet.

2. Identity

Who signed those exact bytes?

Was it a static key, a short-lived certificate, a repository workflow identity, or something else?

3. Evidence

What supporting proof exists around that signature?

Do you have a certificate chain, a transparency-log inclusion proof, a provenance attestation, build metadata, threshold signatures, or update-framework metadata?

4. Policy

What combination of digest, identity, and evidence is acceptable for this environment?

If your answer is still "anything signed by us", your control is much weaker than it probably needs to be.

That four-part model is mechanism-first, and it scales across ecosystems. It works for OCI images, package repositories, firmware bundles, and signed update metadata because the same trust questions recur even when the file formats change.

The industry is finally moving away from the simplistic idea that one long-lived release key and one green tick solve software trust. That is progress. But the replacement is not magic either. It is a more explicit chain: immutable subject, constrained signer identity, public evidence, and local verification policy.

If you remember one sentence from all of this, make it this one: supply chain signing does not tell you that software is good. It tells you which exact bytes were vouched for, by which identity, under which evidence, and whether your policy accepts that story.