Topic starter
02/08/2026 12:27 pm
TL;DR: Third-party libraries now make up 70-90% of modern codebases, while transitive dependencies, malicious packages, SBOM obligations, and DORA-style compliance pressures turn software supply chain exposure into a persistent governance problem, according to Veracode. The operational gap is no longer whether teams can scan code, but whether they can continuously govern what enters, persists, and propagates through the build chain.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “The Hidden Risks in Your Software Supply Chain: What You Need to Know in 2025 and Beyond”.
By the numbers:
- 70-90% of modern codebases are made up of open-source or third-party libraries.
- The average cost of a data breach in 2025 is $4.4 million.
- DORA became active since January 2025.
Key questions
Q: What breaks when software supply chain controls are only partially automated?
A: Partial automation creates inconsistent enforcement, which means some builds are protected while others slip through manual exceptions or forgotten paths.
Q: Why do transitive dependencies create more risk than teams expect?
A: Transitive dependencies are often invisible to the developer who triggered them, but they still become part of the shipped application.
Q: What are the signs that software supply chain controls are failing in practice?
A: Common warning signs include overreliance on vulnerability lists, weak visibility into third party dependencies, limited scrutiny of developer tooling, and no practical way to audit the full software estate.
Practitioner guidance
- Map the full dependency tree Inventory direct and transitive dependencies for every internet-facing and regulated application, then tie each component to an owner, source, and update path.
- Block risky packages before build ingestion Apply package allowlisting, reputation checks, and provenance validation so untrusted packages are stopped before they enter CI/CD pipelines.
- Bind SBOMs to remediation workflows Use SBOM outputs to drive triage, exception handling, and patch prioritisation rather than treating them as static compliance artefacts.
Bottom line: Software supply chain risk now spans provenance, dependency depth, package intake, and compliance evidence, not just vulnerability scanning.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:26 pm
Software supply chain governance is now an identity and trust problem, not just a developer tooling problem. The article is right to frame dependency sprawl as a governance issue because modern build systems ingest external code through trusted automation. Once packages, tokens, and CI/CD permissions converge, the real question becomes who can introduce software into the environment and under what controls. Practitioners should govern the chain of trust, not just scan the code.
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.
- 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: Who is accountable when a third-party package compromise affects production data?
A: Accountability usually spans software supply chain owners, runtime platform owners, and the business team that accepted the dependency risk. If the package could execute with production access, then the control failure is not only in the repository, but also in the review of what that dependency was allowed to do.
👉 Read our full editorial: Software supply chain risk is now a governance problem for 2025