The supply chain trust boundaries — six stages, each with a threat model

A software supply chain is a pipeline of six stages through which an artifact travels from a developer’s intent to a running process in production. Each stage is a trust boundary: a place where one party hands bytes or identities to another, and where an attacker can substitute one for the other. The threat model of a supply chain is the union of the threat models at each boundary. The production discipline is to verify at every boundary, not to trust any of them.

The six stages

The six stages, in order, are:

1. Source. A developer writes code and commits it to a repository. The commit is the first artifact in the chain.
2. Dependency. The build pulls in libraries, container base images, and tools from external sources. The dependency tree is the second surface.
3. Build. The CI pipeline compiles, packages, and signs the artifact. The builder identity is the third surface.
4. Artifact. The registry stores the artifact and its attestations. The registry is the fourth trust store.
5. Deployment. The deployer pulls the artifact and applies it to a target. The deployer identity is the fifth surface.
6. Runtime. The artifact runs in production. The runtime boundary — the syscall, the network egress, the secret read — is the sixth.

flowchart LR
    A["Source: commit"] --> B["Dependency: external libs"]
    B --> C["Build: CI pipeline"]
    C --> D["Artifact: registry"]
    D --> E["Deployment: cluster"]
    E --> F["Runtime: process"]
    A -. "verify: branch protection / signed commits" .-> A
    B -. "verify: SBOM / lock file pinning" .-> B
    C -. "verify: SLSA provenance / signed build" .-> C
    D -. "verify: cosign verify / digest pin" .-> D
    E -. "verify: deployer identity / policy" .-> E
    F -. "verify: admission control / runtime policy" .-> F

The dotted lines are the verifications. Each stage produces artifacts; each verification checks that the artifacts at the next boundary match what the previous stage claimed. A break in any verification is a break in the chain.

The threat model at each boundary

The attacker’s capability differs at each boundary. At the source boundary, the attacker can attempt to commit code under the developer’s identity, or to commit code through a stolen pat. At the dependency boundary, the attacker can publish a malicious package with a similar name, or compromise a popular package’s maintainer account. At the build boundary, the attacker can compromise the runner, inject steps into the pipeline, or read secrets during the build. At the artifact boundary, the attacker can substitute a digest, republish a tag, or strip an attestation. At the deployment boundary, the attacker can substitute a deployer identity, push a different image to a target cluster, or bypass admission control. At the runtime boundary, the attacker can exploit the binary, exfiltrate secrets, or pivot to a peer service.

Mapping incidents to boundaries

The threat model is not abstract. Recent incidents map cleanly to the boundaries above:

• SolarWinds (2020): the build boundary. The attacker modified the build pipeline to inject a backdoor into the Orion artifact. The artifact was signed by the build platform, so the signature was valid. The attack exploited the absence of provenance verification.
• Codecov (2021): the dependency boundary. The attacker modified a script pulled by the Codecov uploader. The script ran in the build environment and exfiltrated secrets. The attack exploited the absence of dependency pinning and script integrity checks.
• 3CX (2023): the dependency boundary, again. A trojanised version of the X_Trader application was installed by an engineer; the trojanised binary then trojanised the 3CX desktop application. The attack exploited the absence of dependency verification from the developer’s workstation.
• xz-utils (2024): the dependency boundary, with a build trigger. The attacker spent two years gaining the trust of the maintainer, then merged a backdoor that activated only when the package was built by a specific toolchain. The attack exploited the absence of provenance verification and the assumption that a long-standing maintainer is a trusted boundary.

The pattern is the same across all four: the attacker succeeded at a boundary the defender did not verify. The fix is not “be more careful”. The fix is “verify at every boundary”.

Production discipline

The production discipline of supply-chain security is to verify at every boundary, not to trust any of them. The verifications are domain-specific (branch protection at source, SBOM at dependency, provenance at build, signature at artifact, admission control at deployment, runtime policy at runtime), but the rule is the same: the chain is only as strong as the weakest boundary it fails to verify.

Cross-course references

• Git, CI/CD & GitOps — Part XLV-06 (Provenance) establishes the verification at the build boundary this lesson maps to.
• Git, CI/CD & GitOps — Part LXV-02 to LXV-06 cover each of the six boundaries in detail.
• Linux for Production Sysadmins — Part XII (RepoSecurity) covers the OS-level analogue of the dependency boundary.
• Terraform for Production Sysadmins — Part XX (Module Trust) covers the same six-boundary model applied to Terraform modules.

Quiz