Supply chain failures describe how risk enters through dependencies, build tooling, or update channels. Integrity failures describe whether the application verifies what it receives, such as unsigned code, unvetted plugins, or tampered data.
How to tell whether the failure sits in the supply chain or in integrity checks
The distinction starts with where the weakness exists. Supply chain failures are upstream exposure problems: you trusted a dependency, build step, package source, or update path that was already unsafe. Software integrity failures are local verification problems: the application accepted code, plugins, artifacts, or data without proving they were authentic, expected, or unmodified.
That difference matters because the remediation owner and control set are not the same. Supply chain issues usually point to provenance, dependency governance, build hygiene, and release trust. Integrity issues point to verification gaps inside the application, updater, loader, or deployment path. Teams that blur the two often fix the wrong layer and leave the same failure mode intact.
A practical way to separate them is to ask, “Did risk enter before we received the software, or did we fail to check what we received?” If the answer is before, the problem is usually supply chain related. If the answer is during acceptance, loading, installation, or execution, the problem is usually integrity related. A compromised upstream package can be both, but the analysis should still distinguish ingress from verification.
What belongs in the supply chain bucket
Supply chain failures involve dependence on third parties or pipeline stages that can be subverted before the product reaches you. That includes malicious packages, poisoned build artifacts, compromised maintainer accounts, tainted update channels, and unsafe CI/CD or repository access. The control question is whether you can trust the source and the path that delivered the software, not just whether the runtime accepted it.
Good supply chain analysis also looks at transitive risk. A dependency may be legitimate, but if its maintainer token, build runner, signing key, or publishing workflow is compromised, your own environment inherits that exposure. The SLSA model is useful here because it frames build provenance and artifact integrity as upstream properties that need explicit assurance.
For teams managing packages, plugins, or internal tooling, this is where dependency review, pinned versions, provenance checks, and trusted build processes belong. The OpenSSF ecosystem is relevant because it focuses on practical open source supply chain security, including guidance that helps teams reduce trust in opaque upstream inputs.
What belongs in the software integrity bucket
Integrity failures are about whether the application verifies what it receives before acting on it. Examples include unsigned code being loaded, unvetted plugins being executed, tampered configuration being accepted, or data being consumed without validation. The issue is not necessarily that the source was malicious, but that the receiving system lacked a strong enough authenticity or tamper check.
This distinction becomes sharp in runtime paths such as plugin loading, auto-update mechanisms, script execution, and dynamic content ingestion. If a product accepts an update without verifying a signature or hash, that is an integrity failure even if the update channel itself was normal. If the application permits untrusted extensions to run with broad privileges, the integrity weakness is in the acceptance rule, not only in the upstream package source.
NIST’s Secure Software Development Framework is useful because it ties secure build and release practices to integrity expectations across the software lifecycle. Teams can use it to ask whether their validation, release, and update checks are strong enough for the level of trust the software requires.
Risk and Threat Considerations
Confusing these categories creates a common blind spot: teams harden upstream sourcing but still let tampered content run, or they add local validation while continuing to trust a compromised dependency pipeline. Adversaries exploit that gap by choosing the easiest trust boundary to break, whether that is maintainer access, package publication, update infrastructure, or weak signature and content validation.
Failure mechanism: The failure occurs when organisations treat provenance and verification as interchangeable, so an upstream compromise can still be executed locally, or a local validation gap can still accept tainted content from a trusted source.
Impact: The result is persistent exposure to malicious code, poisoned dependencies, and undetected tampering, often with broader blast radius than the original defect because the same trust path is reused across releases and deployments.
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 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 failures. |
| Recommendation — Adopt SLSA-aligned provenance checks for build outputs and dependency inputs. | ||
| NIST SP 800-53 Rev 5 | SI-7 — Software, Firmware, and Information Integrity | Integrity failures hinge on verifying software and content before execution or installation. |
| CM-5 — Access Restrictions for Change | Supply chain compromise often enters through unauthorized or unreviewed changes. | |
| SA-12 — Supply Chain Protection | Directly addresses third-party and upstream software supply chain risk. | |
| Recommendation — Implement SI-7 checks for trusted updates, code validation, and tamper detection. Restrict who can publish, modify, and approve software changes and releases. Apply SA-12 to assess suppliers, provenance, and component trust before adoption. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Application-side integrity checks depend on secure design and trustworthy handling of inputs and components. |
| Recommendation — Build explicit verification points into update, plugin, and artifact handling paths. | ||
Practitioner Guidance
What to prioritise: Split incidents into two questions during triage, where did the risk enter, and where did acceptance fail. That makes ownership clearer, because supply chain remediation usually sits with release engineering or dependency governance, while integrity remediation usually sits with application or platform engineering.
What to verify: Confirm whether the artifact was signed, whether the signature was checked, whether the dependency source was pinned, and whether the loader or updater rejected unexpected content. If any one of those checks is missing, you have an integrity problem even when the source looked trustworthy.
Decision rule: If a control only proves origin, do not treat it as sufficient integrity protection. If a control only validates content after retrieval, do not treat it as sufficient supply chain protection.
Practitioner takeaway: The cleanest separation is provenance versus acceptance, upstream trust versus local verification. Teams should map each failure to the boundary that actually broke, otherwise they will improve the wrong control and leave the real attack path open.