Software supply chain security is moving into engineering workflows

At a glance

What this is: This is Arnica’s analysis of Gartner’s 2026 secure software engineering Hype Cycle and its message that software supply chain security has moved into the engineering workflow.

Why it matters: It matters because IAM, NHI, and AppSec teams now have to treat developer tooling, agent-produced code, and secrets exposure as governed access and provenance problems, not only as code quality issues.

By the numbers:

• More than 95% of organisations use open-source software, often without full visibility into what they are pulling in.
• 43% of software engineering leaders surveyed by Gartner say building AI-powered features is a top priority.

👉 Read Arnica's analysis of Gartner's 2026 secure software engineering Hype Cycle

Context

Software supply chain security is no longer a narrow AppSec concern. It now sits inside the broader engineering system that produces code, assembles dependencies, and moves artifacts toward production, which means the control problem includes provenance, secrets, package trust, and the identity of tools that write code.

The pressure comes from AI-augmented development, distributed architectures, and growing dependency interconnection. When humans and AI agents both generate code, governance has to cover the full build path, not just the final review step. That is why this topic intersects with NHI governance, especially where code assistants, automation, and secrets handling create new non-human access paths.

Key questions

Q: How should security teams stop supply chain attacks in AI development workflows?

A: Security teams should narrow automation rights, isolate package installation from execution, and add runtime controls that can block abnormal process behaviour before code reaches production. In AI workflows, the important question is not only whether a source is trusted, but whether the agent or pipeline still has valid authority to act at the moment it executes.

Q: Why do AI coding agents increase supply-chain risk?

A: AI coding agents can choose tooling, install packages, and edit lock files in ways that may bypass the controls humans expect in a managed environment. That widens the blind spot around untracked software and makes package provenance harder to enforce. The practical response is to restrict agent permissions, inventory their workspaces, and review their install behaviour like any other privileged automation.

Q: What breaks when dependency scanning is based only on CVE counts?

A: Teams end up triaging large volumes of findings that may never be exploitable in their environment, while missing the few issues that can be invoked from live code paths. CVE counts alone do not tell you whether a package is reachable, trusted, or present in a critical build path. Reachability and provenance are what convert scanning into decision support.

Q: Which controls matter most when software supply chain risk meets zero trust?

A: The most useful controls are continuous validation, least privilege, runtime session monitoring, and a governed inventory of machine identities. Zero trust is not a single product decision. It is a discipline for proving that authenticated access is still appropriate after deployment, integration, and change.

Technical breakdown

Why reachability analysis changes dependency risk decisions

Reachability analysis asks a simpler question than traditional vulnerability scoring: can the vulnerable function actually be invoked by the application? In software supply chain security, that distinction matters because many dependencies contain known issues that never become exploitable in a given code path. By combining static analysis with call-path context, teams can separate theoretical exposure from practical risk. This also improves SBOM usefulness when paired with VEX-style context, because the inventory becomes operational rather than purely descriptive.

Practical implication: prioritise fixes where a vulnerable package is actually reachable, not where a scanner merely found a CVE.

Package reputation and provenance in modern build pipelines

Package reputation extends beyond CVE presence by looking at maintainer behaviour, community trust signals, and other indicators of dependency reliability. That matters because many supply chain compromises arrive through packages that are technically valid but socially or operationally risky before they are overtly malicious. For identity practitioners, this is a provenance problem as much as a code problem: the build system is making trust decisions about external software at machine speed. The same logic applies to AI-generated dependencies and tool-assisted code insertion.

Practical implication: add provenance and reputation checks to dependency approval so trust is not based only on version numbers and vulnerability lists.

MCP and agentic coding expand the supply chain attack surface

As AI agents write code and invoke tools, the build pipeline inherits a new set of identities, permissions, and integrations. MCP servers become control points for agent-to-tool communication, which means a compromised or over-privileged server can influence code generation, package import decisions, or data exposure. This is where software supply chain security crosses into NHI governance: agents, connectors, and coding tools are non-human actors with access that must be scoped, monitored, and revocable. The security issue is not just the output they produce, but the authority they carry while producing it.

Practical implication: inventory agentic coding tools and apply explicit policy to the non-human identities they use to reach repositories, models, and build systems.

Threat narrative

Attacker objective: The attacker seeks to turn trusted software delivery machinery into a scalable path for code execution, data exposure, or persistence across many downstream environments.

1. Entry occurs through trusted software pathways such as open-source packages, AI coding tools, or exposed secrets inside repositories.
2. Escalation follows when a vulnerable or over-privileged dependency, agent, or MCP-connected tool gains broader access than intended in the build and delivery chain.
3. Impact arrives when compromised software, leaked secrets, or untrusted code reaches production and expands the attacker’s reach across applications and downstream systems.

NHI Mgmt Group analysis

Software supply chain security has moved from a tooling problem to a governance problem. The article is really about where trust is established inside the SDLC, not just where vulnerabilities are found. Once AI agents and distributed dependency graphs are part of normal development, security teams have to govern provenance, policy, and revocation across the entire software path. Practitioners should treat build trust as a managed control plane, not a static checklist.

AI-generated code creates a new form of dependency sprawl that AppSec alone cannot absorb. If models can generate code and introduce packages at machine speed, then the control surface expands beyond human review capacity. That is why the identity of the code-producing system matters, especially where agentic tooling reaches repositories, package registries, and CI/CD systems. Practitioners should put explicit identity and policy controls around AI coding tools, not only around the output they produce.

Reachability analysis is becoming the difference between noise and governance. Traditional scanner output tells teams what exists, but not what can actually matter in their environment. The named concept here is dependency signal collapse: when raw vulnerability volume overwhelms teams and obscures the few issues that can actually be exploited. Practitioners should use reachability, provenance, and SBOM context together so remediation targets real exposure.

MCP is emerging as a supply-chain control point because it connects agents to the tools that shape code. That link changes the threat model from isolated developer mistakes to governed non-human access paths. If the server or connector is not trusted, then the code path is not trusted either. Practitioners should align MCP governance with NHI lifecycle and privilege review, because the access model is now part of software assurance.

Regulatory pressure is turning supply chain visibility into an auditable expectation. The article’s mention of SBOMs, continuous scanning, and supplier assessments reflects a broader shift in accountability. Security teams should expect engineering and risk functions to share evidence across product, platform, and compliance teams. Practitioners should design evidence collection once and reuse it for engineering, audit, and resilience reporting.

What this signals

Dependency signal collapse: engineering teams are increasingly exposed to more findings than they can action, which pushes them toward reachability, provenance, and policy-based prioritisation rather than universal remediation. The operational signal is clear: if your pipeline cannot separate exploitable risk from theoretical noise, it is producing awareness without governance.

As agentic coding becomes more common, the identity problem moves upstream into the build system. Security programmes should prepare to govern non-human access paths to repositories, registries, and CI/CD tooling in the same way they already manage privileged human access. The most mature teams will align software assurance with controls in the OWASP Non-Human Identity Top 10 and the NIST AI Risk Management Framework.

The practical change for practitioners is that software supply chain security now needs the same lifecycle discipline used in identity programmes. Provenance, rotation of secrets, and revocation of tool access should be treated as continuous controls, not one-time checks.

For practitioners

• Prioritise reachable vulnerability remediation Use reachability analysis to separate exploitable dependency issues from theoretical findings, then route only reachable cases into sprint planning. This reduces noise and focuses engineering time on code paths that can actually be abused.
• Inventory AI coding tools and their identities Map every agentic coding tool, plugin, and MCP-connected workflow that can write or influence code, then assign ownership for its access to repositories, registries, and pipelines. Treat each as a non-human identity with scoped permissions.
• Add provenance checks to dependency intake Require package reputation, maintainer trust signals, and source provenance review before new dependencies are allowed into approved build paths. This helps catch risky packages before they become embedded in production software.
• Review secrets exposure inside developer workflows Scan repositories, pull requests, and generated code paths for hardcoded secrets before merge, and tie findings to revocation and rotation workflows. Secrets in source remain a direct supply chain entry point.
• Align SBOM evidence with compliance reporting Build one evidence pipeline that can support SBOM generation, supplier assessments, and continuous vulnerability scanning without duplicating manual work. The goal is to make audit evidence a by-product of engineering controls.

Key takeaways

• Software supply chain security is now inseparable from secure engineering, because AI-generated code and deep dependency graphs widen the trust boundary.
• The most useful controls are the ones that separate real exposure from theoretical noise, especially reachability analysis, provenance, and secrets governance.
• Teams should start treating AI coding tools and MCP-connected workflows as governed non-human identities with explicit access, ownership, and revocation paths.

Key terms

• Reachability analysis: Reachability analysis checks whether a vulnerability can actually be exploited in the application’s real code paths and dependency graph. It helps teams distinguish theoretical findings from issues that an attacker can reach, which makes prioritisation far more accurate for both AppSec and identity risk management.
• Package Reputation: Package reputation is the trust profile of a dependency, built from maintainer activity, community behaviour, and other reliability signals. It helps teams assess whether a package is merely vulnerable in theory or risky in practice before it enters a build pipeline.
• MCP: Model Context Protocol, an open way for AI agents to connect to tools and data sources. It improves interoperability, but it also introduces a shared integration layer that must be governed carefully because the protocol can widen access across many systems at once.
• Agentic coding assistant: An AI-assisted development tool that can decompose tasks, choose actions, and execute parts of a workflow inside the editor. In security terms, it behaves like a non-human identity when it can access code, tools, and terminals on behalf of a developer, so governance must cover its runtime behaviour.

What's in the full article

Arnica's full blog post covers the operational detail this post intentionally leaves for the source:

• Reachability-analysis examples showing how vulnerable packages are deprioritised when code paths are not callable
• Developer-native workflow details, including ChatOps and pull request feedback for remediation
• How the tool surfaces package reputation, git posture, and pipeline visibility for prioritisation
• Additional coverage of AI-generated code risk handling across repositories and build systems

👉 The full Arnica post covers supply chain categories, AI coding risk, and workflow-level controls in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity control to real operational risk.