Topic starter
02/08/2026 12:06 pm
TL;DR: Third-party code now accounts for 70% of critical security debt, while breaches exploiting vulnerabilities in third-party code rose 180% in 2024, according to Veracode’s source article and the 2024 Verizon Data Breach Investigations Report. DevSecOps only works when supply chain controls, exploitability checks, and automated remediation are built into the pipeline, not layered on afterward.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “How to Align Your DevSecOps Framework with Software Supply Chain Security”.
By the numbers:
- 70% of critical security debt comes from third-party code.
- Breachs exploiting vulnerabilities in third-party code increased by 180% in 2024.
Key questions
Q: What happens when software supply chain security is treated as an afterthought in DevOps?
A: When supply chain security is bolted on late, teams usually create blind spots in the very stages attackers target most.
Q: Why do third-party dependencies create outsized risk in software delivery pipelines?
A: Third-party dependencies expand the attack surface because they can be compromised, abandoned, or replaced with malicious packages.
Q: What do security teams get wrong about dependency scanning?
A: They often assume a clean manifest means a clean environment.
Practitioner guidance
- Embed package intake controls into CI/CD Block non-compliant or suspicious packages before they enter builds by applying policy at package download time and during dependency resolution.
- Add reachability analysis to SCA results Prioritise only the vulnerabilities that are actually invoked by application code so developers do not spend cycles on non-exploitable findings.
- Automate SBOM generation on every build Generate an up-to-date software bill of materials as part of the pipeline so component inventory supports audit, release, and incident workflows.
Bottom line: Third-party and open-source code now drive a large share of application risk, so DevSecOps controls must extend beyond first-party code.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:10 pm
Third-party code is now a governance problem, not just a development convenience. Once organisations rely on external packages and transitive dependencies, the security boundary shifts from code authorship to dependency governance. The real question becomes whether teams can prove what entered the build, why it was allowed, and whether it was actually exploitable. Practitioners should treat dependency intake as a controlled identity-and-policy decision for software supply chains.
A few things that frame the scale:
- 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.
A question worth separating out:
Q: How should teams implement software supply chain security across build pipelines?
A: Start by inventorying dependencies, then add provenance checks, secret governance, and continuous remediation evidence at the pipeline level. The goal is to prevent untrusted code and unowned automation from entering production. Teams should measure success by reduced exposure age, fewer risky dependencies, and better traceability across releases.
👉 Read our full editorial: DevSecOps supply chain security exposes the third-party code gap