TL;DR: Software supply chain security tools are now being judged on whether they can discover transitive dependencies, block malicious packages, and prove compliance as security debt rises: 82% of organisations carry security debt and 66% of critical debt comes from third-party code, according to Veracode’s cited report. The practical shift is from detection-only tooling to layered control, developer workflow integration, and auditable remediation evidence.
At a glance
What this is: Veracode argues that software supply chain security tools now need to prove visibility, prevention and remediation evidence, not just detect vulnerabilities after they land.
Why it matters: This matters because dependency sprawl and third-party code now shape risk, so IAM, platform and security teams need controls that can govern software trust chains as well as internal code.
By the numbers:
- 82% of organizations currently carry security debt, an 11% increase year-over-year.
- 60% of organizations are affected by critical security debt, representing a 20% jump from 2025.
- 66% of critical security debt originates from third-party code.
Context
Software supply chain security is the discipline of controlling the libraries, packages, build systems and external components that shape shipped code. In this article, the primary governance gap is not a lack of scanning, but a lack of end-to-end visibility, prevention and proof across dependencies that teams did not author themselves.
The identity angle is real even in a broader application-security discussion because third-party code, build pipelines and package registries rely on trusted non-human identities, tokens and automation paths. When those controls are weak, software trust becomes an identity and access problem as much as a code-quality problem.
Veracode’s guidance is aimed at engineering teams evaluating tooling, so the operational question is whether the controls can keep pace with modern release velocity without creating blind spots or developer bypasses.
Key questions
Q: What breaks when software supply chain tools only detect vulnerabilities after code is installed?
A: Detection-only tooling creates a growing backlog because risky dependencies are already inside the build chain before anyone can block them. That makes remediation slower, increases bypass pressure on developers, and leaves organisations with evidence of problems but weak control over intake. Prevention has to move upstream if teams want to reduce exposure rather than merely report it.
Q: Why do third-party dependencies create such persistent security debt?
A: Third-party dependencies create persistent security debt because organisations often discover flaws faster than they can replace, patch, or retest them. Dependency sprawl also means one vulnerable component can affect many applications at once. Teams need ownership, prioritisation, and lifecycle tracking, not just detection, to reduce the backlog.
Q: How do organisations prove their software supply chain controls are actually working?
A: Use evidence, not assumptions. Track reduction in security debt, remediation time, false positive rates, blocked package events, and audit-ready reports over time. If the tool cannot show measurable change in dependency risk and developer behaviour, it is only producing activity, not assurance.
Q: What is the difference between scanning dependencies and proving software supply chain security?
A: Scanning finds issues, but proof shows that the organisation can trace what was shipped, what was fixed, and when it was fixed. Proof requires SBOMs, remediation records, historical trend data and reporting that stands up to audit or board review. Without that layer, security claims remain difficult to verify.
Technical breakdown
Why transitive dependency visibility is the first control gap
Direct dependencies are the packages developers choose explicitly, but transitive dependencies are pulled in by those packages and often escape normal review. In software supply chains, attackers exploit that hidden layer by poisoning public registries or slipping malicious code into widely used components. Software Bills of Materials help expose that dependency graph, but only if tools can continuously inventory it and tie it to vulnerability intelligence. The practical problem is governance blind spots: teams think they know what they ship, but they often only know the first layer of the stack.
Practical implication: inventory direct and transitive dependencies continuously, not only at release time.
How prevention changes the security model for package ingestion
Detection tells you what is already risky, while prevention tries to stop untrusted packages before they reach the codebase. Package firewalls sit upstream of the repository or package manager and can enforce policy at ingestion, which is materially different from scanning after installation. That shift matters because once a dependency lands in the build chain, it can propagate into multiple services and environments. Prevention is also where identity and trust intersect, because registry access, package signing and automated pipeline permissions determine what can enter the software factory.
Practical implication: place policy enforcement at package ingestion, not only in post-commit scanning.
What proof of remediation actually means in a software supply chain
Proof is the difference between saying a vulnerability was found and showing that it was fixed, tracked and auditable. In mature programmes, evidence includes SBOMs, historical vulnerability trends, remediation records and reporting that maps controls to frameworks such as NIST SSDF. Without that proof layer, leaders can measure scan volume but not risk reduction. This is especially important where third-party code drives most critical debt, because auditors and engineering leaders need assurance that remediation is not just theoretical. The control question is whether the tool can make security improvement visible over time.
Practical implication: require audit-ready evidence of remediation, not just vulnerability counts.
Threat narrative
Attacker objective: The attacker objective is to get malicious or risky code accepted as trusted dependency material so it can propagate through downstream builds and applications.
- Entry occurs through open-source repositories and package ecosystems where attackers target widely used components and libraries.
- Credentialed trust in the build and dependency chain allows malicious or vulnerable packages to flow into applications through transitive dependencies.
- Impact appears when security debt accumulates faster than remediation, increasing the blast radius of third-party code across the application estate.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Software supply chain security is now an identity problem as much as a code problem: build pipelines, registries and package managers depend on machine identities, tokens and automated trust paths. When those identities are unmanaged, security tools can detect risk after the fact but cannot prove who or what was authorised to introduce code. Practitioners should treat dependency governance as part of non-human identity governance.
Visibility without prevention produces security theatre: teams that only scan after code is installed create a backlog that grows faster than remediation capacity. The better model is upstream trust control, where package ingestion is governed before malicious or non-compliant dependencies enter the environment. Security teams should re-evaluate whether their current tooling can actually stop risky software, not merely report on it.
Proof is the missing control layer in software supply chain programmes: audit-ready evidence, SBOMs and remediation history are becoming operational requirements, not compliance extras. That shift matters because leaders need demonstrable reduction in security debt, especially where third-party code drives most critical exposure. Practitioners should make evidence production a first-class control objective.
Third-party code creates supply chain security debt: the article’s figures reinforce that most critical debt now sits outside code teams’ direct authorship. That means responsibility has to move from developer awareness alone to governed intake, prioritised remediation and executive reporting. The practical conclusion is simple: if you cannot see, block and prove, you do not yet have supply chain control.
From our research library:
- Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
- Read next: Third-Party, B2B and Contractor Access Guide
What this signals
Supply chain governance now depends on non-human identity control: package registries, CI pipelines and build services all rely on machine credentials that can expand the blast radius of compromised code. If those identities are not inventoried and governed, visibility tools will keep finding the same problem after trust has already been extended.
A practical next step is to align supply chain controls with the software development lifecycle rather than treating them as a separate scanning layer. NIST SSDF and the OWASP NHI Top 10 are both relevant here because the issue is not only code provenance, but also the trust relationships that let code move from external source to production.
The real programme signal is that detection-only security is losing to delivery velocity. Teams should expect pressure to justify package approval, automated remediation and audit evidence in the same control plane, because the gap between discovery and enforcement is where software supply chain risk compounds.
For practitioners
- Build a complete dependency inventory Map direct and transitive dependencies across every application, then generate SBOMs so you can see what enters the build and what reaches production.
- Enforce upstream package policy Use package firewalls or equivalent controls to block malicious or non-compliant packages before they are installed in developer workflows or CI pipelines.
- Tie remediation to risk and evidence Prioritise exploitable third-party issues, then track fixes with historical vulnerability records and remediation evidence that can support audit and executive review.
- Measure developer friction as a security signal Test scanning performance, false positive rates and workflow fit in real projects so security controls do not become easy to bypass under delivery pressure.
Key takeaways
- Third-party code now drives a disproportionate share of critical security debt, so software supply chain control must extend beyond first-party code review.
- Visibility, prevention and proof are separate control layers, and tools that only deliver one of them leave a governance gap.
- Teams need auditable evidence of dependency inventory, package blocking and remediation progress if they want to reduce supply chain risk rather than measure it.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Supply chain tooling here is about protecting code and build artifacts before they reach production. |
| PR.AA-05 — Access Permissions, Entitlements and Authorizations | Package registries and CI systems rely on machine permissions that must be governed tightly. | |
| Recommendation — Protect software artifacts and dependency channels with controls that prevent untrusted components from entering production. Apply least-privilege authorization to registries, pipelines and package ingestion paths. | ||
| MITRE ATT&CK | TA0002;TA0006 — Execution; Credential Access | The threat pattern involves attackers using trusted build paths and package ecosystems to get code accepted. |
| Recommendation — Map package-abuse scenarios to execution and credential-access tactics in your detection and response logic. | ||
| NIST SP 800-53 Rev 5 | SA-10 — Developer Configuration Management | The article emphasises controlled dependency handling, automated gates and remediation evidence in software delivery. |
| Recommendation — Use configuration management controls to govern dependency changes, approval gates and secure build evidence. | ||
Key terms
- Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
- Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
- Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
- Package Firewall: A package firewall is a control that blocks or screens software packages before they enter a development or build environment. It is used to prevent vulnerable, malicious, or non-compliant dependencies from reaching downstream pipelines where later detection may be too late to reduce risk.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore the NHI Foundation Level course if your programme needs stronger governance over machine identities, secrets and delegated access.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org