Software supply chain security best practices now hinge on identity controls

At a glance

What this is: Veracode argues that software supply chain security now hinges on identity controls because third-party code, build systems and AI-assisted development expand the attack surface beyond what developers directly write.

Why it matters: This matters because IAM, PAM and NHI teams increasingly govern the identities and secrets that move software through CI/CD, third-party integrations and AI-assisted tooling, not just user access.

By the numbers:

• 66% of the most critical, long-lived vulnerabilities in enterprise applications originate from third-party code, according to Veracode.
• Only 26% of critical vulnerabilities listed in CISA’s Known Exploited Vulnerabilities catalog were fully remediated, according to Veracode.
• The median time to full resolution climbed to 43 days, according to Veracode.

Context

Software supply chain security is the discipline of controlling what enters software before it reaches production, including code, dependencies, build systems, and automation identities. The weak point is no longer just vulnerable code. It is the trust chain that allows third-party components, CI/CD tooling, and AI-assisted development to inject risk faster than teams can review it.

The identity angle is now central because build pipelines, package registries, service accounts, and developer tokens are what make supply chain compromise operationally useful. When those identities are overprivileged, long-lived, or exposed in automation, the software supply chain becomes a machine identity governance problem as much as a code integrity problem.

Key questions

Q: What breaks when non-human identities are not governed in software supply chains?

A: When non-human identities are not governed, attackers can use tokens, service accounts, and secrets to reach build, release, and data systems that were never meant to be exposed together. The result is hidden persistent access, broad blast radius, and compromise that can spread through trusted automation before anyone notices.

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: How should security teams balance SLSA and SBOM requirements in software delivery?

A: SBOMs tell you what components are present, while SLSA addresses whether the artifact itself can be trusted. Teams should use both: SBOM for inventory and vulnerability response, SLSA for build provenance and tamper resistance. Together they create a fuller control picture than either one alone, especially when third-party and AI-assisted code are both in play.

Technical breakdown

Why software supply chain security is now an identity problem

Modern build and delivery systems rely on identities that are not human but still act with authority: service accounts, CI/CD tokens, signing keys, package registry credentials, and automation bots. Those identities often have standing access across repositories, artifact stores, and deployment targets, which means a single compromise can propagate from one component to many downstream systems. In practice, the chain is only as strong as the weakest identity that can publish, approve, or fetch software. Once an attacker steals a pipeline token or abuses a compromised maintainer account, they can move from code insertion to broad distribution quickly because the trust model assumes the actor is legitimate.

Practical implication: Treat build and release identities as privileged assets with lifecycle controls, not as implementation details.

How transitive dependencies expand the attack surface

A transitive dependency is a component that your software uses indirectly through another package. Teams often monitor direct dependencies while missing the deeper tree where malicious or vulnerable code can hide three levels down. That matters because package managers and AI coding tools can introduce libraries automatically, making human review too slow and too shallow to catch every import. The result is an attack surface defined by what your software fetches at build time, not just what developers consciously wrote. Identity controls matter here because the systems that resolve, approve, and install packages are the enforcement point for what enters the build.

Practical implication: Inventory and govern the identities that can approve dependency ingestion, not just the dependencies themselves.

Build integrity depends on provenance, not just scanning

Scanning tells you what is already present; provenance tells you whether the artifact you received is the one you intended to build. Build integrity frameworks such as SLSA focus on this distinction by requiring verifiable source, build process, and artifact attestations. That is important because an attacker does not need to change source code if they can tamper with the build stage, poison a package registry, or impersonate a trusted publisher. Without provenance controls, security teams are left trying to detect malicious output after it has already inherited the trust of the pipeline that produced it.

Practical implication: Add provenance checks and signing controls to the build path so release trust does not depend on manual review alone.

Threat narrative

Attacker objective: The objective is to insert trusted-looking malicious code into software delivery paths so the attacker can steal secrets, persist in downstream projects, or reach production systems at scale.

1. Entry occurs when attackers compromise a dependency, package registry entry, or CI/CD credential that sits inside the build pipeline.
2. Credential access or abuse follows when developer tokens, maintainer accounts, or pipeline secrets are hijacked to publish poisoned versions or modify build steps.
3. Impact arrives when malicious artifacts are distributed downstream and inherit the trust of the software delivery process, spreading compromise across projects and environments.

Breaches seen in the wild

• Nx s1ngularity attack 2025: Attackers stole Nx's npm token via a GitHub Actions flaw and shipped malware that stole 2,349 secrets and abused developers' AI CLIs.
• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.

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 security has become a machine identity governance problem. The article is right to move beyond code review and scanning because build systems, registry publishers and automation bots are the actors that now control software movement. When those identities are overprivileged or long-lived, compromise becomes a distribution event rather than an isolated incident. Practitioners should manage pipeline identities with the same rigor they apply to privileged human accounts.

Transitive dependency risk is really trust delegation without enough oversight. Enterprises rarely understand every indirect package their software pulls in, yet those packages can still execute with production relevance. That creates a governance gap where approval is separated from effect, which is exactly where supply chain attacks thrive. The practical conclusion is that dependency trust has to be explicit, inventory-driven and continuously validated.

AI-assisted development is widening the supply chain perimeter. AI tools now influence what packages get imported, what code gets generated and which dependencies are copied into repositories. That means security policy has to cover the toolchain that suggests software, not only the software that lands in source control. The real issue is not whether AI writes code, but whether organisations can govern the identities and provenance behind what AI introduces.

Build provenance is the missing control that ties security, compliance and incident response together. Scanning without attestation leaves teams able to describe exposure but not prove artifact origin. Frameworks such as SLSA matter because they force evidence about what was built, where it came from and which identity handled it. Practitioners should treat provenance as a core control plane for software trust, not a niche DevSecOps enhancement.

The named concept here is dependency trust delegation. It describes the point where organisations allow indirect software inputs to inherit production trust without matching governance over the identities that approve, fetch or publish them. That failure mode is now visible across CI/CD, open source intake and AI-assisted coding. Teams should rework controls around delegated software trust, not assume component-level scanning is enough.

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.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: CI/CD Pipeline Identity Security Guide

What this signals

Dependency trust delegation: software supply chain risk now sits at the point where indirect components inherit production trust without matching governance over the identities that approve them. That means build systems, package registries and signing workflows deserve the same lifecycle controls as privileged user access.

Enterprises should expect supply chain governance to merge more tightly with identity governance as automation and AI-assisted development expand the number of non-human actors that can move code into production. Continuous inventory, provenance attestation and explicit approval boundaries are becoming baseline control expectations rather than specialised additions.

For practitioners

• Govern pipeline and registry identities as privileged assets Map every service account, token, signing key and bot that can approve, publish or deploy software, then remove standing access wherever possible. Tie each identity to an owner, expiry, rotation schedule and revocation path.
• Block unapproved dependency ingestion at the build boundary Enforce policy on package sources, publisher trust, typosquatting and transitive dependency approval before code enters the build. Use allowlists and package firewall controls for high-risk repositories and automation paths.
• Require provenance evidence for build outputs Adopt artifact signing, build attestations and source-to-binary traceability so release trust depends on verifiable origin rather than post-build inspection. Apply the same standard to first-party and AI-assisted code.
• Instrument continuous dependency monitoring across the portfolio Scan direct and transitive dependencies continuously, not only at release time, and alert when newly disclosed vulnerabilities affect production components. Track remediation SLAs separately for internet-facing and internally scoped software.
• Review AI coding tools as part of supply chain policy Document which assistants are allowed, what packages they may suggest or install, and what review gates apply before generated code merges. Treat AI-generated imports as supply chain events that need explicit approval.

Key takeaways

• Software supply chain security is now inseparable from identity governance because build and release paths rely on privileged non-human actors.
• The article shows that third-party code, transitive dependencies and AI-assisted development enlarge the attack surface faster than manual review can keep up.
• Teams need provenance, continuous dependency monitoring and tightly governed automation identities if they want to reduce downstream compromise risk.

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.
• 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.
• 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.
• Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It helps security, IAM, and platform teams govern the identities that now shape software delivery and access.