Software supply chain security is moving into engineering workflows

At a glance

What this is: Arnica’s article says software supply chain security is moving into secure engineering workflows, with Gartner placing the category in the Transformational tier and expecting mainstream adoption within two to five years.

Why it matters: This matters because security teams now have to govern code, dependencies, secrets, and AI-generated output inside developer workflows rather than relying on post-build or post-release checks.

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.

Context

Software supply chain security now sits inside the software delivery system, not beside it. That matters because the main risks are no longer limited to one vulnerable package or one exposed secret. They are spread across repositories, CI pipelines, AI-assisted coding, and the governance decisions that shape how software is reviewed and shipped.

For identity and access practitioners, the intersection is increasingly real. The same engineering workflows that move code also move credentials, service permissions, and delegated access into build and delivery systems. Once AI agents are generating code and MCP-connected tooling is part of the development path, supply chain controls and identity governance start to overlap.

The article’s starting point is typical for the current market: security teams are being asked to reduce risk without slowing delivery, and the only durable answer is to make controls part of the workflow itself.

Key questions

Q: Where does software supply chain security fail in practice?

A: It fails when teams rely on late-stage scanning after code, dependencies, and secrets have already entered the delivery pipeline. By that point, the most useful control is no longer detection but prevention inside pull requests, build steps, and policy checks that stop untrusted material from advancing.

Q: Why do AI-generated code and agentic workflows make AppSec prioritisation harder?

A: AI-generated code increases finding volume faster than human review capacity, so severity alone stops being a useful filter. Teams need reachability, ownership, business criticality, and deployment context to decide what is truly exploitable. Without those signals, security teams spend time on low-value findings while real exposure keeps moving into production.

Q: What do security teams get wrong about dependency scanning?

A: They often assume a clean manifest means a clean environment. In reality, package managers can resolve transitive code dynamically and execute scripts during installation. A scan can confirm what should have been installed, but it cannot prove what actually ran or what secrets the code reached.

Q: How should organisations govern secrets and third-party components in the SDLC?

A: They should enforce controls at the point of introduction, not after code is shipped. That means blocking hardcoded secrets, checking package trust before merge, and making build and repository policy part of the same governance model rather than separate security tasks.

Technical breakdown

Why software supply chain risk now lives in the SDLC

Software supply chain risk used to be treated as a downstream validation problem: scan dependencies, check signatures, and patch after release. That model breaks when code is produced continuously by human developers and AI systems, while dependencies, build steps, and package sources change faster than manual review can track. The real control question is not whether a component is vulnerable in the abstract, but whether the organisation can see what is in the build path, how it was introduced, and whether it is trusted enough to ship.

Practical implication: move supply chain controls into source, build, and pull request workflows instead of relying on late-stage security review.

Reachability analysis, SBOMs, and the limits of CVE-first triage

CVE-first triage often creates noise because it treats every vulnerability as equally relevant. Reachability analysis improves that model by asking whether the vulnerable function is actually invoked by the code in your environment. SBOMs add inventory, but inventory alone does not tell you whether a dependency is exploitable, whether it is maintained, or whether it should block release. In secure engineering workflows, the useful combination is inventory, reachability, and policy enforcement tied to the build pipeline.

Practical implication: prioritise controls that connect dependency visibility to exploitability and release decisions, not just raw vulnerability counts.

AI-generated code and MCP-linked tooling expand the review surface

AI-generated code changes the supply chain problem because the code authoring step is no longer limited to humans. That expands the review surface to include the tools that generate code, the packages they suggest, and the prompts or agent workflows that influence what gets introduced into the repository. MCP-connected tooling adds another layer because it links models to external tools and data sources, which creates new provenance and trust questions across the SDLC. The security issue is no longer only what code exists, but what chain of tools and identities produced it.

Practical implication: extend software supply chain policy to AI-generated output, MCP usage, and any workflow that can inject code or dependencies.

Threat narrative

Attacker objective: The attacker wants to turn trusted development and build workflows into a path for code execution, secret theft, or downstream compromise at scale.

1. Entry occurs through developer workflows, where vulnerable dependencies, hardcoded secrets, or AI-generated code can enter the repository before traditional review catches them.
2. Credential or package abuse follows when unvetted packages, compromised maintainers, or exposed secrets are allowed into the build and release path.
3. Escalation happens as those components are promoted through CI/CD and gain trusted access to downstream systems, making the supply chain itself the delivery vector.
4. Impact is production exposure, where malicious or unsafe code reaches runtime, expands blast radius, or enables broader compromise of software and connected environments.

Breaches seen in the wild

• xinference PyPI compromise 2026: Three xinference releases on PyPI carried a stealer for cloud, Kubernetes and registry keys, reportedly via a compromised bot account.
• 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.

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 is no longer a post-build control problem; it is a workflow governance problem. Once security moves upstream into IDEs, pull requests, and CI pipelines, the organisation is governing how trust enters software, not just how it exits. That makes developer experience and control design inseparable, because controls that live outside the workflow will miss the moment risk is introduced. The practitioner lesson is to treat the SDLC as the control surface.

AI-generated code creates governance debt unless organisations can inspect provenance at the same speed as code creation. Human review alone cannot keep pace with high-volume code generation, package suggestions, and agent-assisted changes. That means supply chain policy now has to cover both authored code and generated code, with clear rules for review, provenance, and trust thresholds. The practitioner conclusion is that AI development should be governed as part of software engineering, not as an adjacent experiment.

Agentic coding security: when code-writing tools and MCP-linked integrations can introduce dependencies, the governance gap is traceability, not just vulnerability scanning. The article points to a class of risk where toolchains, packages, and agent outputs all contribute to the build chain. That is where identity and supply chain controls intersect, because the systems producing code are acting with delegated trust. The practitioner conclusion is to verify the identity and provenance of the tools shaping the pipeline.

Secrets detection remains a frontline control because hardcoded credentials still provide the shortest path from source code to compromise. The issue is not abstract leakage risk. It is the operational reality that a secret committed early can be copied, cached, mirrored, and reused long before a routine review would catch it. The practitioner conclusion is that secret exposure has to be prevented at authoring time and blocked before merge, not remediated after release.

Reachability and reputation are becoming the two controls that separate useful signal from dependency noise. Most teams do not need more alerts about theoretical package risk. They need to know which dependencies are actually callable, which packages are trustworthy enough to use, and which code paths matter in their environment. The practitioner conclusion is that triage should be based on exploitability and provenance, not just vulnerability volume.

From our research library:

• 67% of organisations still rely heavily on static credentials despite the risks they pose to agentic AI deployments, according to the 2026 Infrastructure Identity Survey.
• 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
• Read next: Agentic AI Security Guide

What this signals

Software supply chain governance is converging with identity governance inside engineering pipelines. The practical boundary has moved. When repositories, CI systems, and AI-assisted tooling can introduce credentials, packages, and delegated access, the control problem becomes one of lifecycle governance across code and identity together. Teams should expect security architecture to shift from point tools to workflow policy.

Agentic coding security is now a provenance problem as much as a code-quality problem. Security leaders should prepare for a world where the question is not only whether code is vulnerable, but whether the system that produced it can be trusted. That means provenance, reviewability, and policy enforcement must be embedded before merge and before release.

More than 95% of organisations use open-source software, often without full visibility into what they are pulling in, according to the Ultimate Guide to NHIs. That scale makes reachability, package reputation, and secret prevention the controls that matter most when supply chain risk is operationalised inside engineering workflows.

For practitioners

• Embed supply chain checks in pull requests Require dependency, secret, and provenance checks before code can merge so risk is addressed while developers are still in workflow.
• Prioritise reachable vulnerabilities over raw counts Use reachability analysis to focus remediation on dependencies your code actually calls, and deprioritise issues with no execution path.
• Extend policy to AI-generated code Treat AI-assisted and agent-produced code the same as human-written code for review, dependency approval, and release gating.
• Block hardcoded secrets before merge Scan repositories and branch protections for secrets early enough to stop them entering CI pipelines, caches, and release artifacts.

Key takeaways

• Software supply chain security is moving from a downstream scanning problem to an engineering governance problem inside the SDLC.
• AI-generated code, MCP-linked tooling, and distributed dependencies expand the trust surface that security teams must inspect before merge and release.
• Reachability analysis, secret prevention, and provenance controls are becoming the practical levers that reduce noise and improve risk decisions.

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.
• 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.
• 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.

Deepen your knowledge

The NHI Foundation Level course covers NHI governance, agentic AI identity, and machine identity security in a way that helps practitioners connect identity controls to modern engineering workflows. It is designed for teams that need a shared baseline for governing delegated trust across software delivery.