Notifications
Clear all
Topic starter
02/08/2026 11:53 am
TL;DR: Third-party code is responsible for 66% of the most dangerous, long-lived security debt, while 62% of applications contain vulnerabilities from open-source libraries, according to Veracode's 2026 State of Software Security Report. Software supply chain risk is now a governance problem, not just a scanning problem, because transitive dependencies and delayed remediation keep exposure alive long after discovery.
NHIMG editorial — based on content published by Veracode: Tackling Third-Party Risks: The Persistent Software Supply Chain Challenge
By the numbers:
- 62% of applications contain vulnerabilities originating from open-source libraries.
- 66% of the most dangerous, long-lived security debt comes from third-party code.
- The half-life of flaws in third-party code is 358 days.
Questions worth separating out
Q: How should security teams reduce the impact of CI/CD supply chain compromise?
A: Treat build systems as privileged identity infrastructure, not just delivery tooling.
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.
Q: What do security teams get wrong about Software Composition Analysis?
A: The common mistake is treating SCA as a one-time scan of source code.
Practitioner guidance
- Map direct and transitive dependencies across all critical applications Use software composition analysis to inventory every package, framework, and nested library, then tie each dependency to an owner and an upgrade path.
- Enforce package provenance before dependency acceptance Require signed or verified package sources, block unexpected publishers, and reject components that do not meet your trust criteria.
- Treat CI/CD secrets and service accounts as high-value identities Rotate pipeline tokens, remove standing privileges, and apply lifecycle ownership to build and release accounts.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step dependency review practices for teams introducing third-party components into software delivery workflows
- Guidance on package firewall and policy-as-code implementation for blocking risky packages before download
- Developer workflow examples showing how SCA, SAST, and DAST can be combined for release decisions
- Measured goals for reducing third-party contribution to critical security debt over a defined time horizon
👉 Read Veracode's analysis of the software supply chain challenge →
Software supply chain risk: what IAM and security teams need to know?
Explore further
02/08/2026 1:01 pm
Third-party code has become a governance problem, not just a scanning problem. The article shows that most organisations are now living with risk they did not author, but still own. That shifts the burden from vulnerability discovery to dependency governance, including provenance, approval, and lifecycle control. In NHI terms, the same pattern appears when organisations trust secrets, tokens, and build identities without enforcing ownership. The practical conclusion is that software supply chain security must be managed as an access and trust discipline, not a periodic code review.
A question worth separating out:
Q: Who is accountable when a vulnerable embedded component ships in production?
A: Accountability usually spans build engineering, product security, and release management because no single team owns the full chain from source revision to deployed image. Governance works only when one function can answer which artefacts were rebuilt, which products consumed them, and which devices still need replacement.
👉 Read our full editorial: Third-party code now drives most critical software security debt
