Notifications
Clear all
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.
NHIMG editorial — based on content published by Veracode: How to Align Your DevSecOps Framework with Software Supply Chain Security
By the numbers:
- Breach incidents exploiting vulnerabilities in third-party code increased by 180% in 2024.
- 70% of critical security debt comes from third-party code.
Questions worth separating out
Q: What breaks when software supply chain controls are not built into DevSecOps pipelines?
A: When supply chain controls sit outside the pipeline, teams lose visibility into what actually enters builds, and malicious or vulnerable dependencies can pass through as trusted inputs.
Q: Why do third-party dependencies create more supply chain risk than first-party code?
A: Third-party dependencies expand trust beyond the team’s direct control.
Q: How do teams know if a vulnerability is truly exploitable?
A: They validate it in the live environment using safe testing that shows whether an attacker can reach the condition, trigger it, and move beyond it.
Practitioner guidance
- Gate package intake before code reaches the pipeline Block known-malicious or non-compliant packages at the point of download, and maintain policy lists for approved registries and package sources.
- Prioritise reachable vulnerabilities over library-level alerts Use vulnerable-methods detection or equivalent reachability analysis to identify which CVEs are actually invoked by application code.
- Automate SBOM generation at build time Generate the SBOM in the CI/CD pipeline so every release has a current component inventory.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step guidance for embedding software composition analysis directly into IDE and CI/CD workflows
- Practical examples of package firewall policy enforcement for malicious or non-compliant dependencies
- How vulnerable-methods detection changes remediation prioritisation in real development pipelines
- SBOM integration points for release governance and compliance evidence
👉 Read Veracode's guide to aligning DevSecOps with software supply chain security →
Software supply chain security in DevSecOps: what teams need to change?
Explore further
02/08/2026 1:10 pm
Third-party code has become the dominant control gap in DevSecOps. The article’s 70% critical debt figure shows that many organisations are still optimising first-party code while leaving the larger exposure surface under-governed. That is not a scanning problem alone. It is a supply chain governance problem, and the practitioners who own it need dependency policy, exception handling, and release gating that extend beyond the application repository.
A question worth separating out:
Q: Should organisations treat SBOMs as a compliance artifact or an operational control?
A: They should treat SBOMs as an operational control that feeds policy, release gating, and remediation. A static inventory helps, but it does not reduce risk on its own. The value appears when the SBOM is current, machine-readable, and linked to the decisions that approve or block delivery.
👉 Read our full editorial: DevSecOps supply chain security exposes the third-party code gap
