How to prevent supply chain attacks in 2026

In March 2026, five widely used open-source projects, Trivy, KICS, LiteLLM, Telnyx, and Axios, were compromised within twelve days. Axios alone accounts for roughly 100 million weekly npm downloads and runs in approximately 80% of cloud and code environments. LiteLLM, an AI infrastructure library, was present in an estimated 36% of cloud environments at the time of its compromise. These projects are load-bearing pieces of the software ecosystem, and millions of applications run on them.

Another name on the list that deserves a second look is Trivy. Trivy is an open-source vulnerability scanner built specifically to detect supply chain compromises, and what followed its compromise made it more than an ironic footnote. Credentials harvested from that breach were reused to authenticate as a legitimate publisher and execute malicious code injections into KICS, a completely separate static analysis tool, turning one compromised project into a stepping stone for the next.

TLDR

In every case, the attack entered through a tool the target already trusted, ran code with legitimate pipeline privileges, and exfiltrated whatever credentials it could reach. This article covers how that chain works and how to break it.

How supply chain attacks work

Every software supply chain attack follows the same playbook. An attacker compromises a trusted tool somewhere upstream, whether through a hijacked account, a misconfigured workflow, or a poisoned release.

When your development environments pull that third-party software during a routine install, the malicious code executes inside your system with the same privileged access as any legitimate process. From that position, it enumerates every credential the process can reach and ships them out, as shown in the image below.

The supply chain attack lifecycle

In March 2026, ran this playbook twice in quick succession through different entry points. Trivy's entry point was a misconfigured pull_request_target GitHub Actions workflow. Attackers exploited it to steal a Personal Access Token with broad admin and repository scope across dozens of workflows, then force-pushed malicious code to the trivy-action and setup-trivy repositories, redirecting trusted version tags to code they controlled. Any pipeline that pulled Trivy during that window executed attacker-controlled code within its own CI/CD environment, using its own credentials.

Axios took a different route: attackers hijacked the npm account and published malicious package versions directly to the registry. They injected a fake runtime dependency and triggered it automatically through a postinstall hook, the moment a developer or pipeline ran npm install. The attack required no user interaction.

In both cases, the outcome was the same. The malicious code swept everything the process could reach: cloud credentials, Kubernetes secrets, SSH keys, .env files, Docker registry tokens, database connection strings, and shell histories. All of it was exfiltrated to attacker-controlled infrastructure. How much damage followed depended entirely on where those credentials lived.

Why does credential location determine blast radius?

Across all five March 2026 security incidents, the organizations that suffered a full data breach had one thing in common. Their credentials were stored on the machines where compromised code ran.

Organizations that had moved credentials into centralized infrastructure did not suffer the same outcome, because the compromised code running inside their environments found nothing to harvest.

Local vs. Centralized Secrets Management

The reason comes down to how process execution works. When malicious code runs inside a CI/CD pipeline or on a developer's machine, it runs as that process, inheriting its file system access, environment variables, and network permissions. Your build runner has access to your cloud services, Kubernetes configuration, and SSH keys. So does anything that executes inside it. The attack surface is not the compromised tool itself; it is the credential footprint of the environment in which it runs.

You will not prevent every compromised dependency from executing, but you can control what it finds when it does. Beyond credential architecture, detection is your next line of defense.

Detecting anomalous behavior before it becomes a data breach

Once malicious code is running in your environment, its behavior can be detected before credentials leave it. Apply the following controls to catch the malicious activity in time.

Monitor for sensitive data enumeration

In a supply chain attack, malicious code runs within a legitimate process, so detection based on process names or known malware signatures will miss it entirely. What you can detect is behavior. When a process starts sweeping through .env files, cloud credential directories, Kubernetes secret paths, and SSH key stores in rapid succession, that pattern is the signal. A legitimate build process does not need to touch all of those in sequence. Build your detection rules around this kind of access behavior at the file system and audit log level, not around what the process is called.

Plant canary credentials

A canary token is a fake credential placed alongside your real credentials in locations an infostealer would sweep, such as .env files, cloud credential directories, and CI/CD configuration files. Because it has no legitimate use, any process that reads it deviates from normal behavior and is acting like a harvester. The canary fires before the attacker reaches anything real, giving you a detection signal with no false positives.

Rotate everything on confirmed compromise

Do not wait for proof of exfiltration before acting. The Axios RAT ran for roughly three hours before it was pulled, enough time to sweep credentials from thousands of machines. The moment a compromise is confirmed, treat every credential accessible to affected runners as stolen, rotate all of them, and use audit logs to reconstruct the full exposure window.

Many supply chain attacks go undetected for days. Behavioral monitoring and canary tokens close that window before a third-party data breach reaches customer data or intellectual property. The next line of control is to reduce how often that window opens in the first place.

Security measures to prevent supply chain attacks

The distribution processes behind the March 2026 attacks were not novel. Each had a known countermeasure.

• Scope workflow permissions to the minimum required: Apply the principle of least privilege in your access management workflow. A security scanning workflow does not need deployment access. A dependency audit job does not need publish permissions. Scope the GITHUB_TOKEN and service account credentials per workflow rather than at the repository level.
• Audit the privilege level of tools you run in CI/CD: Scanners and infrastructure utilities often request elevated access to improve coverage. A tool running with admin credentials or privileged accounts is a high-value target for cyberattacks. Evaluate whether that scope is necessary for your use case.
• Pin dependencies to commit SHAs: Both Trivy and Axios used tag manipulation to redirect trusted version references to malicious code. Pinning to an immutable commit SHA means your pipeline runs the exact code that was reviewed, regardless of what an attacker changes behind the tag afterward.
• Disable postinstall scripts in CI/CD pipelines: The Axios payload required no user interaction; it was triggered automatically by a postinstall hook during npm install. Running npm ci --ignore-scripts removes this delivery class from your pipeline environments entirely.
• Use lock files and commit them: A pipeline resolving dependencies fresh on every run executes whatever the registry currently serves. Lock files bind every build to the exact versions that were reviewed.

Even with these controls in place, assume a dependency will eventually get through. The controls below address what an attacker finds when it does.

How to limit the blast radius when dependencies are compromised

Start with credential scope. The Trivy PAT had broad repo and admin access across 33 workflows, and that scope became the blast radius. Had it been scoped to the specific repositories and permissions each workflow actually required, the damage would have been a fraction of what it became. Every pipeline role, service account, and API key should have access only to the resources its specific job needs.

Beyond scope, token lifetime matters. The credentials harvested from the Trivy breach remained valid days later, when attackers reused them to compromise KICS. Short-lived credentials issued through OpenID Connect (OIDC) would have expired long before they could be weaponized against a second target. An OIDC token is bound to a single job run and expires when the job run ends, so a stolen token is useless outside the window during which it was issued.

Rotate credentials immediately upon confirmation of exposure. The Axios RAT was active for roughly three hours before it was detected and pulled, but the credentials it harvested from developer machines and build servers remained live long after. Sapphire Sleet, the North Korean state actor behind the Axios attack, was documented using harvested credentials in follow-on campaigns weeks later. The window between confirmed compromise and completed rotation is the active risk period.

Where to put the credentials instead

The March 2026 attacks revealed a blind spot in standard supply chain security practice. Dependency scanning, vendor reviews, and code signing all fire before a tool runs. By the time a compromised dependency is executing inside your pipeline, every one of those checks has already passed it through.

The organizations that contained the damage had made one structural choice rooted in zero-trust architecture. Credentials lived in server-side infrastructure, away from the environments where package code executes. The fix is the same structural choice: move credentials to a centralized manager, scope each credential to the minimum required, and automate rotation so a confirmed compromise does not leave an open window. When those three things are in place, a compromised dependency executes inside your environment and finds nothing to take.

To see credentials moved server-side, scoped by environment, and rotating automatically across your infrastructure, try a Doppler demo.