Protect the access software supply chain

Protection need

Access components process credentials, policy, identity, routes, and protected traffic. A malicious source change, dependency, build action, artifact, deployment identity, or update can bypass every runtime policy. Protect the chain from source intent to the exact bytes and configuration running in each environment.

Map repositories, maintainers, review rules, dependencies, package sources, build definitions, builders, secrets, runners, artifacts, registries, signatures, attestations, deployment controllers, environments, and runtime identities. Include third-party images, plugins, policy libraries, generators, base images, and emergency release paths.

Security objectives and requirements

• Only authenticated, authorized source and dependency changes enter a protected build.
• A build runs from a declared definition in an isolated, ephemeral environment with bounded network and secret access.
• Provenance identifies the source, build definition, builder, dependencies or materials, and immutable artifact digest.
• Deployment verifies artifact identity and required evidence before use.
• Release and deployment identities cannot approve their own high-risk changes.
• Runtime inventory connects each access component to its digest, configuration, provenance, owner, and rollback artifact.
• Compromised source, builder, artifact, registry, or credential can be revoked and replaced.

An SBOM lists components. Provenance states how an artifact was produced. An attestation is a signed or authenticated statement about an artifact. A signature binds identity to bytes. A verification policy decides which evidence and identities are acceptable. None alone proves the software is safe.

Security invariants and evidence

The artifact deployed is the artifact reviewed and verified. Its digest is immutable across promotion. The builder identity and build definition meet the policy. Untrusted code cannot alter evidence after the build. Production deployment accepts only approved artifact and configuration identities. Rollback uses a known artifact with still-valid trust, not a fresh rebuild of an old source revision.

Evidence includes source revision, review and approval, dependency lock state, vulnerability and license results, build definition, builder identity, provenance, artifact digest, SBOM, signature or attestation verification, deployment identity, environment, runtime digest, and exception expiry.

Failure cases

• A protected branch can still invoke an unreviewed mutable build action.
• A trusted build downloads undeclared code from the network.
• A signed artifact lacks trustworthy provenance or was signed after compromise.
• An SBOM omits generated, vendored, runtime, or base-image components.
• A tag changes while deployment policy trusts the tag instead of a digest.
• The same identity can change source, build, approve, and deploy.
• Emergency release bypass becomes the normal path.
• Rollback restores a known-vulnerable artifact or revoked signing identity.
• Runtime mutation makes the verified artifact different from the executing state.

Design tradeoffs and residual risk

Hermetic builds improve reproducibility and require controlled dependency acquisition. Automated updates reduce exposure time and can introduce malicious or incompatible releases. Strong deployment policy improves assurance and can block emergency recovery when evidence infrastructure fails.

More attestations do not help when their predicates are vague or every signer is trusted. Independent builders and reproducible results raise assurance and cost. Set requirements from the authority and exposure of the component.

Residual risk includes malicious reviewed code, compromised trusted maintainers or builders, vulnerable but authentic dependencies, runtime exploitation, and evidence systems that attest to the wrong property.

Pomerium boundary

Pomerium publishes software and deployment guidance. Each operator owns how artifacts are selected, verified, configured, promoted, deployed, inventoried, observed, and rolled back in its environment. Product provenance cannot prove the security of the operator's images, plugins, policy modules, CI system, configuration, or deployment path.

Exercise

Trace one deployed access component from runtime digest back to artifact, provenance, builder, build definition, source revision, dependency state, review, and owner. State which claim each evidence item proves and what it does not prove.

Attempt four controlled failures: mutable tag replacement, artifact with no required provenance, build from an unapproved source revision, and deployment by an unauthorized identity. Verify policy blocks each case. Then revoke one trusted builder and prove that its new artifacts fail while a reviewed recovery artifact can deploy.

Evaluation checklist

• Does the model include source, dependencies, build, evidence, artifact, deployment, and runtime?
• Are SBOM, provenance, attestation, signature, and verification policy used for distinct claims?
• Does deployment verify immutable artifact identity and required evidence?
• Are high-authority source, build, approval, and deployment duties separated?
• Can the team revoke a compromised supply-chain identity and recover with known-good artifacts?