Notifications
Clear all
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.
NHIMG editorial — 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:
- Today’s applications increasingly rely on external components, with over 70-90% of codebases made up of open-source or third-party libraries.
Questions worth separating out
Q: How should security teams govern software supply chain risk when CI/CD identities can publish code?
A: Security teams should treat CI/CD accounts, signing keys, and release tokens as high-risk identities with least privilege, scoped access, and rotation requirements.
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 do teams get wrong about software bills of materials?
A: They often treat SBOMs as a complete security control when they are mainly a visibility and audit tool.
Practitioner guidance
- Enforce package admission controls Block unapproved or risky packages before they enter CI/CD, and require explicit policy exceptions for new registries, maintainers, or package families.
- Inventory transitive dependencies continuously Scan beyond direct packages and maintain a live dependency tree for every application so hidden packages, nested libraries, and abandoned components can be identified quickly.
- Scope pipeline non-human identities tightly Restrict CI runners, signing services, and deployment tokens to the minimum permissions needed, then rotate credentials and remove standing access where possible.
What's in the full article
Veracode's full article covers the operational detail this post intentionally leaves for the source:
- Package firewall and SCA workflow details for blocking risky dependencies before they enter CI/CD
- Step-by-step guidance on building and maintaining SBOM-driven compliance evidence
- Examples of policy settings for outdated, dormant, or non-compliant packages
- Implementation notes on embedding security checks directly into developer workflows
👉 Read Veracode's analysis of software supply chain risks in 2025 →
Software supply chain risk: are your controls keeping up?
Explore further
02/08/2026 1:26 pm
Software supply chain governance has become dependency provenance governance. The central problem is no longer just whether code is scanned, but whether every package, transitive dependency, and pipeline credential is trusted at the point of admission. That puts provenance, policy, and ownership ahead of raw vulnerability counts. Practitioners should treat the build chain as a governed trust boundary, not a passive delivery mechanism.
A question worth separating out:
Q: What should organisations do when a critical open-source package is compromised?
A: Contain exposure by blocking the package at ingestion, identify all affected applications through dependency and artifact inventory, and verify whether build or deploy identities could have propagated the risk further. Then prioritise remediation based on runtime exposure, not just scan severity.
👉 Read our full editorial: Software supply chain risk is now a governance problem for 2025
