AI changed software supply chain risk faster than controls can adapt

At a glance

What this is: StepSecurity argues that software supply chain security is inflecting because AI has expanded both the volume of code moving through pipelines and the speed of attacker tradecraft.

Why it matters: For IAM and NHI practitioners, the key issue is governing machine-to-machine trust across developer tools, package ecosystems, and CI/CD workflows before secrets and privileges are abused.

By the numbers:

• 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
• AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.

👉 Read StepSecurity's mid-year update on software supply chain security and AI-driven pipeline risk

Context

Software supply chain security now has to account for the identity and trust boundaries around developer machines, package registries, CI/CD workflows, and AI coding agents. When those layers are connected by reusable secrets and broad automation, compromise can spread faster than traditional review and approval models can contain it.

StepSecurity’s mid-year update is primarily a market and operational signal, not just a business update. The article shows that attackers are shifting left into the build and delivery path, where non-human identities, tokens, and workflow permissions become the practical control plane for both prevention and blast-radius limitation.

Key questions

Q: What breaks when software supply chain controls are only partially automated?

A: Partial automation creates inconsistent enforcement, which means some builds are protected while others slip through manual exceptions or forgotten paths. That weakens trust in the whole release process. The practical consequence is asymmetric risk, where attackers only need to find one unprotected route to get a compromised artefact into production.

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: How do security teams know if a package compromise is actually contained?

A: They should confirm three things: the bad version no longer appears in lockfiles, SBOM records no longer resolve to it, and running services no longer load it. If any one of those still matches, the compromise is not contained. Re-scan after remediation and require evidence from both code and runtime.

Q: Who is accountable when a supply chain compromise spreads through trusted credentials?

A: Accountability usually spans release engineering, platform security, and identity governance because the incident crosses multiple trust domains. The practical question is which team owns credential scope, publish rights, and offboarding for automation identities. Frameworks such as NIST CSF and NHI governance models help assign control ownership where a single compromise can affect many systems.

Technical breakdown

Why developer machines and CI/CD runners became the new attack surface

Modern software delivery systems distribute trust across laptops, repositories, registries, and runtime workflows. That matters because compromise rarely stays at one layer: a malicious package or workflow can reach developer tooling, then CI/CD, then downstream credentials and release processes. AI coding agents intensify this pattern by increasing the rate at which dependencies are installed and changes are accepted. In supply chain security, the relevant unit of control is no longer the repository alone, but the path from code creation to execution.

Practical implication: map controls to each stage where code can be introduced, executed, or exfiltrated, not just to source control.

How runtime controls limit secrets exposure after a compromise

Runtime controls matter because supply chain attacks often aim to steal secrets rather than simply run malicious code. Egress blocking, workflow cancellation, package cooldown, and device policy work differently, but they all reduce the attacker’s ability to convert execution into credential theft or lateral movement. This is especially important in environments where tokens, API keys, and build secrets are available to automation. The core architectural idea is blast-radius control: assume one layer may fail and constrain what the attacker can reach next.

Practical implication: pair preventive policies with runtime containment so a single compromised component cannot access secrets or external channels freely.

What searchable compromise discovery changes for security operations

Discovery across developer machines, pull requests, branches, registries, and workflow runs is a response to a simple operational problem: teams cannot defend what they cannot find. Searchable compromise analysis ties a vulnerable package or malicious action to every place it landed, which shortens triage and supports incident scoping. That is not just a detection problem. It is a trust inventory problem that overlaps with NHI governance because secrets, tokens, and service credentials are the assets most often exposed when supply chain compromise succeeds.

Practical implication: build an inventory that can answer where a compromised package or action was used before you need to prove exposure scope.

Threat narrative

Attacker objective: The attacker’s objective is to turn trusted software delivery paths into a scalable route for secret theft, code manipulation, or broader supply chain compromise.

1. Entry begins when attackers compromise a package, action, or dependency that is trusted by developer tooling or CI/CD workflows.
2. Escalation occurs when that trusted component executes with access to build secrets, runner context, or developer machine resources.
3. Impact follows when the attacker steals credentials, exfiltrates data, or uses the compromised pipeline to spread further into the software estate.

NHI Mgmt Group analysis

AI has turned software supply chain security into a non-human identity problem. The article shows that the control plane now includes packages, runners, workflow tokens, and AI coding agents, all of which behave like machine identities with varying privilege and lifecycle discipline. That means the governance challenge is not just malware prevention, but ownership, scope, and revocation for machine-mediated trust. Practitioners should treat every automated path to code execution as an identity surface.

Blast-radius control is becoming more important than point detection. StepSecurity’s framing is consistent with a market in which attackers can move from compromise to secret theft in minutes, while response often takes days. The named concept here is pipeline trust fragmentation: when controls are split across machines, repos, registries, and runtime layers, no single team can prove the whole path is safe. Practitioners should prioritise layered containment over assumptions that one gate will stop every compromise.

Security teams should re-evaluate where they place trust in ephemeral automation. AI coding agents and automated workflow systems can install, update, and execute code at machine speed, which weakens review-based assumptions inherited from human-centric SDLC models. The right response is not to ban automation, but to govern it as a privileged system with explicit policy, bounded access, and auditable execution. Practitioners should align this with OWASP-NHI thinking and least-privilege design.

This market is moving toward integrated visibility across prevention, detection, and remediation. StepSecurity’s update reflects a broader shift from single-purpose controls to platforms that can identify a compromised component, stop execution, and prove exposure scope quickly. That direction will shape procurement, because teams will increasingly judge tooling on how well it reduces uncertainty after an alert, not only on how well it blocks initial compromise. Practitioners should expect incident scoping to become a buying criterion.

Software delivery governance now has a direct identity security dependency. Reusable secrets, service credentials, and workflow tokens are the practical assets attackers seek after compromise, so supply chain security and NHI governance are converging. The best control sets will connect package trust decisions to secret lifecycle management, revocation, and access scoping. Practitioners should stop treating supply chain and identity controls as separate programmes.

What this signals

The next procurement cycle will reward platforms that can connect prevention to proof. Security teams are under pressure to answer not only whether a malicious component was blocked, but where it ran, what it touched, and whether credentials were exposed before containment.

Pipeline trust fragmentation: the practical failure mode in this category is distributed trust with no single authoritative view. As AI expands code volume and automation, programmes will need controls that span repos, registries, devices, and runtime if they want defensible exposure analysis.

For identity teams, the strategic signal is clear: secrets, workflow tokens, and service credentials now behave like operational identities with lifecycle risk. That makes rotation, revocation, and ownership part of software delivery governance, not a separate afterthought.

For practitioners

• Map trust boundaries across the delivery pipeline Inventory where code can be introduced, executed, and promoted across developer machines, repositories, package registries, and CI/CD runners. Use that map to identify where secrets, tokens, and workflow permissions are exposed to automation.
• Apply runtime containment to build and release workflows Enable egress blocking, workflow cancellation, and package cooldown controls so a compromised dependency cannot freely phone home or harvest credentials during execution.
• Treat workflow tokens and build secrets as governed NHI assets Assign owners, expiration rules, and revocation paths to tokens and service credentials used in automation, then test whether they can be removed quickly when a package or action is flagged.
• Build compromise search into incident response Make it possible to search pull requests, branches, developer machines, and workflow history for a known malicious component so scope can be confirmed before the response window closes.

Key takeaways

• Software supply chain compromise now reaches into the identity layer because secrets, tokens, and workflow permissions are the attacker’s real prize.
• The evidence points to faster attacks, broader code movement, and a stronger need for searchable exposure scoping across machines, repos, and CI/CD.
• Teams should govern automation as privileged infrastructure, with layered containment and explicit lifecycle control for every credential it can touch.

Key terms

• Pipeline Trust Fragmentation: The split of trust and control across developer machines, repositories, registries, and CI/CD systems so no single control can see the whole exposure path. It is a governance problem as much as a technical one because compromise can cross boundaries faster than teams can correlate evidence.
• Software Supply Chain: A software supply chain is the set of tools, identities, dependencies, and processes that turn source code into deployed software. Because it relies on automation and privileged machine identities, it becomes a governance problem when access, signing, and deployment controls are too broad.
• Build Secret Exposure: The loss of credentials, tokens, or API keys during software build or delivery activity. These secrets often sit in automation with broad scope, so a compromise in one workflow can produce access far beyond the original system that was attacked.

What's in the full article

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

• A stage-by-stage view of how Dev Machine Guard, Secure Registry, and Harden-Runner each block compromise in different parts of the pipeline
• Examples of the specific workflow and egress policies used to stop malicious packages from executing or exfiltrating secrets
• The incident search and threat intelligence workflow used to determine whether a compromised component touched developer machines, pull requests, or CI/CD runs
• The product-level release cadence behind the H1 2026 controls and how those releases map to real attack patterns

👉 StepSecurity's full post covers the growth drivers, attack patterns, and control layers behind its H1 2026 update.

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 helps practitioners connect identity lifecycle control to the broader security programmes their pipelines depend on.