Open source supply chain risk is now an SDLC governance problem

At a glance

What this is: Open source supply chain security is now framed as an SDLC governance problem because third-party code, malicious packages, AI-generated dependencies, and IaC reuse can all expand exposure.

Why it matters: Engineering and security teams need controls that govern dependency visibility, policy enforcement, and build-chain trust, not just post-build scanning.

By the numbers:

• 70% of critical security debt originates from third-party code.

Context

Open source supply chain security is the control problem that appears when software teams depend on code they did not author, package, or fully observe. The risk is not limited to known vulnerabilities in libraries. It also includes malicious packages, dependency confusion, typosquatting, repo-jacking, transitive dependency blind spots, and reused IaC patterns that spread insecure defaults.

For IAM and NHI practitioners, the identity angle is real but indirect: package registries, CI/CD systems, signing workflows, and developer automation all rely on machine credentials, tokens, and trust decisions. That means software supply chain governance now touches non-human identity lifecycle, secrets exposure, and policy enforcement as much as it touches code scanning.

Key questions

Q: What breaks when open-source software and cloud tools are deployed without strong supply chain controls?

A: Without strong supply chain controls, trusted images, libraries, and management tools can become delivery mechanisms for backdoors, miners, or remote code execution. Teams lose confidence in what is running, what has been modified, and which workloads are exposed. The practical failure is that a single compromised component can affect many downstream systems across containers, orchestration layers, and shared platforms.

Q: Why do malicious packages and dependency confusion still work in mature engineering environments?

A: These attacks succeed because trust is often granted too early. Package names can be mistyped, internal names can be matched by public packages, and newly published malicious code may execute during install before scanners react. Human workflow errors, registry defaults, and rapid release cycles create openings that traditional post-install scanning cannot reliably close.

Q: How do security teams know whether SBOM and policy controls are working?

A: They should see complete component inventory, consistent policy enforcement in CI/CD, and fast tracing from a released artefact back to its dependencies. If teams still cannot answer what entered the build, where it came from, or why it was approved, the controls are not yet effective.

Q: What is the difference between package scanning and package provenance controls?

A: Scanning evaluates what is already present in a package, while provenance controls decide whether the package should be trusted and admitted in the first place. Scanning is useful for detection, but provenance controls reduce the chance that a malicious or hijacked package ever enters the build pipeline.

Technical breakdown

Why transitive dependencies create a hidden trust chain

Modern applications rarely depend only on first-order libraries. Each package can bring in a deep tree of transitive dependencies, which makes the effective trust boundary much larger than the dependency manifest suggests. That hidden chain is where attackers exploit blind spots, especially when teams assume a package is safe because it is popular or because a scanner has not yet flagged it. In practice, governance must cover provenance, version integrity, and the source of every component that reaches the build pipeline.

Practical implication: Map direct and transitive dependencies continuously, not only at release time.

How malicious packages and typosquatting enter pipelines

Package ecosystems are vulnerable because build tooling often trusts repository names, search results, and metadata before it evaluates behavioural risk. Typosquatting abuses lookalike names, while repo-jacking and dependency confusion redirect builds to attacker-controlled packages. AI coding tools add a new twist when they suggest package names that do not exist or that resemble legitimate ones, creating a route for accidental installation of malicious code. The technical issue is trust without verification at the point of consumption.

Practical implication: Add pre-install package controls that inspect names, provenance, and policy before anything reaches the build.

Why SBOMs and policy as code matter in the SDLC

Software bills of materials and policy-as-code are governance mechanisms, not paperwork. SBOMs provide inventory, making it possible to trace what is actually in use, while policy as code turns license, provenance, and security rules into automated enforcement inside pipelines. Together they shift supply chain security from after-the-fact review to control at ingestion and release. That matters because manual review cannot keep pace with dependency churn, especially when teams ship frequently and reuse IaC templates across environments.

Practical implication: Automate SBOM generation and enforce dependency policy inside CI/CD, not as a separate review step.

Threat narrative

Attacker objective: The attacker wants to turn trusted software distribution paths into a scalable route for code execution, secret theft, or widespread downstream compromise.

1. Entry occurs when an attacker publishes a malicious or lookalike open-source package and engineers or automation pull it into the dependency chain.
2. Credential access can follow when the compromised package or build step steals tokens, secrets, or registry credentials from the development environment.
3. Impact occurs when the malicious dependency propagates into builds, container images, or production releases, creating broad compromise across downstream systems.

Breaches seen in the wild

• SpotBugs token leak 2025: A SpotBugs maintainer's PAT, stolen via a pull_request_target workflow in 2024, started the reviewdog and tj-actions supply chain attack.
• PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.

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

Open source supply chain risk is now an SDLC governance problem, not a narrow application security task. The article reflects a broader reality: the control surface now includes dependency intake, registry trust, pipeline policy, and release governance. Once third-party code is treated as an operational input rather than a passive component, security ownership shifts left into engineering process and identity control.

Package trust has become a machine identity issue as much as a code issue. Build systems, registries, and automation paths depend on tokens, service accounts, and delegated access that can be abused when package provenance is weak. That makes NHI governance relevant here, because the compromise path often runs through credentials and permissions rather than the source code itself.

AI-assisted development expands supply chain exposure by increasing the chance of false package trust. Hallucinated dependencies and generated snippets can push developers toward unverified packages, which turns assistant output into a governance input. The right response is not to ban AI tooling, but to enforce consumption controls that verify package existence, provenance, and policy before installation.

Provenance blind spots: the core failure mode is assuming that package popularity, repository reputation, or scanner coverage equals trust. That assumption fails in dependency confusion, repo-jacking, and malicious package campaigns because the build pipeline often consumes artifacts before any meaningful validation. Practitioners should treat provenance as a control requirement, not an optional signal.

Compliance pressure is now reinforcing the same governance pattern. DORA and SBOM expectations are pushing teams toward auditable inventory, repeatable policy, and traceable component decisions. The practical conclusion is that software supply chain security is no longer separable from engineering governance, especially in regulated environments.

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: Guide to the Secret Sprawl Challenge

What this signals

Software supply chain governance is becoming inseparable from identity governance. The build pipeline now depends on service accounts, registry tokens, and delegated access paths that can be abused if they are over-permissioned or poorly offboarded. That is why supply chain security programs need the same lifecycle discipline normally applied to NHIs and privileged accounts.

Provenance verification is the control teams will keep circling back to. Scanning remains necessary, but it cannot stop a package that should never have been trusted from entering the system. Security leaders should expect stronger demand for policy-as-code, intake controls, and attestation-backed release processes across engineering pipelines.

For practitioners

• Implement dependency inventory across direct and transitive packages Use automated software composition analysis to track what actually enters builds, including nested libraries and reused IaC modules.
• Enforce package intake policy before installation Block unapproved, lookalike, or non-compliant packages at the point of consumption so malicious code never reaches the pipeline.
• Generate and maintain SBOMs for release artefacts Automate software bills of materials so security, engineering, and audit teams can trace component provenance during incidents and compliance reviews.
• Treat CI/CD credentials as part of supply chain governance Review service accounts, tokens, and registry permissions used by build systems because those identities are often the bridge from package compromise to release compromise.
• Prioritise remediation by exploitability and runtime reach Rank dependency findings by whether they are reachable, exposed in critical systems, or likely to be weaponised in the wild rather than by raw alert volume.

Key takeaways

• Open source supply chain risk is no longer just a vulnerability-management problem. It is a governance problem that spans dependency inventory, package intake, and release control.
• Transitive dependencies and malicious packages create a hidden trust chain that can move compromise from a single library into build systems and production artefacts.
• Teams that can verify provenance, enforce policy, and maintain SBOM accuracy are better positioned to reduce exposure without slowing delivery.

Key terms

• Software Supply Chain Security: Software supply chain security is the practice of protecting the people, code, tools, dependencies, and delivery paths used to build and ship software. It covers source integrity, dependency risk, build system hardening, artifact signing, provenance, and release controls so malicious changes are detected before software reaches production.
• 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.
• Dependency Confusion: A supply chain attack in which a build system resolves a malicious public package instead of an intended internal one because of naming, versioning, or registry precedence. The risk is not only code substitution but automatic execution inside trusted pipelines that already contain valuable credentials.
• Control Provenance: The traceable origin of the evidence used to prove a control is operating. In practice, provenance matters when auditors need to know whether reports were generated independently, whether data was altered, and whether the proof can be reproduced later.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management for practitioners who need to connect identity controls to broader software and security programmes. It is designed for teams that must govern credentials, access, and lifecycle decisions across modern environments.