Software supply chain risk is now a governance problem for 2025

At a glance

What this is: This is an analysis of why software supply chain security has become a governance challenge as open-source and third-party dependencies expand attack surface and compliance burden.

Why it matters: It matters because identity, access, and provenance controls increasingly determine whether pipelines, packages, and build systems can be trusted across application and platform teams.

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.
• 2025 is $4.4 million.

👉 Read Veracode's analysis of software supply chain risks in 2025

Context

Software supply chain security is about controlling the code, packages, dependencies, and build inputs that shape what reaches production. In 2025, the primary issue is not just vulnerable code, but the governance gap created when organisations cannot reliably verify provenance, licensing, dependency depth, and update discipline across increasingly complex pipelines.

The identity connection is real where build systems, package registries, service accounts, tokens, and CI/CD permissions decide what can be introduced into software. That makes software supply chain risk partly an access-control problem, especially when third-party components and automation can bypass the scrutiny applied to human change requests.

Key questions

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. The goal is to make one compromised credential unable to sign, publish, and deploy in the same chain. That means separate duties, short-lived access where possible, and logging that ties every build action to a specific identity.

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. That means a package several layers deep can introduce a known CVE, a malicious update path, or a compliance issue without any direct code change by the team.

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. An SBOM shows what is present, but it does not enforce package admission, scope pipeline access, or ensure that vulnerable components are removed quickly.

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.

Technical breakdown

Why transitive dependencies create hidden control gaps

A transitive dependency is a package your application does not call directly, but one that is pulled in by another library you do use. That matters because security teams often scan first-order dependencies while the real risk sits several layers deep in the tree. When a lower-tier package is compromised, trust propagates upward through ordinary build processes. This is less a code-quality issue than a provenance and dependency governance problem, because the control point is not only the package itself but the chain of trust that admits it.

Practical implication: map the full dependency tree, not just direct packages, before relying on scan results.

How malicious packages enter trusted pipelines

Malicious packages usually succeed by looking ordinary enough to pass developer workflow friction. Attackers exploit naming similarities, rapid dependency updates, or weak review of newly introduced packages, then rely on automated installs to spread the risk. Once a package lands in the pipeline, downstream build and deploy systems amplify the impact. In identity terms, the package manager, CI runner, and deployment service account become the enforcement points, because they determine whether untrusted code can move from registry to runtime without a meaningful trust check.

Practical implication: treat package admission as a policy decision, not a developer convenience function.

Why SBOMs help, but do not close the supply chain problem

A software bill of materials lists the components and dependencies in an application, which improves visibility and auditability. But an SBOM is a record, not a control. It tells you what is present, not whether the package is trustworthy, whether credentials used in the pipeline are tightly scoped, or whether a dependency was introduced through a poorly governed automation path. In practice, SBOMs work best when paired with policy enforcement, continuous scanning, and clear ownership for remediation.

Practical implication: use SBOMs for visibility, then add admission controls and remediation ownership to make them operational.

Threat narrative

Attacker objective: The attacker aims to use trusted software distribution paths to inject malicious code or dependencies into production systems at scale.

1. Entry occurs when a malicious or compromised package is introduced into an open-source ecosystem or a transitive dependency chain.
2. Escalation happens when automated build and deployment systems trust the package and propagate it into applications, environments, or downstream releases.
3. Impact follows when the compromised component creates code execution, data exposure, or compliance failure across multiple software estates.

NHI Mgmt Group analysis

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.

Identity controls now sit inside the software supply chain. Package registries, CI runners, signing services, and deployment jobs are all non-human identities whose permissions determine what can enter production. If those identities are over-scoped or poorly rotated, the security model fails before a scanner ever runs. Teams need to govern service accounts, tokens, and automation permissions with the same discipline they apply to privileged human access.

Transitive dependency sprawl creates a hidden security debt. The more layers between developer intent and production artifact, the more likely it is that teams will miss where trust was introduced and where it should have been revoked. That is why control ownership must extend from procurement and engineering into runtime governance. The practical conclusion is that dependency sprawl is a lifecycle problem, not a point-in-time review problem.

Supply chain assurance now depends on enforcement at admission points. Scanning after packages are accepted is too late to prevent policy violations from entering build systems. Organisations need a named concept for this control gap: package admission drift, meaning the widening gap between what policy says should be allowed and what automation actually admits. Practitioners should close that gap with enforceable rules at ingestion time.

What this signals

Package admission drift: as software delivery becomes more automated, the key governance question is whether policy is enforced before a dependency reaches the build chain or only discovered after the fact. Teams that already manage service accounts, signing keys, and CI tokens as non-human identities will have a clearer path to controlling software provenance.

Supply chain assurance is moving from code scanning toward identity-aware control of build systems, because the identities that install, sign, and deploy software now shape the trust boundary as much as developers do. Practitioners should prepare for tighter coupling between SBOM evidence, pipeline permissioning, and third-party risk review, with DORA-style accountability making that linkage harder to ignore.

For practitioners

• 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. Use approval workflows for high-risk dependencies and tie them to build-time enforcement.
• 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.
• Pair SBOMs with remediation ownership Assign accountable owners for each critical component, define escalation paths for vulnerable or unmaintained packages, and use SBOMs as the visibility layer for those decisions.
• Review supply chain controls against DORA obligations Map reporting, resilience, and third-party oversight requirements to your software delivery process so compliance evidence is generated as part of normal operations.

Key takeaways

• Software supply chain security is now a trust-governance problem, not just a vulnerability-scanning problem.
• Transitive dependencies and pipeline identities expand the attack surface in ways that static reviews cannot fully see.
• The practical response is admission control, scoped automation, and ownership of every high-risk dependency.

Key terms

• Transitive Dependency: A transitive dependency is a package brought in by another package rather than chosen directly by the development team. It matters because hidden packages can carry vulnerabilities, licensing constraints, or malicious code that ordinary top-level reviews may miss.
• Software Bill of Materials: A software bill of materials is an inventory of the components and dependencies used in an application. It helps teams identify what they shipped, but it becomes most useful when paired with source verification, signature checks, and policy enforcement for third-party code.
• Package Admission: Package admission is the decision point where tooling or policy determines whether a dependency is allowed into a build or deployment workflow. In mature programmes, this is where trust is enforced, exceptions are recorded, and automation is constrained by policy.
• Supply Chain Provenance: Supply chain provenance is the ability to trace where software components came from, how they were built, and which identities or systems introduced them. It is a governance requirement because trust depends on knowing not only what code exists, but how it arrived.

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

👉 The full Veracode article covers dependency controls, compliance pressure, and practical mitigation steps.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It is designed for practitioners who need to govern automation, privileged access, and operational trust across modern security programmes.