The New Era of Software Supply Chain Risk

Modern businesses are now software businesses, and software supply chain risk is now a business risk, not just a developer problem. Whether you manufacture industrial components, process financial transactions, run logistics networks, or operate online storefronts, your business likely depends on ERP systems, customer portals, payment integrations, cloud workloads, APIs, automation scripts, and other layers of code assembled from open-source components, third-party libraries, SaaS tooling, and CI/CD workflows.

In practice, very few organisations write most of what they run. They assemble it; the modern software stack is inherited as much as it is built. That is exactly why software supply chain risk deserves closer attention. When people hear “software supply chain attack”, they often think of something like Log4Shell or MOVEit: a widely used component with a vulnerability that attackers exploit. But three recent incidents involving the Axios npm ecosystem, the LiteLLM AI proxy package, and the Trivy security scanner suggest an interesting evolution in tactics that is worth examining more closely.

Three Incidents That Redefine Software Supply Chain Risk

A trio of recent software supply chain incidents demonstrate a shift towards compromising the mechanisms that publish, automate, and validate software itself. Here is what happened in each case.

1. Axios

Axios is one of the most widely used JavaScript libraries for making HTTP requests. In practical terms, it is embedded inside:

• Web applications that communicate with backend APIs
• SaaS platforms that integrate with third-party services
• Internal enterprise dashboards pulling data from microservices
• Payment, logistics, CRM, and analytics systems making outbound API calls

If your business runs modern web applications built on Node.js or frontend frameworks such as React or Vue, Axios is often part of the dependency tree — sometimes directly, often indirectly. In this case, reported in March 2026, threat actors compromised a maintainer account (an authorised developer account with permission to publish official updates to the package) and published malicious versions of Axios to npm.

The malicious update introduced a phantom dependency containing a remote access trojan (RAT). That dependency was not visible in the official GitHub repository. Instead, the attacker manually published poisoned versions using a stolen npm token.

Crucially, this bypassed GitHub Actions’ OIDC Trusted Publisher safeguards. Because the release did not originate from the official automated workflow, provenance signals were effectively sidestepped.

For downstream businesses, nothing looked abnormal. Developers pulling the latest version through standard dependency resolution would ingest the malicious code automatically.

2. Trivy

Trivy is a widely used open-source vulnerability scanner integrated into CI/CD pipelines via a GitHub Action. Thousands of development projects use it to scan container images and infrastructure code before deployment. It is used to detect vulnerabilities in container images and cloud-native artefacts. Many companies use it as part of:

• CI/CD pipelines to block vulnerable builds
• Container registry scanning
• Infrastructure-as-Code validation
• Compliance workflows

In late March 2026, attackers hijacked Trivy GitHub Actions components. That allowed them to access a highly privileged automation account used to manage releases. From there, they were able to steal a publishing token that granted them the same permissions as a trusted maintainer. Although Aqua Security rotated credentials after disclosure, attackers retained access to valid tokens.

On 19 March, the attackers used the stolen automation credentials to quietly replace almost all of the official release references for Trivy’s GitHub integration with malicious versions of the code. To anyone installing or updating the tool through normal automation, nothing appeared unusual; they were pulling what looked like legitimate releases.

Crucially, the legitimate Trivy scan still ran afterwards, producing expected output. There was no vulnerability in the scanner engine itself. But the modified version of the Trivy integration was designed to harvest sensitive information from any build system that executed it. It searched the build environment for stored cloud credentials, SSH keys, and other secrets, encrypted the data, and sent it to an attacker-controlled server.

The compromise occurred in the release and automation layer, specifically in the GitHub Action distribution mechanism that downstream CI pipelines trusted.

3. LiteLLM

LiteLLM acts as a proxy layer that allows applications to communicate with multiple large language model providers through a unified interface. In many AI-enabled businesses, LiteLLM can sit between:

• Customer-facing AI features
• Internal knowledge assistants
• Automated decision engines
• API-driven AI workflows

In short, it often handles requests that include API keys, credentials, prompts, proprietary data, and internal configuration details.

In the reported compromise, malicious versions of LiteLLM were uploaded to PyPI. In an interesting multi-ecosystem link to the Trivy incident, this compromise began when LiteLLM’s CI pipeline ran the compromised Trivy GitHub Action.

When the poisoned Trivy Action executed inside LiteLLM’s CI environment, it harvested secrets from the CI runner, including PyPI publishing tokens and GitHub Personal Access Tokens. Those stolen credentials were then used to publish malicious versions 1.82.7 and 1.82.8 to PyPI.

The malicious LiteLLM versions deployed a three-stage payload:

• Credential harvesting targeting more than 50 categories of secrets
• Kubernetes lateral movement tooling
• A persistent backdoor enabling remote code execution

Again, there was no vulnerability in LiteLLM’s proxy logic being exploited in production. The compromise occurred as a downstream consequence of a compromised security tool embedded in its CI pipeline. Then, automated CI/CD pipelines that pulled the latest package version of LiteLLM incorporated the malicious code without any need for attackers to directly breach enterprise environments.

How Software Supply Chain Risk Is Shifting

For the last few years, software supply chain risk was largely framed around vulnerable code or trusted software compromise. Think of Log4Shell and MOVEit, or the build-system compromise seen in SolarWinds. The pattern was familiar: a defect or upstream compromise existed in widely deployed software, attackers discovered or leveraged it, and organisations raced to patch or respond before compromise spread.

These three recent incidents show attackers targeting the systems that build, sign, tag, publish, and distribute software components. Modern software development is highly automated. Code is merged, tested, packaged, and published through CI/CD pipelines. Packages are consumed automatically via dependency managers. GitHub Actions, PyPI, npm, and container registries serve as trusted distribution channels.

These systems are designed for speed and implicit trust. Attackers have recognised that compromising this layer offers disproportionate leverage.

Rather than:

• Discovering a zero-day
• Building a reliable exploit chain
• Targeting each organisation individually

They can:

• Compromise a maintainer identity
• Steal a publishing token
• Manipulate release tags
• Poison a CI workflow

Then allow automation to propagate the malicious code at scale. Every CI pipeline, every automated build, and every dependency update is part of what is effectively a software factory. It is a production line that turns source code into deployed systems at speed.

That factory now powers revenue-generating applications, customer platforms, logistics systems, AI services, payment integrations, and cloud infrastructure. For many organisations, it is as critical as a manufacturing plant or energy supply chain.

Yet governance over this software factory has not matured at the same pace as its operational importance. Another defining feature of this evolution is systemic interconnection. When one upstream tool is compromised, that trust relationship becomes a propagation mechanism.

As the threat model for software supply chain attacks shifts from exploiting code to exploiting distribution authority, the weakest point may well become the governance layer around applications: structured governance over identities, release authority, third-party tooling, and automation controls. A mature GRC framework aligns these technical safeguards with business risk priorities.

What This Means for Organisations Now

That is why software supply chain risk can no longer be treated as a narrow application security problem. It is a governance issue that sits at the intersection of identity, release authority, third-party tooling, and automation. Organisations that want to reduce this exposure need more than faster patching. They need clearer ownership, stronger controls over build and release processes, and better visibility into where trust is being inherited by default.

If your organisation is reviewing its exposure to software supply chain risk, contact us now..