Automation is now part of the supply-chain attack surface

At a glance

What this is: GitGuardian argues that automation is no longer just a delivery efficiency for dependency updates, it is also a propagation channel for malicious packages and workflow changes.

Why it matters: For IAM, NHI, and platform teams, this matters because bots and agents with write access can move untrusted code faster than human review or vulnerability disclosure cycles can react.

By the numbers:

• At least 895 public repositories upgraded axios to a malicious version during the infection timeframe.
• 95 of those pull requests, or 60%, were merged into the main branch without any user interaction.
• The malicious dependency update was triggered at h+40mn and merged at h+56mn in one showcased repository.

👉 Read GitGuardian's analysis of automation in the software supply-chain attack surface

Context

Software supply-chain attacks now travel through the same automation that teams use to keep dependencies current. The core problem is not only poisoned packages, but the trust placed in bots, merge queues, reusable workflows, and agent-driven installs that can move changes into production faster than people can inspect them.

In this article, GitGuardian ties recent incidents to a broader governance gap: automation has become part of the attack surface. That changes how practitioners should think about CI/CD controls, dependency age policies, and the machines where developers and agents run installs.

Key questions

Q: What breaks when dependency bots can merge malicious updates too quickly?

A: Review stops being a meaningful control when automation can move a package from publication to production in minutes. The failure is not only malicious code, but the assumption that human approval arrives before the attack has already propagated. Teams need timing controls, not just code scanning.

Q: Why do automated dependency updates increase supply-chain risk?

A: They reduce friction for routine maintenance, but they also inherit trust and can be merged without scrutiny. That combination makes them ideal carriers for poisoned packages, compromised workflow pins, and malicious release timing. The risk grows when automerge is allowed to bypass normal review discipline.

Q: What are the signs that access governance is failing in a supply chain environment?

A: Common warning signs include excessive privileges, incomplete onboarding and offboarding, weak access certification coverage, poor log review, and users or vendors retaining access they no longer need. If monitoring cannot quickly surface unusual activity, or if multiple people can complete critical tasks without separation of duties, access governance is not controlling third-party risk effectively.

Q: How should teams balance dependency automation with incident readiness?

A: Use cooldowns, limit high-privilege triggers, and keep install surfaces under inventory so that compromised updates do not spread unchecked. If secrets have already been exposed through automation, containment has to focus on revocation, workflow review, and repository-wide search for affected paths.

Technical breakdown

How trusted automation accelerates malicious dependency propagation

Dependency bots such as Dependabot and Renovate are designed to reduce manual effort by opening or updating pull requests when new package versions appear. The security weakness is that these updates often inherit routine trust, especially when they are automated, expected, and tied to ordinary maintenance work. If malicious code lands in a package release window, the bot can carry it into a repository before anyone has a chance to validate the change. This is not a flaw in update automation alone. It is a timing problem created by implicit trust, short review cycles, and merge paths that treat automation as less risky than human-authored changes.

Practical implication: Treat bot-authored dependency updates as a distinct trust class and add delay or verification controls before they can reach production.

Why reusable workflows and pinned SHAs can still be exploited

Reusable workflows and pinned commit SHAs are meant to add immutability to CI/CD dependencies. In practice, those protections weaken when an automated component updates the pin or swaps in a malicious workflow version inside the same maintenance process. If the workflow runs on pull request events, the damage may be limited by read-only permissions; if it runs on pull_request_target, secrets and broader privileges can become available to the malicious code. The architectural issue is that update automation can modify the very mechanism that was supposed to provide stability. The control boundary therefore has to include the automation that manages workflow integrity, not just the workflow file itself.

Practical implication: Separate workflow integrity checks from automation that updates workflow pins, and restrict high-privilege triggers that expose secrets.

How AI coding agents widen the supply-chain perimeter

AI coding agents change the scale of the attack surface because they can choose dependencies, install packages, and alter lock files without following the same patterns a controlled build system would use. GitGuardian describes a case where an agent updated a uv lock file in an unmonitored experiment, which triggered malware download and execution. That is not a new threat class so much as a perimeter expansion: the install surface now includes ad hoc developer machines, experimental projects, and whatever package manager the agent decides to use. The governance gap is that these environments often sit outside inventory, monitoring, and release discipline.

Practical implication: Bring developer workstations, experiments, and agent-run installs into the same control perimeter as production build systems.

Threat narrative

Attacker objective: The attacker aims to turn trusted automation into a fast distribution channel for malicious code, secrets exposure, and wider repository compromise.

1. Entry occurred when a malicious dependency or workflow version was published and then pulled in by automated tooling such as Dependabot, Renovate, or an AI coding agent.
2. Credential access or execution followed when the automation installed the package, updated the workflow pin, or ran the malicious code as part of routine CI/CD or local execution.
3. Escalation and lateral movement occurred when the compromised automation touched additional repositories, branches, or secrets-bearing workflows, expanding the blast radius beyond the original project.
4. Impact was the rapid propagation of poisoned code or secret exposure into production paths before human review or disclosure could interrupt the chain.

Breaches seen in the wild

• CircleCI breach 2023: Malware stole a CircleCI engineer's SSO session; attackers exfiltrated customers' CI/CD secrets and keys, forcing a platform-wide rotation.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Automation has become part of the supply-chain control plane. The old boundary between code review and operational control no longer holds when bots and agents can open, update, and merge dependency changes. That means the governance question is no longer only whether a package is trusted, but whether the automated path that carries it is trusted enough to write into production. Practitioners should treat automation as a governed identity with its own blast radius.

Short review windows are now a structural weakness, not just a process gap. The article shows how malicious packages can move from publication to production in minutes when automerge and CI/CD approval paths are left open. That compresses the window in which vulnerability scanners, human reviewers, and advisory feeds can act. The implication is that control design must assume the attacker can outrun the disclosure cycle.

Agent-driven installs expand the perimeter beyond monitored production systems. When an AI coding agent chooses a package manager, updates a lock file, or reaches for a public index inside an experiment, the security programme loses the comfort of a stable build boundary. This is where governance and endpoint control meet: if the machine is not inventoried, the install path is not controlled. Practitioners should treat untracked developer environments as part of the supply-chain estate, not as outside it.

Cooldown policy is a timing control, not a complete defence. Version age rules reduce exposure to fresh malicious releases, but they do not solve secret leakage, workflow misuse, or compromised automation identities. The deeper issue is that trusted automation can act faster than the organisation can validate what it has accepted. Teams should therefore rethink privilege, timing, and approval together rather than isolating dependency hygiene from access governance.

From our research library:

• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Guide to the Secret Sprawl Challenge

What this signals

Release-age policy is now an identity control as much as a build control. When bots and agents can write to dependency graphs, the security team is governing a non-human actor that can move faster than a human reviewer. Cooldown periods and merge restrictions therefore function as blast-radius controls, not just software hygiene.

Secrets observability remains the decisive backstop. Recent incidents show that the real damage often appears after a dependency or workflow compromise, when hidden credentials are already available for lateral movement or exfiltration. That makes honeytokens, leak detection, and inventory of developer machines part of supply-chain defence, not optional extras.

For practitioners

• Enforce release-age delays on dependency updates Set minimum release age or cooldown periods on Dependabot, Renovate, npm, uv, and similar tools so new releases cannot be merged immediately into build paths.
• Block automated updates to immutable workflow pins Prevent automation from changing pinned reusable workflow SHAs or digest references unless a separate integrity review approves the new version.
• Restrict high-privilege pull request triggers Review pull_request_target and similar triggers so secrets are not exposed to code that has not yet been validated in a trusted context.
• Inventory developer and agent-run install surfaces Map which workstations, experiments, and agent-driven environments can install packages or modify lock files, then bring them under monitoring and policy.
• Add canary secrets and honeytokens to exposed paths Plant decoy credentials where CI/CD automation, package installs, or agent actions might surface secrets so misuse is detected earlier.

Key takeaways

• Automation can now accelerate malicious dependencies into production, which turns trusted maintenance workflows into an attack path.
• The compromise window can be extremely short, with bot-authored updates merged in minutes and across hundreds of repositories.
• Cooldowns, workflow pin restrictions, and secrets observability are the controls most likely to slow propagation and limit blast radius.

Key terms

• Dependency Automation: Dependency automation is the use of bots or agents to open, update, or merge package changes with minimal human effort. In supply-chain security, it becomes a governance problem when automated updates inherit trust and can move unvetted code faster than reviewers can inspect it.
• Cooldown Period: A policy delay that prevents immediate use of newly published dependencies. It gives defenders a short window to detect malicious releases before they are automatically adopted into build and deployment pipelines.
• Dependency Pinning: Dependency pinning means fixing a project to specific package versions instead of always pulling the newest release. It reduces surprise upgrades and gives security teams time to evaluate whether a new package version is trustworthy before it enters production.
• Supply-Chain Automation Perimeter: The supply-chain automation perimeter is the set of bots, CI/CD jobs, developer machines, and agent-run installs that can change dependencies or workflow execution. It is broader than production build infrastructure because it includes the systems that decide what enters the build in the first place.

What's in the full article

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

• Examples of bot-authored pull requests that were merged without human interaction
• Configuration snippets for cooldown policies in Renovate, Dependabot, npm, and uv
• Workflow pinning guidance for reusable CI/CD components and immutable version tags
• Observations from the LiteLLM and axios campaigns that show how agent-driven installs change the perimeter

👉 The full GitGuardian article covers dependency bot behaviour, workflow pinning, and cooldown settings in more detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.