Why your supply chain attack surface is expanding

TLDR overview

• Supply chain attacks exploit open source dependencies, CI/CD pipelines, and AI tools to inject malicious code and steal credentials. Recent breaches involving Trivy, KICS, LiteLLM, and Axios show how one misconfigured workflow can cascade into millions of backdoored downstream installs.
• SonarQube Advanced Security mitigates such attacks at the developer workflow — detecting malicious packages, exposed secrets, and CI/CD misconfigurations before they move downstream. It includes SCA with reachability analysis and CI/CD misconfiguration detection that CVE scanning can't reach.
• AI coding tools add new supply chain risk: hidden Unicode instructions in assistant config files can silently backdoor AI-generated code, and agents like Claude Code can inadvertently leak credentials to LLM providers. SonarQube detects both.

March 2026 has been a brutal month for open source trust.

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, they compromised Trivy (a widely used open-source vulnerability scanner) by exploiting a misconfigured GitHub Actions workflow to steal CI/CD pipeline secrets. 

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. Within hours, two backdoored versions of the AI gateway library (used by 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, a separate attacker compromised a maintainer account for Axios and published two malicious versions containing a fully featured remote access trojan. Axios is JavaScript's most popular HTTP client, present in roughly 80% of cloud environments. 

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. The real lesson is bigger than any one incident : your attack surface now includes every dependency you import, every pipeline secret you expose, and every AI tool your software developers trust.

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. 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 passed automated tests. 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.

There is also a newer class of attack that takes this logic one step further — targeting not just what your application runs, but what your developers use to write it.

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.

The other  blind spot is your own code. Supply chain attacks frequently succeed because application code passes unsanitized data from a compromised package straight into a sensitive operation — a database call, an authentication check, an API endpoint. Detecting the malicious package is necessary but not sufficient if the code around it amplifies the damage.

How SonarQube Advanced Security 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 three layers at once: what you consume, what builds your software, and what helps write your code. 

That is where SonarQube Advanced Security 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. 

Malicious package detection. 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 surfaced as a critical issue, not just a low-severity warning, and your quality gate fails.

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. TeamPCP's entire strategy depended on being able to steal secrets from CI/CD environments. SonarQube detects accidentally committed secrets — API keys, tokens, cloud credentials, database passwords — at two points: directly in your IDE via SonarQube for IDE before the code is ever committed, and again in the CI/CD pipeline as a second check. Hundreds of detection patterns cover all major cloud providers and services. The IDE check is the critical one — 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. Had secrets been detected and rotated before they were exposed in Trivy's pipeline, the cascade to LiteLLM may have stopped at the first step.

Software composition analysis (SCA). 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. Critically, SCA includes reachability analysis: rather than alerting you to every CVE in every package you've installed, it determines whether the vulnerable code path is actually called by your application. A vulnerability in a library you depend on is much less urgent if your code never exercises the affected function. This distinction is what separates actionable security findings from a noise-heavy list that developers learn to ignore. 

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.

SBOM generation. You cannot protect what you cannot see. SonarQube Advanced Security generates and maintains a Software Bill of Materials for your applications in standard formats, including CycloneDX — a precise, exportable inventory of every dependency in your software, the version in use, and its current security status. This is increasingly required for regulatory compliance (including US Executive Order 14028 and EU Cyber Resilience Act requirements), and it's the foundation for any credible supply chain security program.

Advanced SAST with cross-boundary taint analysis. 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. If a compromised dependency introduces a tainted data source, and your code passes that data into a sensitive sink, Advanced SAST will find it. The analysis works cross-file and cross-function, which is how real applications are actually structured.

CI/CD pipeline misconfiguration detection. 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 automated bot the opening it needed to dump runner memory and extract the aqua-bot PAT. This class of vulnerability is something SonarQube detects directly. SonarQube scans for GitHub Actions workflows covering the security best practices most commonly violated in real pipelines — unpinned external actions, overly permissive workflow triggers, script injection vectors, 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.

Findings in pull requests. All of these signals — malicious packages, vulnerable dependencies, secrets, 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

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.

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 — specifically characters from the Unicode Tag block (range U+E0000 to U+E007F). 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 — and the attack 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 before any developer's next AI-assisted coding session.

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 — and that 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.

The recently released SonarQube CLI addresses this directly. It integrates with Claude Code as a mandatory pre-capture hook, scanning every code snippet the agent produces in real time before it leaves the local environment. With a processing time under 100ms per file and a false positive rate below 5%, it operates as a continuous security perimeter around the agentic coding workflow — intercepting 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 — AI gateways, chatbots, RAG pipelines, 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 it is now one of the most commonly exploited vulnerabilities in AI-integrated applications. SonarQube's taint analysis engine traces data flows from untrusted external sources through your application code to LLM API calls — the same cross-function, cross-file analysis used for SQL injection and XSS detection, applied to the AI layer of your application.

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 build fails and nothing moves 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.

The Axios attack window was approximately three hours between the malicious packages going live on npm and being removed. A quality gate guarantees that the moment 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 this month 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.

SonarQube Advanced Security 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. The code security solution scans your own code, your dependencies, your secrets, your licenses, your AI configuration files, and the data flows into your AI-integrated services.

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. 

Interested in seeing SonarQube Advanced Security in action? Visit sonarsource.com/products/sonarqube/advanced-security to learn more.

Interested in learning more about software supply chain security. Visit https://www.sonarsource.com/solutions/software-supply-chain-security/