Software supply chain risk is now a governance problem for 2025

At a glance

What this is: This article argues that software supply chain risk is no longer just a scanning problem, but a governance problem shaped by third-party code, transitive dependencies, malicious packages, and compliance pressure.

Why it matters: It matters to IAM and security teams because supply chain governance now intersects with third-party access, build integrity, and the control boundaries that determine what can enter production.

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.

Context

Software supply chain risk starts with a simple reality: modern applications are assembled from code you did not write and often do not fully control. That creates governance gaps across provenance, dependency visibility, and change control, especially when third-party components arrive through automated build pipelines rather than manual review.

In identity terms, the article sits at the boundary between software governance and trust governance. Third-party code, package registries, CI/CD systems, and SBOM processes all shape who or what is authorised to introduce code into production, which is why build integrity now belongs in the same conversation as access control and lifecycle oversight.

The article’s core claim is typical of 2025 development environments rather than an edge case. Most organisations now inherit the same control problem: they can scan dependencies, but they still struggle to govern the full chain of trust that those dependencies create.

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. That weakens trust in the whole release process. The practical consequence is asymmetric risk, where attackers only need to find one unprotected route to get a compromised artefact into production.

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 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. If teams can only identify known CVEs but cannot assess package provenance, build trust, or dependency risk at scale, their controls are missing the real attack surface.

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.

Technical breakdown

Why transitive dependencies create hidden governance debt

A transitive dependency is a package that your code consumes indirectly through another package. That matters because security teams may believe they have reviewed the dependency they chose, while the true risk sits several layers deeper in the chain. Each layer adds provenance uncertainty, version drift, and a wider blast radius when a maintainer is compromised or a malicious update lands. In practice, the control failure is not just missing scan coverage. It is incomplete ownership of the full dependency tree across build, release, and runtime.

Practical implication: Practitioners need dependency-tree visibility that extends beyond direct packages to the full transitive chain.

How malicious packages bypass trust assumptions in CI/CD

Malicious packages exploit the fact that package registries are treated as trusted input channels. Attackers can publish lookalike dependencies, inject backdoors into legitimate packages, or target maintainer accounts so that malicious code appears as an ordinary update. Once a build pipeline ingests that package, the problem becomes one of inherited trust, not just code inspection. This is why package filtering, provenance checks, and release-policy controls matter. The main architectural issue is that CI/CD often optimises for speed while assuming upstream integrity it has not verified.

Practical implication: Teams should treat package ingestion as a control point, not as a passive source of trusted software.

Why SBOMs shift supply chain risk from discovery to accountability

An SBOM, or software bill of materials, lists the components that make up an application. It does not remove risk on its own, but it makes dependency ownership and disclosure enforceable in a way that ad hoc scanning does not. That matters under regimes such as DORA because organisations increasingly need to prove they know what is in their software and can trace it back when something breaks. The control question therefore changes from "Can we find vulnerabilities?" to "Can we account for every dependency and document its exposure path?"

Practical implication: Use SBOMs as an accountability layer tied to remediation, not just as an inventory artefact.

Threat narrative

Attacker objective: The attacker aims to insert untrusted code into trusted build paths so the compromise spreads through downstream applications and business processes.

1. Entry occurs when a malicious package is published to a repository such as npm or PyPI, or when a legitimate dependency is tampered with upstream.
2. Credential access or trust abuse follows when the build pipeline automatically pulls that package in without strong provenance or policy checks.
3. Escalation happens as transitive dependencies propagate the compromise into multiple applications, creating a wider blast radius than the initial package suggests.
4. Impact is realised through backdoored code, data exposure, release delays, regulatory failure, or reputation loss once compromised software reaches production.

Breaches seen in the wild

• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.
• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Transitive dependency visibility is the named control gap this article exposes. Teams often think in terms of direct package review, but the compromised component is frequently several layers removed from what developers selected. That creates a governance blind spot where ownership, provenance, and remediation responsibility blur. Practitioners need a control model that traces risk through the full dependency tree.

SBOMs create accountability, but only when paired with enforcement. A bill of materials improves traceability, yet it does not prevent malicious packages, stale dependencies, or policy bypass. The practical lesson is that disclosure and control are not the same thing. Practitioners should use SBOMs to support enforcement, exception handling, and audit readiness, not as a substitute for secure intake.

Supply chain security is converging with compliance because regulators now care about evidence, not reassurance. DORA and similar requirements turn dependency governance into a measurable obligation, especially where third-party code can affect operational resilience. That shifts supply chain security out of the developer convenience category and into board-level accountability. Practitioners should expect more scrutiny of build provenance, reporting, and supplier assurance.

Malicious package ingestion is a form of trusted-path abuse. The pattern is familiar across identity security: when an upstream channel is assumed safe, the attacker targets the trust boundary instead of the obvious endpoint. That means package registries, CI runners, and release workflows need controls that verify source, intent, and scope before code is allowed to propagate. Practitioners should treat package trust as a policy problem.

From our research library:

• 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.
• Read next: AI Supply Chain Security and AI-BOM Guide

What this signals

Dependency governance is becoming part of identity governance because build pipelines now act like privileged actors. When external code, package registries, and automation tokens can introduce software into production, the control problem looks less like scanning and more like access governance. Practitioners should treat the software supply chain as an identity-bearing trust path that needs ownership, policy, and review.

Supply chain risk will keep expanding until teams can prove provenance end to end. The article’s 70-90% codebase dependence figure shows why organisations cannot rely on direct-package review alone. What matters now is whether every dependency, transitive or direct, can be traced, authorised, and challenged before it reaches release. According to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, raising concerns about supply chain security.

For practitioners

• 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.
• Review third-party integration trust Assess whether external services, OAuth grants, and automation tokens can propagate risk into connected environments without lifecycle controls.

Key takeaways

• Software supply chain risk now spans provenance, dependency depth, package intake, and compliance evidence, not just vulnerability scanning.
• The article’s numbers show why governance has to extend beyond direct dependencies: most codebases rely heavily on external libraries, and breach costs remain material.
• Practitioners need controls that connect dependency visibility, SBOM accountability, package policy, and third-party trust review into one operating model.

Key terms

• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Transitive Dependency: A transitive dependency is a package that your software uses indirectly through another library rather than calling it directly. These dependencies often hide in Java estates, which makes visibility and runtime validation necessary to understand what code is actually present and active.
• 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.
• Build provenance: Build provenance is the evidence chain showing where a software artefact came from, how it was assembled, and which identities and keys were used. It is essential when teams need to prove that an embedded release was produced from trusted source and controlled inputs.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course covers NHI governance, workload identity, and secrets management within an accredited programme built for practitioners. It helps security and identity teams connect trust, lifecycle, and control decisions across modern environments.