Software Supply Chain Threat Modeling

Software Supply Chain Threat Modeling

This lesson introduces a practical supply-chain threat model and shows why a secure source repository alone cannot establish trust in a release.

A release inherits trust from more than its source repository

A software release is the result of a chain: people contribute source code, maintainers approve changes, packages and base images are selected, a build service combines inputs, signing or release systems distribute artifacts, and deployment systems deliver them to users. Every link can introduce an error, a compromise, or an undocumented assumption.

Start by tracing one real release. Where does source originate? Which repositories and branches are trusted? Which dependencies, package registries, build actions, container images, compilers, services, and credentials are involved? Who can change build definitions, publish artifacts, approve a release, or alter the deployment environment? Do not omit third-party automation merely because it is convenient or familiar.

Threat modeling is not an exercise in predicting every attacker. It is a way to state what could go wrong and which control would make that outcome less likely, more visible, or easier to recover from. Examples include a malicious dependency update, dependency confusion, compromised maintainer account, altered build definition, leaked publishing token, substituted artifact, or an urgent vulnerability that cannot be located in deployed products.

Name the asset and consequence. A modified test dependency may create limited risk, while a signing key or production deployment credential can change many releases. This distinction helps teams prioritize controls around high-impact trust boundaries instead of applying the same burden to every package.

Choose controls that address a specific assumption

Controls are strongest when they address a named assumption. Code review and branch protection reduce the chance of unauthorized source changes. Dependency pinning and trusted registries reduce ambiguity about what is acquired. Isolated build services and restricted credentials reduce build tampering. Artifact signatures and provenance can help a consumer evaluate origin. Logging and retention support investigation when a release must be traced.

No individual control proves everything. A signature can show that an authorized key signed an artifact; it cannot prove the source change was safe or the build environment was uncompromised. An SBOM can list declared components; it may not show runtime-loaded or unknown components. A vulnerability scanner can compare known component versions to known vulnerability data; it cannot decide organizational impact, exploitation, or whether a finding is reachable.

Consider attacker capability and operational cost. A small internal service might first benefit from inventory, protected repository access, reviewed updates, and an ability to rebuild quickly. A critical public product may require additional isolation, hardened build infrastructure, independent approvals, provenance verification, and supplier assurance. Maturity should be incremental and evidence-driven rather than a claim to meet a label without understanding its requirements.

Keep the model current. New package ecosystems, AI coding assistants, hosted build actions, container registries, and deployment platforms can add new inputs or identities. Every major delivery change deserves a short review of the trust path it introduces.

Resources

• NIST SP 800-218 Secure Software Development Framework — Use NIST’s SSDF as a common vocabulary for integrating secure software practices across development, acquisition, vulnerability response, and supplier communication.