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.
Editorial analysis by NHI Mgmt Group, 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.
- Third-party code is responsible for 66% of the most dangerous, long-lived security debt.
- The half-life of flaws in third-party code is 358 days.
Key questions
Q: What breaks when third-party code is not governed before it enters the build pipeline?
A: The control that fails first is trust at intake.
Q: Why do third-party library vulnerabilities create longer security debt than first-party flaws?
A: Third-party flaws often depend on upstream maintainer fixes, compatible version releases, regression testing, and coordinated deployment across many applications.
Q: How can security teams measure whether supply chain controls are actually working?
A: Look for reduced use of long-lived publishing tokens, fewer workflows with broad secrets access, lower dependency auto-update exposure, and faster revocation after compromise.
Practitioner guidance
- Map direct and transitive dependencies Build a complete inventory of open-source and third-party components across applications, including nested libraries that your primary scanning tools may miss.
- Gate package intake before build-time execution Apply repository and package admission controls so that public packages are validated for provenance, policy compliance, and naming anomalies before developers or CI runners can fetch them.
- Track third-party vulnerability ageing as a governance metric Measure how long vulnerable dependencies remain unresolved, then escalate aged findings through release, owner, and exception workflows rather than leaving them in scan queues.
Bottom line: Third-party code now represents a durable governance problem because exposure can persist long after the vulnerable component is discovered.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:01 pm
Third-party code is now a governance asset, not just a developer convenience. The article shows that dependency choice directly shapes residual security debt, which means software supply chain governance has to sit alongside application security, procurement, and release management. When 66% of the most dangerous long-lived debt comes from third-party code, the issue is no longer isolated defect management. Practitioners should treat dependency approval, ownership, and lifecycle control as a formal control plane.
A few things that frame the scale:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
A question worth separating out:
Q: What is the difference between software composition analysis and an SBOM in open source security?
A: Software composition analysis is an active control that scans code and builds to find open source components, versions, and known vulnerabilities. An SBOM is the documented inventory of those components, including direct and transitive dependencies, versions, licenses, and update status. In practice, SCA discovers risk while the SBOM preserves the authoritative record.
👉 Read our full editorial: Third-party code now drives most critical software security debt