Trust Travels from Source to Runtime

Trust Travels from Source to Runtime

Map developers, repositories, workflows, runners, registries, deployers, and workloads as one chain of authority.

Every handoff accepts a claim from another identity or system

A developer merges code. A workflow definition tells a runner how to build it. The runner retrieves dependencies, produces an artifact, and pushes it to a registry. A deployment system accepts that artifact and creates a workload. Each step relies on a claim made by the step before it.

That reliance is a trust boundary. The repository trusts the developer’s authenticated session and review process. The runner trusts the workflow and source revision. The registry trusts the publishing identity. The deployer trusts the artifact reference and policy. The runtime trusts the image and configuration it receives. A compromise at one boundary can inherit legitimacy from all the later ones.

Detection begins by making the handoffs visible. Record stable identities for the developer, automation client, runner, builder, registry publisher, deployer, service account, and workload. Preserve immutable identifiers for the commit, workflow version, job, artifact digest, deployment, and running image. Names and tags help humans, but they can move. Digests and provider-issued IDs let evidence refer to the same object over time.

Credentials cross the chain too. A short-lived job token may assume a cloud role. A registry credential may be available to a runner. A maintainer token may change branch protection or publish a release. Secret theft is meaningful because of the authority and boundary it unlocks, not merely because a secret-looking string appeared.

CI/CD and Developer-Environment Detection Opportunities organizes evidence around source, build, dependency, artifact, deployment, and runtime. The point is not to collect every possible log. It is to identify transitions where a false claim would let untrusted work inherit trusted authority.

Threat intelligence can tell you that current actors target developer identities, workflow files, package ecosystems, and trusted release channels. Your local architecture tells you which handoff those behaviors would exploit and which evidence could reveal it. A useful detection claim names the boundary, identity, object, and state change rather than promising to detect “supply-chain attacks” as one category.

Resources

• SLSA Specification — Primary reference for the standards and concepts discussed in this lesson.