GitHub Actions / Identity, coordination, and governance / Lesson 14

Action dependency identity and artifact attestations

Review what a dependency pin proves and verify build claims at the consumer boundary.

About 4 min readContent reviewed 2026-10-28

On this page

Lesson goals

Explain mutable tags, reviewed commit pins, and update responsibility.
Distinguish authenticated provenance from byte hashes and safety claims.

Every uses reference adds executable trust

An action or reusable workflow can execute commands, read files, access its permitted token, and influence outputs. A popular name or marketplace badge does not remove that authority. Parcel should review implementation, maintenance, nested dependencies, runtime requirements, and permission needs before adopting it. A full commit SHA identifies a specific repository revision more precisely than a mutable tag or branch. It does not prove the revision is safe, independently reproducible, or free of compromised dependencies. Identity is a foundation for review, not its conclusion.

Pins need a maintained change process

A pinned dependency remains on old content until deliberately updated. Review updates for behavior, permissions, runtime compatibility, and nested executable inputs. Automated update proposals can help discovery but should still pass the repository’s review and test contract. Do not invent a forty-character string to make an example look secure. This course uses conceptual identity records and official action repositories instead of fabricating pins. In an actual workflow, obtain and review the real commit from the intended repository and retain why that identity was accepted.

A signed claim connects build context

Artifact attestations can provide cryptographically signed provenance associated with a built artifact. Consumers need to verify the signature or identity system, bind the claim’s subject to the received bytes, and evaluate expected repository, workflow, revision, and builder conditions. Availability and verification behavior depend on repository context and selected tooling. A matching digest alone identifies bytes but not their origin. A valid attestation can truthfully describe a build that violates consumer policy, and it does not establish that the software has no vulnerabilities.

Describe consumer expectations explicitly

The following JSON is a synthetic expectation record, not a GitHub attestation, Sigstore bundle, or SLSA predicate. It makes the intended source and workflow relationship visible without fake cryptographic fields. A real consumer should use supported verification tooling and documented policy options. Keep provenance and dependency inventory separate: an SBOM describes components within its scope, while provenance describes build relationships. Either can be useful, but neither should be accepted for a different artifact merely because the filename matches.

json A synthetic consumer expectation record

{"repository":"parcel-lab/source","workflow":"reviewed-build-definition","candidate":"parcel-lab-r3","required_origin":"approved-build-path"}

The labels are declared teaching inputs. This record cannot verify an artifact and claims no attestation-format conformance. No signing service, registry, repository API, or verifier is contacted.

Reject an otherwise plausible wrong origin

The complete local model assumes authenticated claims and compares two expected fields. It rejects another workflow even when repository identity matches. Real verification must also check the artifact subject, relevant parameters, trust roots, certificate or signature validity, and any policy-specific conditions. This program intentionally omits those security mechanisms and must not be reused as a verifier. Its limited purpose is showing that consumer expectations remain necessary after cryptographic authentication and that a familiar repository alone does not authorize every build path.

python Evaluate an origin expectation offline

expected = {"repository": "parcel-lab/source", "workflow": "reviewed-build"}
def policy(claim):
    return all(claim.get(k) == v for k, v in expected.items())
print(policy(dict(expected)))
print(policy(dict(expected, workflow="unreviewed-build")))

Expected output

True
False

This is a dictionary predicate over synthetic already-authenticated data. It does not parse, sign, download, or verify an actual artifact attestation.

Common errors and fixes

A full commit pin is described as proof that an action is safe.

Why it happens: Precise identity was confused with security review.
How to fix it: Review the pinned implementation, authority, and nested dependencies.
Prevent it next time: Retain review rationale and an update process.

A valid attestation from another workflow is accepted.

Why it happens: Consumer policy checks only signature validity or repository name.
How to fix it: Require the intended subject and build-path expectations.
Prevent it next time: Test rejection of authenticated but unauthorized claims.

A tutorial contains a made-up commit pin or digest.

Why it happens: A visual appearance of security replaced real identity evidence.
How to fix it: Use verified real identities in operations and clearly synthetic labels in teaching.
Prevent it next time: Never present invented cryptographic strings as trusted metadata.

Check your understanding

1. A dependency pin never changes for two years. Is immutability alone a healthy maintenance policy?

Show worked solution

No. The identity remains stable, but known vulnerabilities, runtime changes, and maintenance concerns can accumulate. Review updates through a controlled process and preserve compatibility evidence. Stability should support deliberate change, not permanent neglect.

2. The downloaded package has the expected hash but its verified attestation names an unapproved workflow. What follows?