Open source supply chain risk is now an SDLC governance problem

At a glance

What this is: This is a practitioner-focused analysis of open source supply chain security, centred on the finding that third-party code now drives most critical security debt and that defenders need visibility, policy, and layered controls.

Why it matters: It matters because engineering speed, compliance pressure, and software trust now depend on how well teams govern third-party code, CI/CD controls, and the identity and integrity of build-time tooling.

By the numbers:

• 70% of critical security debt originates from third-party code.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected.
• 17 minutes.

👉 Read Veracode's analysis of open source supply chain security best practices

Context

Open source supply chain security is about controlling the risk introduced by code you did not author but still trust in production. In this article, the primary issue is not whether open-source software is useful, but whether organisations can govern dependency risk, package integrity, and build-time trust well enough to keep delivery speed from becoming exposure speed.

The identity connection is real even in a software supply chain discussion. Package registries, CI/CD systems, and container build pipelines rely on non-human identities, secrets, and permissions to fetch, approve, sign, and deploy code. When those identities are weakly governed, third-party code risk becomes an access-control problem as much as a scanning problem.

Key questions

Q: How should security teams govern open source dependencies in CI/CD pipelines?

A: Security teams should treat dependency governance as a release-control problem, not just a scanning problem. That means mapping direct and transitive dependencies, enforcing package provenance before download, and tying every approved component to an accountable owner. The goal is to prevent untrusted code from entering the pipeline in the first place.

Q: Why do malicious packages keep bypassing software supply chain controls?

A: They bypass controls because build systems often trust registry names, default resolution paths, and automation permissions more than they trust human review. When a pipeline can fetch packages automatically, typosquatting, dependency confusion, and repo-jacking exploit that trust. Strong source authentication and allowlisting are what change the outcome.

Q: What do teams get wrong about SBOMs and supply chain visibility?

A: The common mistake is treating SBOMs as a reporting output instead of an enforcement mechanism. A component inventory is useful only if it drives release decisions, risk scoring, and quarantine actions. Without policy tied to the inventory, organisations get better visibility but not better control.

Q: How should organisations reduce the blast radius of build and deploy identities?

A: Limit the permissions of package managers, signing services, and deployment automation to the smallest set needed for their task. Separate fetch, sign, and promote functions, rotate required secrets, and prefer workload identity where feasible. That prevents one compromised automation account from controlling the entire release chain.

Technical breakdown

Dependency sprawl and transitive trust

Modern applications rarely depend only on the libraries developers import directly. They also inherit transitive dependencies, build plugins, and container base layers that can change the effective trust boundary without being visible in source code review. That creates a governance gap: security teams may review the application while missing the packages, registries, and automation identities that actually assemble it. Software composition analysis helps, but only if it is tied to ownership, policy, and release gates rather than treated as a reporting layer.

Practical implication: map direct and transitive dependencies to the build identities and pipelines that consume them.

Why malicious packages succeed in CI/CD

Typosquatting, dependency confusion, and repo-jacking work because automated build systems are designed to trust package names, registry lookups, and default resolution paths. If the pipeline pulls from public sources without policy controls, a malicious package can enter the software factory before a human ever sees it. This is less a vulnerability in one library than a weakness in how the pipeline authenticates sources, authorises downloads, and validates provenance.

Practical implication: enforce package allowlists, provenance checks, and registry controls before code reaches the build stage.

SBOMs, policy-as-code, and runtime verification

Software bills of materials give organisations visibility into what is in the release, but visibility alone does not stop risky code from moving downstream. The stronger model combines SBOM generation, policy-as-code for licences and vulnerabilities, and runtime monitoring of container and application behaviour. That pairing turns supply chain security into a lifecycle control rather than a point-in-time scan. It also matters for NHI governance because the automation accounts that fetch, sign, and deploy artefacts become high-value control points that need lifecycle management and least privilege.

Practical implication: treat SBOMs, policy rules, and runtime checks as one control chain, not separate tools.

Threat narrative

Attacker objective: The attacker wants to insert malicious code or steal build-time trust so that compromised dependencies can spread into production systems and customer environments.

1. Entry occurs when an attacker publishes a malicious package, abuses dependency confusion, or hijacks a trusted repository path that automated builds will accept.
2. Credential or trust abuse follows when the CI/CD pipeline or developer tooling resolves the hostile package using its existing registry access and automation permissions.
3. Impact occurs when poisoned dependencies, stolen tokens, or manipulated build artefacts reach production and compromise applications, deployments, or downstream customers.

NHI Mgmt Group analysis

Third-party code risk is really trust-boundary risk. Open source supply chain security fails when organisations treat dependency review as a software issue instead of a trust and access issue. The build pipeline, package registry, signing service, and deploy automation all carry non-human identities that can widen blast radius if they are over-privileged or poorly segmented. Practitioners should govern these identities as part of the release chain, not as an afterthought.

Identity controls now determine whether supply chain attacks become platform-wide incidents. Attackers increasingly win through the automation layer, not the developer workstation. That means secrets management, registry authentication, workload identity, and policy enforcement are central to supply chain defence. The operational lesson is that secure source code alone does not secure the software factory.

Transitive dependency visibility is the named governance gap many teams still miss. Transitive trust drift: a release can inherit risk from libraries, plugins, and build steps that were never directly approved. This drift becomes material when security teams can name first-party code but cannot explain which non-human identities are allowed to fetch, sign, or promote third-party artefacts. Practitioners should connect dependency inventory to identity ownership and release authority.

SBOM maturity is only useful when it drives enforcement. A complete component inventory matters less than the ability to block or quarantine risky packages before they are built, signed, or deployed. The article's emphasis on visibility, proactive prevention, and layered defence reflects the broader market direction toward control-plane governance. Practitioners should measure whether SBOMs change release decisions, not just audit reports.

Open source supply chain security is converging with broader software governance. DORA, licence policy, container security, and CI/CD integrity are increasingly part of one control surface. That convergence matters because the same automation identities often move code, secrets, and infrastructure changes. Practitioners should align supply chain controls with identity lifecycle, privileged access, and runtime assurance.

What this signals

Transitive trust drift will become a useful shorthand for the risk that hidden dependencies and automation identities expand exposure faster than teams can review it. That drift matters because supply chain security programmes now need to govern both artefacts and the non-human identities that move them through the pipeline.

The practical signal for security leaders is that build-time trust controls will be judged alongside runtime detection. Inventory, provenance, and least privilege need to be managed as one programme, or the organisation ends up with visibility without enforceable restraint.

If your SDLC still separates application security from identity governance, the attack path is already longer than your control path. The stronger model is to align release approval, secrets management, and pipeline privilege with the same governance logic used for other high-risk access.

For practitioners

• Implement dependency inventory across the full release chain Use software composition analysis to map direct and transitive dependencies, then assign ownership for each critical package, plugin, and build artefact. Tie the inventory to the pipeline that consumes it so release managers can see which build identities touch which components.
• Enforce package provenance before build execution Require registry allowlists, signature or provenance validation, and package firewall rules before dependencies are pulled into CI/CD. Block typosquatting, dependency confusion, and untrusted sources at the point of download rather than relying on post-build detection.
• Treat SBOM generation as a release gate Generate SBOMs automatically and use them to block releases that contain unapproved components, unsupported licences, or known high-risk dependencies. Make the release decision visible to engineering, security, and compliance owners.
• Reduce privilege on build and deploy identities Minimise the permissions used by package managers, signing services, and deployment automation. Rotate the secrets they still require, prefer workload identity where possible, and separate fetch, sign, and promote duties to limit blast radius if one account is abused.
• Add runtime monitoring for container and dependency abuse Scan container images before deployment and monitor runtime environments for suspicious package behaviour, risky base images, or unexpected outbound activity. Combine this with policy enforcement so unsafe artefacts cannot persist in production unnoticed.

Key takeaways

• Open source supply chain risk is no longer just a code quality issue.** It is a governance problem involving dependencies, package trust, and the non-human identities that move software into production.
• Visibility alone does not stop malicious packages or compromised build paths.** Teams need provenance checks, release gates, and least-privilege automation to turn inventory into control.
• The next maturity step is to govern the software factory as a trust boundary.** That means aligning SBOMs, CI/CD permissions, and runtime monitoring under one operating model.

Key terms

• 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: Dependency confusion is an attack technique where an automated build process pulls a malicious public package instead of the intended private one. It succeeds when package resolution trusts naming and default lookup order more than provenance, ownership, or allowlisting.
• Package Firewall: A package firewall is a control that inspects and filters software packages before they are downloaded into a build or developer workflow. It reduces supply chain risk by blocking malicious, unapproved, or policy-violating components at the point of entry.
• Transitive Dependency: A transitive dependency is a package that your application uses indirectly through another library. These hidden components expand the attack surface because they can introduce vulnerabilities, licensing issues, or malicious code without appearing in the first layer of developer choice.

What's in the full article

Veracode's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance on SCA, SAST, DAST, package firewall, and container security integration.
• Practical advice on automating SBOMs and policy enforcement across the SDLC.
• Examples of how to reduce workflow friction while keeping developer tooling integrated into CI/CD.
• Discussion of how dynamic risk scoring and automated triage can be used to prioritise remediation.

👉 Veracode's full article covers the SDLC controls, workflow integration, and risk prioritisation detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and identity lifecycle fundamentals. It is designed for practitioners who need to connect identity controls to modern security programmes.