Upstream component governance controls what enters the build in the first place, including package source, remediation status, and policy enforcement. Artifact scanning examines the resulting image, code, or infrastructure artifact for vulnerabilities, misconfigurations, and secrets. Both are needed because governance reduces exposure before build, while scanning verifies the security state of what is actually shipped.
How upstream governance and artifact scanning differ
Upstream component governance is the control point before the build. It decides which packages, dependencies, registries, remediations, and policy exceptions are allowed to enter the software supply chain at all. Artifact scanning is a post-build verification step. It inspects the image, binary, package, or infrastructure artifact that will be shipped, looking for vulnerabilities, misconfigurations, exposed secrets, and other issues that survived earlier controls.
The practical distinction is timing and trust boundary. Governance tries to prevent bad inputs from becoming part of the release candidate, while scanning confirms what the release artifact actually contains. A mature program uses both because one is preventative and the other is detective, and neither fully substitutes for the other.
That split matters most when a dependency is approved upstream but later turns out to be unsafe, or when an artifact is built from clean inputs but is contaminated by a misconfigured pipeline, embedded secret, or vulnerable base layer. Good supply chain security assumes both the source set and the produced artifact can drift from intended state.
What each control is responsible for
Upstream governance focuses on policy decisions and supply inputs. Typical questions are whether a component is from an approved source, whether it has a current remediation status, whether it meets version and provenance requirements, and whether exceptions are tracked with ownership. The control is strongest when it blocks unsafe packages before they are introduced into the build graph.
Artifact scanning focuses on the deliverable. It checks the assembled output for known vulnerabilities, hidden secrets, insecure configuration, and drift from the expected build result. It is especially important for container images, compiled packages, deployment manifests, and infrastructure artifacts where the final object can differ materially from the inputs that created it.
In practice, the two controls answer different governance questions. Upstream component governance asks, “Should this component be allowed in?” Artifact scanning asks, “What is actually in the thing we are about to ship?”
Why both are needed in software supply chain security
Relying on only one layer creates blind spots. Governance can approve a package that later becomes risky because of a newly disclosed weakness, transitive dependency change, or build-time abuse. Scanning can catch some of that after the fact, but by then the artifact already exists and may need to be rebuilt, blocked, or revoked.
The reverse is also true. Scanning alone does not fix dependency selection, provenance gaps, or allow-list discipline. If the build is fed by uncontrolled sources, the artifact may keep passing scans while the upstream dependency set expands quietly. That is why supply chain programs treat governance and scanning as complementary controls, not alternative ones. Standards such as SLSA and NIST SSDF (SP 800-218) both reinforce the need for disciplined source control and build integrity, while OpenSSF provides broader supply chain guidance and tooling context.
For high-risk pipelines, the most useful operating model is “govern inputs, scan outputs, and compare both against policy.” That keeps release decisions tied to the intended dependency set and the actual artifact state, rather than to either one in isolation.
Risk and Threat Considerations
The main risk is treating scanning as a substitute for upstream governance, or treating governance as proof that the shipped artifact is safe. Attackers, accidental misconfiguration, and dependency drift all exploit the gap between intended inputs and produced outputs. A compromised package source, an over-permissive exception process, or a build that introduces secrets or vulnerable layers can all survive if only one control is used.
Failure mechanism: Unsafe dependencies, hidden secrets, malicious build changes, or misconfigurations enter through a weak upstream gate or emerge after build, then evade detection because the organisation validates only one side of the supply chain.
Impact: The result can be vulnerable releases, poisoned artifacts, secret exposure, provenance loss, emergency rollbacks, and a release process that gives false assurance about what was actually shipped.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply-chain Levels for Software Artifacts | Build provenance and integrity are central to upstream governance and artifact verification. |
| Recommendation — Adopt SLSA-aligned provenance controls to restrict inputs and verify build integrity before release. | ||
| NIST SP 800-53 Rev 5 | CM-8 — System Component Inventory | Component governance depends on knowing and controlling which software components enter the build. |
| SI-2 — Flaw Remediation | Upstream governance and artifact scanning both depend on tracking remediation status for vulnerable components. | |
| SI-7 — Software, Firmware, and Information Integrity | Artifact scanning and supply chain verification both support integrity of released software artifacts. | |
| Recommendation — Maintain authoritative component inventories and block unapproved dependencies from builds. Require timely remediation or documented exception handling for vulnerable components before release. Verify artifact integrity and detect unauthorized changes before deployment. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Application supply chain security includes controlling dependencies and verifying produced software artifacts. |
| Recommendation — Apply secure software controls to vet dependencies and validate release artifacts. | ||
Practitioner Guidance
What to prioritise: Use upstream governance to block known-bad or unapproved components before they enter the build, then use artifact scanning as a release gate on the immutable output. If you must choose where to be stricter first, tighten the control that has the larger blast radius in your pipeline, often the component source or package registry.
What to verify: Confirm that governance rules are tied to an approved source list, remediation threshold, and exception owner, and that scanning is checking the final artifact rather than a transient intermediate state. The strongest evidence is a build record that shows what entered, what was produced, and what was blocked.
Practitioner takeaway: Good supply chain security is not “governance versus scanning”; it is governance deciding what may enter, and scanning proving what actually left.
Related resources from NHI Mgmt Group
- What is the difference between artifact digests and tags in software supply chain security?
- What is the difference between cybersecurity governance and software supply chain security in a CSF 2.0 programme?
- What is the difference between SaaS supply chain security and software supply chain security?
- What is the difference between software supply chain security and application security in agentic pipelines?