Why your supply chain attack surface is expanding

Published April 7, 2026 · Updated October 29, 2026

The first attacker was an agent.

In late February 2026, an autonomous bot that described itself as an AI security research agent found a misconfigured GitHub Actions workflow in Trivy, one of the most widely used open source vulnerability scanners, and took an organization-wide token. Three weeks later, attackers used the access that survived the cleanup to backdoor Trivy itself. From there, the campaign reached Checkmarx KICS, LiteLLM, and more.

One agent. One misconfigured workflow. Thousands of organizations downstream.

We first published this post in April. Since then, the pattern has repeated, and it has sped up. In April and May, the Mini Shai-Hulud worm hit hundreds of npm and PyPI packages. On October 21, LiteLLM was compromised a second time, and the malicious release reached both PyPI and Docker Hub images. Mandiant now estimates the mean time to exploit at minus seven days: attackers routinely exploit a flaw before a patch exists.

Your supply chain attack surface is still expanding, and faster than it was in April. This update covers what changed, and the Sonar capabilities that shipped since to close the new gaps: reachability analysis, container scanning, and dependency checks inside the coding agent.

What happened in March

In the span of eight days, a threat group called TeamPCP quietly pulled off one of the most sophisticated coordinated supply chain campaigns the industry has seen. First, on March 19, they backdoored Trivy's GitHub Action and release binary, using credentials that had survived Aqua's cleanup after the earlier breach. The poisoned action dumped CI runner memory to steal pipeline secrets from the workflows that ran it.

Then, because LiteLLM's build pipeline ran Trivy without pinning to a specific version, those stolen credentials became the key that unlocked LiteLLM's PyPI publishing account. On March 24, two backdoored versions of the AI gateway library (with roughly 95 million downloads a month) were live, silently harvesting SSH keys, cloud credentials, Kubernetes tokens, and database passwords from any environment that installed them.

And then, just days later, in a separate incident, an attacker took over the npm account of Axios's lead maintainer and published two malicious versions that installed a cross-platform remote access trojan. Axios is JavaScript's most popular HTTP client, present in roughly 80% of cloud and code environments, according to Wiz.

March 2026 was a wake-up call for anyone who thinks software supply chain security begins and ends with CVEs. Over the course of a few days attackers compromised trusted tooling, abused build pipelines, and pushed malicious code through ecosystems that millions of developers rely on. October 2026 brought the sequel. LiteLLM's release pipeline was compromised again, and version 1.107.0 shipped credential-stealing malware to PyPI and to Docker Hub images for less than three hours. By then, researchers had linked data stolen in the March attack to nearly 2,500 corporate domains. The real lesson is bigger than any one incident: your attack surface now includes every dependency you import, every pipeline secret you expose, every container image you ship, and every AI tool your software developers trust. Verizon's 2026 Data Breach Investigations Report puts a number on it: 48% of breaches now involve a third party, up from 30% a year earlier.

How supply chain attacks cascade

The most dangerous supply chain attacks are not random. They are designed to cascade. They follow a deliberate logic that exploits the way most software teams operate.

Step 1: Find a weak link in the supply chain. An attacker starts with a weak link: a misconfigured CI/CD workflow, a stale maintainer account with a weak password, a package that runs without version pinning in another project's build process, or a dependency an AI agent added without checking it. Any of these is enough to get a foothold.

Step 2: Use that foothold to reach a bigger target. Compromising one component can create access to thousands of downstream builds, releases, and environments. TeamPCP didn't just want Trivy users. They were after the thousands of projects that run Trivy inside their own pipelines. Compromise the scanner, steal the credentials, publish backdoored versions of whatever the scanner is building. This is the "cascading" part of a cascading supply chain attack.

Step 3: Make the malicious package look legitimate. This is what makes these attacks so hard to catch; the malicious package still appears to work, the scanner still scans. The backdoored LiteLLM versions still functioned as expected. The poisoned Trivy action still ran scans. The malicious Axios releases left Axios's own code untouched; the only change was one hidden dependency. The attack was designed to be invisible to anything that only checks whether software works, not whether software is safe.

This is the fundamental problem with how most teams evaluate their dependencies: functionality is a poor proxy for security.

Why does traditional AppSec miss modern supply chain attacks?

Most teams already run a vulnerability scanner in CI, check for known CVEs, or rely on a package registry's reputation signals. These controls still matter, but they address a different problem.

CVE databases are built to track bugs in legitimate code. That creates two gaps. First, there is an inherent lag: it typically takes days to weeks from discovery to a scored, scannable CVE entry. During that window you are exposed even with continuous scanning. Second, and more importantly, CVE databases don't cover malicious packages at all. A package intentionally written to steal credentials or persist a backdoor may have no CVE, a clean version history, and a seemingly trusted publisher. The Axios attack made this concrete. The attacker pre-staged the payload under a clean package name (plain-crypto-js), double-obfuscated the dropper, and targeted Windows, macOS, and Linux. Nothing in any CVE database would have flagged it. No CVE was ever issued; malicious packages are tracked separately, in databases like OSV.

Volume is the third gap. The National Vulnerability Database logged more than 72,000 CVEs in the first nine months of 2026, already more than in all of 2025. A typical dependency tree pulls in hundreds or thousands of packages, and most of the CVEs found in them sit in code paths your application never runs. When everything is critical, nothing is, and the vulnerabilities that matter get lost in the queue.

Another blind spot is your own code. A vulnerable library does far more damage when your application passes unsanitized data through it straight into a sensitive operation, such as a database call, an authentication check, or an API endpoint. Detecting the malicious package is necessary but not sufficient if the code around it amplifies the damage.

And code and dependency scans never see the layer underneath: the operating system packages, runtimes, and libraries inside the container images you ship. On October 21, the PHP2Shell flaws (CVE-2026-109618 and CVE-2026-109619) landed exactly there, in the PHP runtime rather than in anyone's application code.

How SonarQube helps secure your supply chain

If the software supply chain is now the attack surface, then securing it requires more than one control. It requires protecting four layers at once: what you consume, what you ship, what builds your software, and what helps write your code.

That is where SonarQube changes the equation. Rather than treating supply chain security as a downstream audit, it brings these protections into the software developer workflow, where teams can prevent compromised components and unsafe code from moving forward in the first place. Some of these controls are part of core SonarQube. Others come with SonarQube Advanced Security, available on SonarQube Cloud (Team and Enterprise plans) and SonarQube Server Enterprise. Each one is labeled below.

Here is how each step of a supply chain attack maps to a Sonar control:

Malicious package detection (Advanced Security). This is the capability that directly addresses what happened with LiteLLM and Axios. SonarQube Advanced Security checks your third-party dependencies against a continuously updated database of known malicious packages, not just packages with CVEs, but packages confirmed to contain intentional malware, backdoors, or credential stealers. When a malicious package is detected, it is always raised at BLOCKER severity, not as a low-severity warning, and it can fail your quality gate. The same check now runs inside coding agents too (see "Dependency checks inside the agent loop" below).

One important caveat: a quality gate runs alongside the build pipeline, not before it. A failing gate blocks merging or releasing. It does not prevent the build runner or a developer's local machine from having already executed the dependency. Any environment that pulled the package should be treated as potentially compromised and credentials rotated regardless. What detection gives you is two things: it stops the blast radius from spreading to production and downstream environments, and it gives you an immediate signal to start your incident response.

Secrets detection (SonarQube). TeamPCP's entire strategy depended on being able to steal secrets from CI/CD environments. Secrets detection does not stop a token from being stolen out of a running CI job. What it does is shrink the supply of credentials sitting in code, where attackers and agents can find them. SonarQube detects accidentally committed secrets, such as API keys, tokens, cloud credentials, and database passwords, at three points: in your IDE with SonarQube for IDE, in your terminal and coding agent with the SonarQube CLI, and again in the CI/CD pipeline. More than 400 secret patterns cover 248 cloud services. The early checks matter most. By the time a secret reaches a git commit, it may already be in a pull request, a code review, or a branch that will be cloned by others. The Trivy timeline makes the other half of the point: the March 19 attack worked because the credential rotation after the earlier breach was incomplete. Finding and rotating every exposed secret, quickly and completely, is what stops a cascade.

Software composition analysis (SCA) (Advanced Security). Beyond malicious packages, SonarQube's SCA identifies public vulnerabilities in both your direct dependencies and your transitive ones (the packages that your packages depend on), which is often where the real risk lives. Each risk is prioritized by severity (CVSS) and by exploitability, using EPSS and CISA's Known Exploited Vulnerabilities (KEV) list.

When a vulnerability does require action, SonarQube provides a specific fix recommendation (the exact version to upgrade to) rather than leaving your team to figure out remediation on their own. Sonar also partners directly with select open source maintainers to validate vulnerabilities, including guidance on whether a finding is a genuine risk or a false positive in typical usage scenarios. You also get automated license compliance checking, so a dependency with a license that conflicts with your distribution model gets flagged before it becomes a legal problem.

Reachability analysis (Advanced Security). Knowing a dependency is vulnerable is not the same as knowing you are exposed. For every vulnerability in a third-party dependency, SonarQube runs a call graph analysis of your code and marks the risk Reachable, Unreachable, or Not analyzed. Reachable risks go to the front of the queue. Unreachable lowers the threat but does not clear it, since other paths can still exist. Reachability is supported for Java/Kotlin, Python, and C#/VB.NET, runs during full analysis in CI or automatic analysis, and needs no extra configuration. If you use the SonarQube Remediation Agent, it can open a pull request that bumps a reachable dependency to a fixed version.

SBOM generation (Advanced Security). You cannot protect what you cannot see. SonarQube Advanced Security generates and maintains a Software Bill of Materials (SBOM) for your applications in CycloneDX and SPDX formats: a precise, exportable inventory of every dependency in your software, the version in use, and its current security status. SBOMs are the evidence regulators and customers now ask for. Since September 11, 2026, the EU Cyber Resilience Act has required manufacturers to report actively exploited vulnerabilities in their products, which is hard to do without knowing what is in them. In the US, federal agencies now set software security requirements case by case, after OMB rescinded the mandatory attestation memos in January 2026. Either way, an SBOM is the foundation for any credible supply chain security program.

Container scanning (open beta, Advanced Security on SonarQube Cloud). Run the SonarQube container scanner against an image, locally or in CI. It generates an SBOM for the image and checks the operating system packages, runtimes, and libraries inside it for known vulnerabilities and malicious packages. By default it fails the build on high-severity risks or above, and you can change the threshold. Results appear under Container images in the SonarQube interface, next to your code and dependency risks, and SonarQube Cloud re-checks analyzed images as new vulnerabilities are published, so you do not need to re-scan to learn about them. Container scanning is in open beta on SonarQube Cloud for Team and Enterprise plans with Advanced Security, at no additional cost. SonarQube Server support is planned.

Advanced SAST with cross-boundary taint analysis (Advanced Security). This is what separates Advanced Security from standard static code analysis. Standard SAST traces data flows within your own code. Advanced SAST is dependency-aware analysis that traces data flows across the boundary between your code and third-party libraries, catching vulnerabilities that only emerge from the specific way your code interacts with external packages. When untrusted data flows through a third-party library and reaches a sensitive sink, Advanced SAST traces the full path and reports it. It finds injection flaws, not malware, so it complements malicious package detection rather than replacing it. The analysis works cross-file and cross-function, which is how real applications are actually structured. Advanced SAST supports Java and C#.

CI/CD pipeline misconfiguration detection (SonarQube). The Trivy attack did not begin with a malicious package or a compromised dependency. It began with a misconfigured GitHub Actions workflow. A pull_request_target workflow that ran with write permissions on untrusted code gave an autonomous bot the opening it needed to steal an organization-wide token belonging to the aqua-bot service account. This class of vulnerability is something SonarQube detects directly. SonarQube checks GitHub Actions workflows against the security practices most often violated in real pipelines: unpinned external actions, unsafe pull_request_target workflows like the one behind the Trivy breach, script injection, and more. It also scans Azure Pipelines, including detection of script injection vulnerabilities, parameter injection attacks, external task invocations without a pinned version, and shell script execution during package installation. These misconfigurations are the entry points attackers look for first. Finding them in your pipeline definitions before an attacker does closes the door before the cascade begins.

Flaws no one has catalogued yet (SonarQube Hunter Agent, needs subscription). Every control above depends on something already being known: a malicious package in a feed, a CVE in a database, a misconfiguration pattern. The Trivy story shows the gap. The first move was made by an AI agent, and attackers now use AI to find flaws before anyone has catalogued them. Even heavily reviewed open source code hides them: in internal testing, SonarQube Hunter Agent has surfaced more than 200 zero-day vulnerabilities across popular, well-audited open source projects. Point it at your own most exposed services to find broken access control and business logic flaws before someone else's AI does. It is generally available on SonarQube Cloud for the Enterprise plan.

Findings in pull requests. All of these signals (malicious packages, vulnerable dependencies, secrets, and taint analysis findings) are surfaced directly in pull request comments. Developers do not need to switch to a separate dashboard or wait for a security team to triage a report. The feedback arrives in the same place the code review is happening, at the moment when a developer is already thinking about that specific change.

The attack surfaces that most teams haven't thought about yet

There is also a newer class of attack that takes the cascade logic one step further. It targets not just what your application runs, but what your developers, and their agents, use to write it. Package registries and CI/CD pipelines are not the only targets. There is a growing category of supply chain attack that goes after the AI coding tools your developers use every day. In May, the Mini Shai-Hulud worm showed where this is heading: it wrote a hook into each infected project's Claude Code settings, and a matching VS Code task, so the malware ran again silently every time a developer opened the project. It then copied the same hooks into other repositories on the machine.

Dependency checks inside the agent loop (Sonar Vortex and SonarQube CLI). Coding agents now add packages on their own, and they often reach for stale or vulnerable versions they saw in training data. Sometimes they install packages that do not exist at all, and attackers register those invented names first. Only 48% of developers say they always verify AI-assisted code before committing it. Sonar Vortex checks the exact package version before the agent edits the manifest and returns vulnerability, malware, and license data, so the agent can refuse a malicious package or propose a safe version. A SonarQube CLI pre-commit hook then scans the project's dependencies, including the transitive ones a new package pulls in, and blocks the commit when it finds new risks at MEDIUM severity or above. Both checks need SonarQube Advanced Security with SCA enabled. See a full walkthrough in You need dependency checks in your AI coding workflow.

Rules file backdoor detection. AI coding assistants like GitHub Copilot and Cursor operate based on instruction files that developers (and projects) maintain to define coding standards and behavior: files like .cursorrules, .mdc, .windsurfrules, .clinerules, and .github/copilot-instructions.md. Researchers at Pillar Security disclosed in early 2025 that attackers can weaponize these files by embedding malicious instructions using invisible Unicode characters, such as zero-width joiners and bidirectional text markers. These characters are completely invisible to a human reading the file, but an LLM processes them as normal text and follows the instructions they contain. A poisoned rules file can silently instruct the AI to insert backdoors, weaken cryptography, or introduce hardcoded credentials into every piece of code it generates. The attack also often survives project forking, spreading to any team that clones or forks the repository.

SonarQube has rules that specifically detect these hidden Unicode sequences in AI coding assistant configuration files and any file that could influence AI code generation. The same files that developers typically gloss over in a code review are now subject to the same analysis as source code. When a suspicious pattern is detected, it is flagged as an issue at analysis time, so the file can be fixed before it shapes more generated code.

Secret leakage through AI coding agents. There is a subtler threat that most teams have not thought through yet. AI coding tools like Claude Code function by scanning your local environment to build context for their suggestions, which means they can inadvertently ingest active session tokens, API keys, database credentials, and .env files, then send that sensitive data to an LLM provider's servers as part of the prompt. Those secrets are then persisted in the provider's gateway request logs, often in plain text. It is no longer a local mistake; it is an enterprise liability sitting in an external log file.

This is no longer hypothetical. LiteLLM's October incident report says the attacker lifted GitHub tokens from the logs of an internet-exposed internal LiteLLM deployment and used them to take over its release workflow. LiteLLM also noted that, in specific situations, Claude Code embeds a user's GitHub CLI OAuth token in a response body, so the token can end up in gateway logs.

The SonarQube CLI closes the most common path: credentials that reach the model through prompts and files. Run sonar integrate claude and it installs hooks in Claude Code that scan each prompt and every file the agent reads or writes, before anything leaves the machine. The same command sets up hooks for Codex, GitHub Copilot CLI, Cursor, and Antigravity, though coverage varies by agent. With an average processing time of about 100ms per file in Sonar's internal testing and a false positive rate below 5%, it checks every agent edit and intercepts secrets before they ever reach an LLM provider.

Prompt injection in application code. A separate but related risk applies to applications that call LLM APIs directly, such as AI gateways, chatbots, RAG pipelines, and agent frameworks. If your application passes unsanitized external input (from a user, a document, a database field) into a prompt without validation, an attacker can craft that input to override the prompt's instructions and cause the model to behave in unintended ways. This is OWASP's LLM01:2025, prompt injection, and OWASP ranks it first in its Top 10 for LLM applications. SonarQube's taint analysis engine traces data flows from untrusted external sources through your application code to LLM API calls, using the same cross-function, cross-file analysis used for SQL injection and XSS detection, applied to the AI layer of your application. This rule (S7518) covers Java and Python.

Make the quality gate your supply chain control point

All of these capabilities are most powerful when they are backed by a quality gate that is configured to enforce policy.

A quality gate in SonarQube is a pass/fail policy applied to every scan. You define what counts as acceptable: no critical vulnerabilities, no malicious packages, no exposed secrets, no license violations. When a scan finds something outside those boundaries, the quality gate fails, and a pipeline that waits on the gate stops the change from moving forward. A quality gate is not a dashboard for later review. It is the enforcement point inside the developer workflow, at the moment when the risk is cheapest to fix and easiest to contain. Container scanning applies the same idea to images: the scanner can fail the build at a severity you choose.

The Axios attack window was approximately three hours between the malicious packages going live on npm and being removed. A quality gate means that once a malicious package is flagged, every pipeline that encounters it stops automatically. No alert to catch, no ticket to triage, no policy to update manually. The caveat is that this protection only kicks in once the package appears in threat intelligence feeds, and there is always some lag between publication and confirmed detection. The goal is to minimize that window and ensure the response is automatic when it closes.

A different way to think about this

The attacks of this year are a symptom of a deeper assumption the industry has been getting wrong: that open source packages are essentially trustworthy until proven otherwise, and that security is something you add on top of a working software delivery process.

Supply chain attacks invert that assumption. The modern threat is not limited to the code your developers write. It is in everything your software touches. Every dependency is a potential vector. Every CI/CD secret is a potential key. Every unreviewed package update is a potential backdoor. Every package an agent adds without checking is a potential foothold.

SonarQube does not make this problem disappear completely. But it does mean that every scan, every pull request, every pipeline run is checking not just whether your code works, but whether it is safe. SonarQube checks your own code, your dependencies, your secrets, your licenses, your pipelines, your AI configuration files, the data flows into your AI-integrated services, and now the container images you ship.

That is the shift the industry needs to make. And it needs to happen inside the developer workflow, not downstream in a security audit six weeks after you're exposed.

Shrink your attack surface, one layer at a time

Attackers needed one agent and one misconfigured workflow. Closing the gaps takes four checks, one for each layer:

1. What you consume. Turn on malicious package detection, add a quality gate condition that fails on it, and fix Reachable dependency risks first.
2. What you ship. Run the Sonar container scanner on the images you build (open beta on SonarQube Cloud).
3. What builds your software. Fix what SonarQube flags in your GitHub Actions and Azure Pipelines workflows, starting with unpinned actions and pull_request_target triggers.
4. What helps write your code. Add the SonarQube CLI hook and Sonar Vortex to your coding agents, so leaked secrets and risky packages are caught on the developer's machine, before the commit.

Start with one critical project: request a free trial of SonarQube Advanced Security.