CI/CD / Integrity, coordination, and improvement / Lesson 13

Supply-chain verification at the consumer boundary

Verify who built an artifact and whether its inputs satisfy policy before adoption.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Distinguish digest, signature, provenance, and dependency inventory.
Model policy checks on authenticated build claims.

Different records answer different questions

A digest identifies bytes. A signature authenticates a statement under an identity and trust system. Provenance describes build relationships. A dependency inventory or SBOM describes components under its own scope and completeness assumptions. None alone proves that software is harmless. Parcel’s consumer needs to know that the intended candidate came from an approved source and builder, passed required checks, and matches the downloaded package. A beautifully formatted inventory cannot replace a source-to-artifact relationship, and a signed malicious build remains malicious.

Authenticate before evaluating fields

A JSON document can claim any builder or revision. The consumer must authenticate the statement using the selected attestation system, verify the subject digest against the artifact, and then evaluate expected source, builder, and build parameters. The trust policy should name acceptable identities and conditions rather than accepting any valid signature. Signature validation and policy validation are separate steps. The following record is intentionally not a real attestation: it illustrates expectations without fake cryptographic material or a claim of SLSA conformance.

json A consumer expectation record

{"expected_builder":"parcel-approved-builder","expected_source":"parcel-reviewed-source","expected_candidate":"candidate-r8","required_checks":["unit","contract"]}

These synthetic labels describe local policy inputs. They are not signer identities, certificate subjects, cryptographic digests, or a complete provenance schema. A real verifier must authenticate evidence before trusting its fields.

Unexpected inputs can change the build

Even an approved builder can produce unintended output when invoked with unsafe parameters or an unreviewed build definition. Inspect the permitted source location, revision, entry point, dependency resolution, and relevant external parameters. A privileged release should not accept an arbitrary script URL merely because the surrounding job runs on a trusted platform. Minimize parameter flexibility and prefer reviewed configuration in source. Record exceptions explicitly so consumers can distinguish a normal build from a manually altered invocation with a superficially similar name.

Keep consumer policy testable

The complete local model assumes authentication has already succeeded and evaluates a small policy against synthetic claims. It rejects an unexpected builder even when the candidate label matches. This is not signature verification, provenance parsing, or a supply-chain security product. Its value is making the policy boundary explicit: authentication establishes who made a claim, while the consumer decides whether that claim is acceptable. Test negative cases such as wrong source, wrong builder, missing evidence, and unexpected parameters.

python Evaluate already authenticated synthetic claims

expected = {"builder": "approved", "source": "reviewed"}
def accepted(claim):
    return all(claim.get(k) == v for k, v in expected.items())
print(accepted({"builder": "approved", "source": "reviewed"}))
print(accepted({"builder": "other", "source": "reviewed"}))

Expected output

True
False

The model cannot authenticate any document and must never be presented as an attestation verifier. It only demonstrates exact consumer expectations after authentication.

Evolve trust with evidence

Builder upgrades, signing identity changes, and source moves can legitimately change provenance. Manage those as reviewed policy changes rather than weakening verification whenever a release is blocked. Retain enough evidence to explain why an old candidate was accepted under an earlier policy. A dependency vulnerability discovered later may require reevaluation even when provenance remains valid. Integrity evidence supports traceability and controlled decisions; it does not freeze the security state of dependencies or eliminate the need for updates and incident response.

Common errors and fixes

Any valid signature is accepted for production.

Why it happens: Cryptographic validity was confused with an approved signer and build policy.
How to fix it: Require the intended identity, subject, builder, and input expectations.
Prevent it next time: Test policy rejection for valid but unauthorized claims.

A build claim names the correct source but refers to different bytes.

Why it happens: The provenance subject was not bound to the downloaded artifact.
How to fix it: Verify the artifact digest against authenticated subject metadata.
Prevent it next time: Make subject binding mandatory before evaluating higher-level claims.

A blocked release causes the verifier to be disabled.

Why it happens: Policy evolution has no controlled exception process.
How to fix it: Investigate the changed identity or input and review a bounded policy update.
Prevent it next time: Version trust policy and retain acceptance evidence.

Check your understanding

1. An SBOM lists all declared libraries. Does that prove the package came from the reviewed source?

Show worked solution

No. Component inventory and build origin are separate claims. Verify authenticated provenance bound to the package, then evaluate source and builder policy. Also understand inventory scope; a list can be incomplete or describe a different artifact.

2. A trusted builder is invoked with an unreviewed script parameter. Should its signature make the candidate acceptable?