Software supply chain security tools now govern AI code and identity

At a glance

What this is: Arnica argues that software supply chain security tools now need to cover dependencies, build infrastructure, AI-generated code, and identity-aware routing, not just the code developers commit.

Why it matters: This matters because security teams cannot govern modern software risk if findings stop at the repo boundary while AI agents, external packages, and identity context shape what actually ships.

Context

Software supply chain security is about the controls that sit around code creation and delivery, not only the code itself. When dependencies, CI/CD workflows, and build infrastructure are part of the attack surface, traditional application security models miss the layers where compromise can enter or persist. The article also shows a genuine identity intersection: who wrote or triggered a change now affects how findings are routed and acted on.

The vendor's core claim is that AI-generated code and pipelineless coverage change what good governance looks like. That is a real shift for engineering security programmes because coverage, attribution, and remediation no longer map cleanly to a single repository scan or a single file owner.

Key questions

Q: What breaks when software supply chain controls rely only on post-build scanning?

A: Post-build scanning often finds problems after risky code, secrets, or malicious dependencies have already entered repositories, images, or deployment pipelines. By then, the issue may have propagated across multiple environments. Continuous upstream enforcement is needed because late detection does not stop distribution.

Q: Why do dependencies and build infrastructure create supply chain risk?

A: Because they are trusted inputs into software delivery, yet they often come from outside the organisation's direct code review process. A compromised package, poisoned build step, or exposed secret can introduce vulnerabilities that internal testing will not reliably catch, which is why governance must extend beyond the team's own source code.

Q: How can security teams measure whether supply chain controls are actually working?

A: Look for reduced use of long-lived publishing tokens, fewer workflows with broad secrets access, lower dependency auto-update exposure, and faster revocation after compromise. If malicious releases still reach trusted build paths before detection, the controls are not containing trust inheritance.

Q: What is the difference between repository scanning and generation-time governance?

A: Repository scanning looks at code after it has already been written or committed, while generation-time governance applies controls before the code enters the repo at all. The distinction matters for AI-assisted development because some of the highest-risk decisions now happen before traditional scanners ever see the change.

Technical breakdown

Why pipelineless coverage changes the control boundary

Traditional supply chain tooling assumes security value begins once code reaches a repository, a build system, or a CI/CD pipeline. A pipelineless model shifts that boundary earlier by analysing source and behaviour through the SCM connection itself, which means security controls can observe repositories even when CI/CD agents are absent or never installed. That matters because modern delivery environments often contain blind spots between developer workstations, cloud agents, and ephemeral build paths. In practice, the architectural question is not whether scanning exists, but where coverage starts and what path the tool can actually see.

Practical implication: map every repo and delivery path to the earliest point where your controls can still see risk.

How AI-generated code becomes a supply chain control problem

AI coding agents complicate software supply chain security because they can generate code that enters repositories before a human reviewer has a stable opportunity to inspect the provenance or risk profile. That turns code generation into a governance moment, not just a development convenience. The relevant control question is whether the security programme can apply policy before commit, preserve evidence about what was generated, and distinguish human-written from machine-produced contributions when decisions are made. This is where identity matters: attribution and authorisation are now part of code risk management.

Practical implication: treat code generation as a governed step and require provenance-aware controls before commit.

Why identity-aware routing is now part of remediation

Identity-aware routing means findings are assigned to the person or actor that actually created or owns the risky change, rather than being left at team, folder, or CODEOWNERS level. That matters because remediation speed depends on precise accountability, and AI-assisted development makes shared ownership less reliable as a response model. In security terms, the issue is not only detection but decision routing. If the tool cannot tie a finding back to the right developer, cloud agent, or automated contributor, then blast radius and fix latency both increase.

Practical implication: verify that findings route to the actual contributor, not just the nominal team owner.

Threat narrative

Attacker objective: The objective is to get malicious or unsafe code, secrets, or dependency changes into production through trusted software delivery paths.

1. Entry occurs through dependencies, packages, or build infrastructure that sit outside the code a team directly writes, creating a broader attack surface than traditional AppSec assumes.
2. Credentialed or authorised access to CI/CD workflows, repository metadata, or AI-generated commits can let attackers or risky automation introduce malicious or vulnerable changes without immediate visibility.
3. Impact appears when poisoned builds, exposed secrets, or ungoverned AI-generated code reach production faster than review and remediation processes can contain them.

Breaches seen in the wild

• Hugging Face API tokens exposed 2023: Lasso Security found 1,681 live Hugging Face tokens in public code, 655 with write access, reaching 723 organisations including Meta; all were revoked.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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 governance problem, not just a scanning problem. The article shows that dependencies, build infrastructure, AI-generated code, and identity context now influence whether software is secure enough to ship. That means the control plane has moved from a single scanner to a workflow that must understand provenance, routing, and ownership. Practitioners should judge tools by where they govern, not how many findings they list.

Generation-time governance is the new boundary for AI-assisted development. Once AI agents can write meaningful code, waiting for repository ingestion is already late for part of the risk. The important question is whether policy can act before commit, while keeping evidence of what was generated and who or what initiated it. This is where software supply chain security intersects with agentic AI identity in a practical way.

Identity-aware remediation will matter more than team-based ownership. The article's emphasis on resolving findings to specific developers shows that generic ownership models are becoming too coarse for modern software delivery. When humans and AI agents both contribute, security teams need attribution that survives shared repos, cloud agents, and automated commits. Practitioner conclusion: if your routing model cannot identify the real actor, your remediation model is already lagging.

Pipelineless coverage is a response to coverage gaps, not a feature race. The architectural split described in the article is between tools that depend on installs inside pipelines and tools that can observe activity through the SCM connection itself. That distinction will shape adoption as engineering teams distribute work across local, cloud, and agent-driven workflows. Practitioner conclusion: coverage architecture now determines control reliability.

From our research library:

• Gartner predicts that more than 40% of agentic AI projects will be cancelled by the end of 2027, citing rising costs, unclear value and insufficient risk controls.
• Read next: Agentic AI Security Guide

What this signals

Generation-time governance is becoming the control point that matters most. Security teams should expect more code to be produced by AI agents and more findings to be created before a human ever opens a pull request. That shifts the programme from after-the-fact review to pre-commit policy enforcement and provenance tracking, which is where software supply chain governance now has to operate.

Coverage architecture will decide whether your controls keep pace with delivery. Pipelineless models and SCM-based governance reduce the dependency on installed agents, while pipeline-dependent approaches will continue to leave blind spots in cloud-heavy and AI-assisted workflows. Teams should test whether their current stack can see every repository, every contributor, and every generated change before they assume their controls are complete.

Identity-aware routing closes the gap between detection and remediation. When findings resolve to the actual contributor, security teams can shorten fix cycles and avoid the ambiguity that shared ownership creates. The practical signal is simple: if your tool cannot tell who changed the code, it cannot reliably tell who should fix it.

For practitioners

• Define your true software supply chain boundary Inventory where dependencies, generated code, CI/CD workflows, and build infrastructure enter the delivery path so controls follow the actual attack surface.
• Require provenance-aware checks before commit Place policy enforcement at the generation or pre-commit stage for AI-assisted changes so risky code does not wait for repository scanning to be caught.
• Test coverage gaps created by pipeline dependence Compare repository coverage for tools that need installed agents against tools that can inspect through the SCM connection without per-developer setup.
• Route findings to the actual contributor Use identity-aware assignment so remediation lands with the developer or cloud agent that introduced the change, not just the team that owns the repository.

Key takeaways

• Software supply chain security now has to govern dependencies, build infrastructure, AI-generated code, and ownership context, not just committed source code.
• The article's architectural split is between tools that depend on CI/CD deployment and tools that can govern through the SCM connection with broader repository coverage.
• Identity-aware routing and generation-time governance are becoming the controls that determine whether supply chain security can keep up with modern 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.
• Pipelineless Architecture: A delivery model that applies security controls through the source code management layer instead of relying on CI/CD jobs or local agent installs. It is useful when organisations need continuous visibility across repositories that may not have complete pipeline coverage or developer-side tooling.
• Identity-Aware Routing: A routing model that decides whether traffic may reach a private resource based on the authenticated identity and policy context. In this pattern, the network path is not the trust boundary; entitlement and session policy are, which makes internal access auditable and scoped.
• Install-Time Governance: Install-time governance is the set of controls that decide whether software may reach a developer device, browser, or workspace before execution. It focuses on blocking, delaying, or reviewing packages, extensions, AI tools, and related artifacts at the moment they are introduced into the environment.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, machine identity security, IAM, and secrets management. It is designed for practitioners who need to align identity controls with broader security and engineering programmes.