Start by treating the software supply chain as one control plane with distinct checkpoints at each stage. Define baseline requirements for source code, build systems, dependencies, artifacts, and deployment configuration, then automate checks in CI/CD so failures are visible early. The goal is not just compliance, but repeatable evidence that insecure changes are detected before they reach production.
How to stage software supply chain checks from source to deployment
Security teams get better results when they treat the pipeline as a sequence of trust gates, not a single policy file. Each stage should verify a different failure mode: source integrity, build provenance, dependency trust, artifact integrity, and deployment configuration. That staging model makes it easier to automate controls in CI/CD and produce evidence that insecure changes were blocked before release.
A useful way to design the checks is to ask what must be true before the next stage is allowed to proceed. Source-stage checks should focus on commit integrity, branch protection, code review, and prohibited content. Build-stage checks should validate the builder, the recipe, and the provenance of the produced output. Dependency-stage checks should validate origin, version pinning, and known risk in third-party components. Artifact-stage checks should confirm that what was built is what is being promoted. Deployment-stage checks should verify that the release is being placed into the expected environment with the expected configuration.
That separation matters because failures are not interchangeable. A clean source repository does not compensate for a compromised build worker, and a signed artifact does not help if deployment pulls the wrong image tag or inherits insecure defaults. The practical goal is to narrow the blast radius at each checkpoint and make every stage capable of failing closed when its inputs are not trustworthy.
What each supply chain stage should verify
At the source stage, teams should check for protected branches, mandatory reviews, signed commits where appropriate, and policy on who can change build definitions or dependency manifests. That is the first line of defence against tampered source and malicious workflow changes. If you allow direct changes to pipeline definitions or release manifests, you have already weakened every downstream control.
At the build stage, verify that the build environment is controlled, reproducible where possible, and isolated from untrusted secrets or ad hoc tooling. This is where many supply chain failures become operationally visible, especially when build jobs can read tokens, publish artifacts, or execute arbitrary scripts. SLSA is useful here because it centres the conversation on build provenance and integrity, which is exactly what teams need when they want evidence that a release came from the expected process.
At the dependency stage, treat third-party packages, build plugins, and transitive libraries as an explicit control point rather than a passive convenience. Teams should verify the source of the dependency, pin versions, review update paths, and block obviously risky inputs before they enter the build. Open source ecosystem guidance from OpenSSF is valuable because it gives teams a broader supply chain security context for package trust, scorecards, and hygiene practices.
At the artifact stage, focus on what is being promoted, stored, and released. Check signatures, checksums, provenance metadata, and repository permissions so the published artifact cannot be silently replaced or retagged. If the artifact is the unit of deployment, then artifact integrity is the control that stops “looks right” releases from becoming “is right” by assumption alone.
At the deployment stage, validate the target environment, configuration, and policy boundary. Deployment checks should confirm that the artifact is being delivered to the intended cluster, account, or environment with the expected security settings, not a shadow or relaxed path. This is where teams catch drift between approved release content and insecure runtime placement, especially in multi-environment and multi-account setups.
Risk and Threat Considerations
Software supply chain controls fail most often when one stage is treated as symbolic and the others are treated as real. Attackers look for the weakest checkpoint, especially dependency updates, build automation, and release permissions, because compromising one trusted stage can give them reach into many downstream systems. If stage-specific evidence is missing, the organisation may believe it has control coverage when it actually has only partial visibility.
Failure mechanism: Trusted pipeline components can be abused through poisoned dependencies, compromised build credentials, altered release artifacts, or insecure deployment paths, allowing malicious code to move forward under the appearance of normal automation.
Impact: A single weakness can cascade into production compromise, credential exposure, unauthorised code execution, or widespread artifact trust failure across multiple applications and teams.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and artifact integrity are central to supply chain checks. |
| Recommendation — Adopt SLSA provenance and integrity controls for build outputs. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | CIS software supply chain checks align with secure software and change control. |
| Recommendation — Enforce software supply chain safeguards across source, build, dependency and release stages. | ||
| NIST SP 800-53 Rev 5 | SA-12 — Supply Chain Protection | Directly addresses protecting software and components across the acquisition and build chain. |
| CM-3 — Configuration Change Control | Pipeline stages depend on controlled changes to source, build, and deployment settings. | |
| Recommendation — Apply SA-12 to verify source, supplier, and component integrity throughout the pipeline. Require approved change control for code, build definitions, and deployment configuration. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Software supply chain checks support secure construction and verification of application delivery. |
| Recommendation — Build verification gates into the delivery process and block untrusted changes from promotion. | ||
Practitioner Guidance
What to prioritise: Start with the checks that block irreversible promotion, especially source protection, build provenance, and artifact signing or verification. Those controls usually give the highest value because they stop bad output before it becomes widely distributed.
What to verify: Make sure every stage produces an audit trail that answers who approved the change, what was built, what dependencies were included, and what artifact was deployed. If a stage cannot produce that evidence, it is not yet a reliable control point.
Common mistake: Teams often add scanning without adding policy enforcement. Scanning alone finds problems, but it does not stop unsafe material from advancing unless the pipeline is configured to fail or require exception handling.
Practitioner takeaway: The most effective supply chain programme is the one that makes trust explicit at every handoff, because gaps between stages are where compromised code and compromised process usually meet.
Related resources from NHI Mgmt Group
- How should teams implement software supply chain security across build pipelines?
- How should security teams scope a software supply chain security programme across build, release, and consumption stages?
- How should security teams implement dependency graphing to manage indirect software supply chain risk?
- How should security teams contain an upstream software supply chain breach across build and runtime environments?