By NHI Mgmt Group Editorial TeamPublished 2026-04-10Domain: Best PracticesSource: GitGuardian

TL;DR: Automation that speeds dependency updates can also accelerate malicious package propagation, as GitGuardian shows through recent campaigns involving Dependabot, Renovate, and AI coding agents. The security problem is no longer just poisoned packages, but trusted automation that can move them into production faster than human review can react.


At a glance

What this is: GitGuardian argues that dependency automation, including bots and AI coding agents, is now a practical supply-chain attack path because it can ingest and propagate malicious updates before teams notice.

Why it matters: IAM and NHI teams should treat automated build systems, bot accounts, and agentic tooling as privileged non-human identities that need separate governance, not just software hygiene.

By the numbers:

  • The malicious axios package was uploaded on March 31st at 00:20 am, and the first package.json modification was observed 5 minutes later.
  • Across the infection timeframe, at least 895 public repositories upgraded axios to a malicious version.
  • Of the 527 repositories still available during analysis, 313 were pushed directly to a branch and 214 changes arrived via pull request.
  • 95 of those pull requests, or 60%, were merged into the main branch, including 50 merged by a bot user without user interaction.

👉 Read GitGuardian's analysis of supply-chain automation, bots, and AI agent risk


Context

Software supply-chain attacks succeed when trusted automation is allowed to change code, dependencies, or workflow definitions without enough friction. In NHI terms, the problem is not only malicious packages. It is the non-human identities, bots, and pipeline credentials that are trusted to move those packages through build and release systems.

GitGuardian’s examples point to a governance gap that most IAM programs do not model well: machine-driven changes can inherit standing trust from approved update bots, CI/CD runners, and workflow tokens. That makes dependency automation an access-control problem as much as a software-quality problem.

The article’s starting position is increasingly typical, not exceptional. As more organisations let automation update dependencies and agents write code, the default perimeter shifts from the repository boundary to the automation layer itself.


Key questions

Q: How should teams slow down malicious dependency updates without breaking delivery?

A: Apply time-based controls such as minimum release age or cooldown periods to package managers and automated update bots. The goal is to create a review window between publication and adoption, which gives scanners, maintainers, and responders time to detect poisoned packages before they reach production. This is most effective when paired with branch protection and explicit approval for high-risk changes.

Q: What is the difference between automating dependency updates and granting them blind trust?

A: Automation is a mechanism for efficiency, while trust is a policy decision about what that automation is allowed to change. A bot that opens a pull request is not inherently dangerous, but auto-merging its output without inspection turns convenience into a privileged access path. Teams should separate update creation from update approval and treat bots as governed identities.

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: Should organisations allow pull_request_target for automated dependency workflows?

A: Only with extreme caution. pull_request_target can expose secrets and higher-privilege repository context to workflow code if the workflow itself is modified or abused. For dependency automation, the safer pattern is to minimise privileged triggers, pin reusable workflows carefully, and keep secret-bearing jobs separate from untrusted code execution.


Technical breakdown

Why dependency bots become trusted non-human identities

Dependency bots such as Dependabot and Renovate behave like privileged non-human identities because they are expected, repetitive, and often exempt from the scrutiny applied to human-authored pull requests. That trust is useful for maintenance, but it also creates a fast path for malicious updates when a package or workflow is compromised. The failure mode is not just bad code. It is policy drift, where automation inherits broad write access to dependency graphs, branch updates, or release workflows. In practice, the trust decision is made once and then reused at machine speed.

Practical implication: Treat update bots as governed NHI workloads with scoped permissions, review gates, and separate policy controls.

How workflow compromise turns into secret exposure

Reusable workflows and CI/CD jobs often run with credentials that are invisible to the code author but available to the automation at execution time. If a malicious dependency update changes a workflow file or a pinned commit SHA, the changed workflow can execute as part of the normal pipeline. Whether secrets are exposed depends on the trigger and permissions model. A pull_request run may be limited, but pull_request_target can expose more sensitive context if used carelessly. This is why workflow integrity and secret scope have to be evaluated together, not as separate tasks.

Practical implication: Audit workflow triggers, pinning logic, and secret exposure paths as one control surface.

Why AI coding agents widen the blind spot

AI coding agents extend the attack surface because they can choose their own tooling, install packages, and operate outside the controls teams assume are in place. If an agent updates a lock file or pulls from a public index, the resulting action may never pass through the same review and inventory processes used for production code. The risk is not that AI introduces a totally new class of attack. The risk is that it accelerates existing supply-chain weaknesses into untracked environments where detection is weaker and accountability is unclear.

Practical implication: Inventory agent activity, package manager usage, and unmonitored workspaces before granting code-writing autonomy.


Threat narrative

Attacker objective: The attacker aims to turn trusted automation into a distribution channel for malicious code and credential exposure at production speed.

  1. Entry via a compromised open-source dependency or workflow update that is trusted by automation and merged quickly into code.
  2. Escalation through CI/CD runners, automerge logic, or workflow execution that exposes build-time credentials and repository write paths.
  3. Impact through secret theft, malicious code propagation, or broader lateral movement from the compromised development environment.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

Automation is now a privileged attack path, not a support function. Dependency bots, merge automation, and agentic coding tools can all operate with the authority of a non-human identity. That makes their permissions and triggers part of the access model, not merely part of the delivery process. Security leaders need to govern automated change as they would any other high-trust workload, because the attack path now runs through routine maintenance.

Ephemeral speed creates persistent risk when revocation is slow. The article shows that malicious updates can move from publication to production in minutes, which means the window for human review is too small to rely on as the primary safeguard. The decisive control is not only detection, but constraining how quickly untrusted updates can flow into execution. Practitioners should treat time-to-propagation as an identity and policy issue, not just a DevOps efficiency metric.

AI agents magnify existing NHI governance gaps by adding unsupervised choice. An AI agent that selects packages, tooling, or install methods can bypass the assumptions embedded in standardised build processes. That does not make the threat model new, but it makes it harder to predict. The field now needs policy for autonomous software behaviour, not just policy for human developers.

Identity blast radius is the right concept for modern supply-chain defence. When a bot account, workflow token, or coding agent can alter dependency graphs, the blast radius is defined by what that identity can change before anyone intervenes. This should push organisations toward tighter scope, shorter validity, and better segmentation of automation rights. The practical conclusion is simple: govern the machine actor before it governs your release pipeline.

Version-age controls are becoming a baseline control for software trust. Cool-down periods for dependency updates are not a niche hardening measure anymore. They are a practical way to slow the spread of poisoned packages long enough for advisory systems, SCA tooling, and human review to catch up. Teams that still allow instant adoption of every package update are effectively optimizing for speed over containment.

From our research:

  • 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation, according to The State of Secrets Sprawl 2026.
  • AI-related credential leaks surged 81.5% year-over-year in 2025, with the surrounding AI infrastructure leaking 5x faster than core LLM providers.
  • For a broader control perspective, review OWASP NHI Top 10 for policy patterns that limit autonomous access and reduce blast radius.

What this signals

Identity blast radius is the practical lens for this problem. If a bot, workflow, or coding agent can change dependency state before a human can review it, the question is no longer only whether the package is malicious. The question is how much authority the automation has, how quickly it can act, and how much damage that authority can create across repositories and environments.

With 24,008 unique secrets exposed in MCP configuration files in 2025 alone, the broader lesson is that machine-readable trust paths are now a primary leakage surface. Programs that have not extended inventory, secret revocation, and workflow controls into agent-led environments will keep missing the real point of compromise.

The next control priority is policy enforcement at the edge of automation, not just detection after execution. Teams should slow adoption, narrow workflow privileges, and treat unmonitored developer machines and AI workspaces as part of the governed perimeter, because that is where supply-chain abuse increasingly begins.


For practitioners

  • Classify automation as governed NHI Inventory dependency bots, merge agents, workflow runners, and coding agents as non-human identities with explicit owners, scopes, and review requirements.
  • Add release-age cooldowns to dependency updates Set minimum release age or cooldown thresholds in Renovate, Dependabot, npm, pip, uv, and other package managers so new releases cannot move straight into production.
  • Restrict high-risk workflow triggers Review pull_request_target usage, pinned workflow SHAs, and automerge rules, then remove paths that let workflow changes execute with broad secret access.
  • Segment secrets by pipeline and environment Limit CI/CD credentials to the smallest possible scope and keep build-time secrets separate from repository maintenance, especially where bots can modify files.
  • Monitor untracked AI and developer workspaces Extend inventory and telemetry beyond production repos to experimental projects, local package managers, and agent-driven coding environments that can still fetch and execute code.

Key takeaways

  • Dependency automation now behaves like a privileged NHI layer, which means its permissions and triggers need explicit governance.
  • The scale of exposure is operational, not theoretical, because malicious updates can reach production in minutes when automerge is left unchecked.
  • The right response is to slow trust down, shrink blast radius, and extend controls into AI coding environments and untracked workspaces.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
OWASP Non-Human Identity Top 10NHI-03Dependency automation and cooldowns map to NHI credential and update lifecycle risk.
NIST CSF 2.0PR.AC-4Bot and workflow permissions are access-control decisions in the delivery chain.
NIST Zero Trust (SP 800-207)SP 800-207The article's core issue is implicit trust in machine-driven change.

Set ageing and review controls on automated updates before they can modify production paths.


Key terms

  • Dependency Bot: An automated service that opens, updates, or merges dependency changes on behalf of a repository. In NHI terms, it is a machine identity with the authority to modify code paths and should be governed with scoped access, review boundaries, and clear ownership.
  • Release Cooldown: A time delay applied before a newly published package or update can be adopted by automated systems. It reduces the chance that poisoned releases move immediately into production and gives defenders time to detect, validate, and block suspicious changes.
  • Identity Blast Radius: The amount of damage a non-human identity can cause before it is stopped or revoked. It is shaped by permissions, trigger conditions, secret scope, and the speed of automation, making it a practical measure for NHI governance.
  • Automerge: A workflow pattern that allows approved pull requests to merge without manual intervention. It improves delivery speed, but when paired with weak trust controls it can turn routine maintenance into a high-speed path for malicious code and credential exposure.

What's in the full article

GitGuardian's full article covers the operational detail this post intentionally leaves for the source:

  • Exact Renovate and Dependabot configuration examples for cooldown enforcement and update ageing.
  • Workflow-level hardening patterns for pinned SHAs, automerge rules, and trigger selection.
  • Package-manager-specific examples for npm, pnpm, yarn, pip, and uv settings.
  • Incident-by-incident detail on how the trivy-action and Axios campaigns moved through real repositories.

👉 The full GitGuardian post covers cooldown settings, workflow hardening, and AI agent bypass scenarios.

Deepen your knowledge

Supply-chain automation, secret exposure, and NHI governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your environment includes dependency bots or AI coding agents, this course helps frame the controls you need first.
NHIMG Editorial Note
Published by the NHIMG editorial team on 2026-04-10.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org