On March 31, 2026, at 00:21 UTC, someone published two new versions of Axios to the npm registry versions 1.14.1 and 0.30.4 of the JavaScript HTTP client used in more projects than almost any other package on the platform. Axios sees over 70 million downloads a week flow through Axios. It shows up in CI/CD pipelines, Lambda functions, containerised microservices, internal tooling, and production applications at hundreds of thousands of companies.
Nothing about the updates looked unusual. Minor version bumps. Routine releases. The kind of update that auto-installs across thousands of pipelines without a human ever glancing at it.
The updates weren't from the Axios team. An attacker had compromised the lead maintainer's npm credentials and used them to publish directly to the registry, bypassing the project's normal release process entirely. No repository access needed. Just one set of stolen credentials.
Buried in both releases was a new dependency: plain-crypto-js@4.2.1. The package executed automatically via a post-install hook with no user interaction required. It connected to an attacker-controlled command-and-control server, then dropped a cross-platform remote access trojan onto the host, adapting its payload for Windows, macOS, and Linux. After establishing persistence, the RAT replaced its own installation files with clean decoys.
For approximately two hours and fifty-four minutes between 00:21 and 03:15 UTC anyone running npm install axios received the trojan alongside the HTTP client. Microsoft Threat Intelligence estimates approximately 600,000 installs occurred during that window, and attributed the operation to Sapphire Sleet, a North Korean state actor.
By the time the malicious versions were pulled, the payload had already landed in development environments, build servers, and production systems across a significant fraction of the JavaScript ecosystem.
Nothing caught it: not Axios, not the npm registry, or the CI/CD pipelines that auto-updated, because there was nothing to catch. The package was published with legitimate credentials from a legitimate account. The install process behaved exactly like every other install. The only thing different was what happened after.
This is the defining characteristic of supply chain attacks: they don't break through your security controls. They walk through the front door using credentials your security stack already trusted.
What Is a Supply Chain Attack?
A supply chain attack doesn't compromise your systems directly. It compromises something your systems already trust, a package, a build tool, a vendor's software, trust and uses that trust as the delivery mechanism, the weapon.
The supply chain attack moves through three layers.
Layer 1: The Injection Point
The attacker targets an upstream package, library, or tool, often something small enough to attract little scrutiny but depended on broadly. They insert malicious code here. Nothing has reached a victim yet. No data is being exfiltrated. The attacker is planting a seed in the distribution channel.
The Axios attack is a Layer 1 compromise. So were the attacks on event-stream (2018), where a malicious maintainer was handed ownership of a widely-used Node package and inserted a payload targeting the Copay Bitcoin wallet, and ua-parser-js (2021), where an attacker briefly took over a package with 7 million weekly downloads.
The attacker's calculus at Layer 1 tends toward the same logic: major packages have too many eyes. The better targets are the quiet dependencies three levels deep in someone else's stack maintained by one person, rarely audited, and trusted transitively by applications that have no idea they depend on them.
Layer 2: The Carrier
A commercial or open-source application bundles the compromised dependency into a product it ships to customers. Sometimes the injection and carrier are the same entity. SolarWinds built its own backdoored software. Sometimes it's a separate company that unknowingly shipped someone else's compromise.
The 3CX attack in March 2023 illustrates how this layer can itself be the product of a previous supply chain compromise. A 3CX employee installed a financial trading application called X_TRADER on a personal computer. That application, from a company called Trading Technologies, had already been backdoored by a North Korean threat group VEILEDSIGNAL malware was silently bundled into the X_TRADER installer, which was still available for download even though the product had been discontinued in 2020. From that one infected personal computer, the attacker harvested credentials and moved laterally into 3CX's corporate network. Within months, they had inserted malicious code into the 3CXDesktopApp, a VoIP client used by 600,000 companies worldwide. Mandiant later described this as the first documented case of a software supply chain compromise leading directly to another software supply chain compromise.
Layer 3: The Final Victim
The organisation that installed the compromised software. They received a signed, verified, legitimate-looking update from a vendor they trusted. Their security controls saw nothing unusual. The attacker is now inside their environment. Every organisation across the 18,000 customers running SolarWinds Orion when the SUNBURST backdoor was active is a Layer 3 victim. So are the 1,500 downstream businesses whose managed service providers used Kaseya VSA when REvil exploited a zero-day SQL injection vulnerability (CVE-2021-30116) to push ransomware to all managed endpoints simultaneously.
The key dynamic running through all three layers: each inherits the trust of the layer above it. The victim trusted the carrier. The carrier trusted the upstream package. The attacker exploited that chain of trust, which is exactly why each victim's security controls didn't fire. They were built to trust the same things the attacker had already compromised.
Why Supply Chain Attacks Are Uniquely Dangerous
Three factors combine to make supply chain attacks categorically harder to handle than a direct breach.
Scale Is Built In
A direct breach targets one organisation. A supply chain compromise reaches every customer of the compromised vendor simultaneously, with no additional effort from the attacker. SolarWinds delivered the SUNBURST backdoor to roughly 18,000 organisations in a single update cycle. Kaseya's customer breach cascaded to 1,500 downstream businesses. The attacker's reach scales with the vendor's install base or, in the case of open-source packages, with the downstream dependency graph, which can be enormous.
The Discovery-to-Notification Gap
Even when a supply chain compromise is discovered, the time between 'we know' and 'you know' runs through internal investigation, legal review, regulatory notification timelines, and communications preparation. Customers remain compromised and unaware throughout that entire process.
The SolarWinds timeline is instructive. Attackers first accessed SolarWinds systems in September 2019. Malicious updates began shipping to Orion customers on March 26, 2020. The attackers removed the backdoor from SolarWinds' own environment in June 2020, cleaning their tracks while the payload kept running in 18,000 customer networks. FireEye discovered the intrusion while investigating its own network on December 13, 2020. Customers had been running the SUNBURST backdoor for approximately nine months before any of them knew.
The Detection Gap Is Structural
IBM's 2025 Cost of a Data Breach report found that supply chain and vendor breaches take an average of 267 days to detect, the longest of any attack vector. That figure reflects how the attack is designed, not how fast security teams move. Supply chain attacks are specifically constructed to be indistinguishable from legitimate software behaviour. The signature matches a real package. The behavior stays within expected baselines. The software was installed correctly and is doing exactly what it was installed to do.
Third-party and supply chain breaches now account for 30% of all breaches, a figure that doubled in a single year, and cost organisations an average of $4.91 million per incident, making them the second most expensive attack vector IBM tracked.
What the Industry Has Tried and Where It Falls Short
The security and software communities haven't ignored supply chain risk. There are meaningful efforts to harden the supply chain at each layer.
The SLSA framework (Supply-chain Levels for Software Artifacts), developed by Google and now maintained by the Open Source Security Foundation, provides a four-level maturity model for supply chain integrity. At SLSA Level 1, build platforms automatically generate provenance , or a record of how an artifact was built. Level 2 adds cryptographic verification of build sources and authenticated build environments. Each level closes specific attack vectors: tampered source, compromised build environments, unsigned artifacts.
npm's trusted publishing, now generally available, lets maintainers publish packages using OIDC tokens generated by GitHub Actions or GitLab CI eliminating the long-lived automation tokens that were the attack surface in the Axios compromise. Had jasonsaayman been using trusted publishing instead of a static npm token, Sapphire Sleet would have needed to compromise his GitHub account, not just steal a stored credential. Not impossible, but significantly harder.
Software bills of materials (SBOMs) provide a manifest of every dependency bundled into a shipped product. Biden's Executive Order 14028 required SBOM documentation from software vendors selling to the US federal government, a mandate designed explicitly to address the SolarWinds-class risk where organisations had no visibility into what was actually running in their environment.
Software composition analysis tools scan projects for known vulnerable dependencies and flag them against public vulnerability databases. Most modern CI/CD platforms have SCA built in.
These controls are genuinely valuable. SLSA provenance makes supply chain attacks harder to execute at Layer 1. npm trusted publishing closes the specific credential-theft vector Axios fell to. SBOMs give Layer 3 victims at least some chance of knowing what they're running. SCA catches known-bad packages before they get bundled.
But they share a ceiling. SLSA provenance confirms which pipeline built a package, not whether that pipeline's internal state was clean. npm trusted publishing helps maintainers who've adopted it. The npm ecosystem has hundreds of thousands of packages, many maintained by people who haven't. SBOMs tell you what you installed; they don't tell you whether what you installed is currently being used as a weapon. SCA tools can flag packages with known CVEs; they cannot flag a package that was clean last month and is compromised today.
Every one of these controls operates on prior knowledge: known vulnerabilities, known attack patterns, known build configurations. Supply chain attacks are designed to look like legitimate software. Until someone analyses the malicious payload and publishes a CVE, the package doesn't exist in any threat database. And by the time that happens, the attack has typically been running for months.
AI Is Accelerating the Timeline
Supply chain attacks aren't new. What's changing is the speed at which vulnerabilities can be found, weaponised, and deployed.
In April 2026, the UK's AI Security Institute evaluated Anthropic's Mythos model and found it capable of autonomously attacking small, weakly defended enterprise systems once access to a network had already been gained. More specifically: Mythos became the first AI model to complete a 32-step simulated corporate network attack, built with SpecterOps to model a realistic enterprise intrusion kill chain spanning four subnets and roughly 20 hosts, and solved 73% of expert-level capture-the-flag security challenges.
What matters for supply chain specifically: AI systems can now analyse codebases at scale to find exploitable dependencies faster than any human audit, generate working exploit code from discovered vulnerabilities without manual development effort, and run continuously against many targets simultaneously. The time between 'vulnerable package version exists' and 'exploit is deployed' is collapsing.
We ran our own benchmark on this. In May 2026, we tested ten frontier AI models against a controlled AWS cyber range, 300 resources across common services including S3, IAM, EC2, Lambda, RDS, DynamoDB, Secrets Manager, CodeBuild, and Bedrock, designed to simulate a corporate production account with multiple realistic attack paths. Across 951 attack runs, AI agents achieved admin privilege escalation in 162 cases, taking an average of 14 minutes to do so.
That is the timeline a supply chain payload now operates against. An attacker with AI-assisted capabilities who lands in your environment via a compromised dependency doesn't need days to find a path to sensitive data. They need minutes.
There is an asymmetry here that doesn't change regardless of AI capability improvements. Defenders have to be right across every system, every account, every dependency, continuously. An attacker has to be right once. AI amplifies attacker throughput without resolving this asymmetry, it widens the gap because AI can search for vulnerabilities and execute attacks at a speed that no human-driven detection and response cycle can match.
This is the context in which the 267-day average detection time for supply chain attacks needs to be understood. You're not trying to catch a human attacker working methodically through your environment. You're trying to catch a compromise that may already be running in your environment, using tools that move faster than your SOC can review an alert.
Why Your Detection Stack Doesn't Close This Gap
Every tool in a modern security stack operates on the same underlying assumption: the attack will produce a signal it can recognise.
SIEM platforms ingest logs and match events against known threat signatures or statistical deviations from known baselines. Supply chain attacks produce neither. The compromised software isn't generating anomalous logs, it's generating exactly the logs you'd expect from that software doing its job. The SUNBURST backdoor communicated via legitimate Orion network traffic patterns. The 3CXDesktopApp behaved like a legitimate VoIP client. There's no rule in any SIEM that fires on 'software is doing what it was designed to do, except maliciously.'
EDR monitors endpoints for known malicious behaviour: process injection, unusual parent-child relationships, known malware signatures, deviations from expected execution baselines. SUNBURST ran as a legitimate SolarWinds process with a legitimate signature. The 3CX payload is loaded via a legitimate Windows DLL sideloading mechanism. EDR looks for the abnormal. Trojanised legitimate software is specifically designed to look normal.
CSPM evaluates your cloud configuration against known security benchmarks, open S3 buckets, over-permissioned IAM roles, missing encryption, public exposure. Supply chain attacks don't need misconfigurations. The compromised software inherits the permissions it was legitimately granted.
Vulnerability scanners and software composition analysis tools flag dependencies with known CVEs. They do this by comparing installed packages against databases of known-bad versions. When a package is backdoored for the first time, before any CVE exists, before any researcher has published an analysis, before any signature has been written the package doesn't appear in any database. It's clean. The scanner says so because as far as the scanner knows, it is.
The vendor security questionnaire problem compounds this further. Most enterprise security programmes require vendors to meet baseline security standards before software is approved for deployment. SolarWinds had passed security reviews. 3CX was a trusted communications vendor. Questionnaires evaluate the vendor's security posture at a point in time. They cannot detect when that posture is compromised after the software has already been installed.
The pattern across every one of these tools: they require prior knowledge of the threat to detect it. A signature, a baseline, a known-bad configuration, a vulnerable version number. Supply chain attacks are designed to produce none of these signals. This isn't a failure of the tools. They work. They catch a significant proportion of attacks, and every organisation should run them. But they share a structural blind spot and supply chain attacks are specifically designed to exploit it.
The Only Response That Doesn't Require Prior Knowledge
If the threat is designed to be invisible to controls that rely on knowing what to look for, then the only detection mechanism that doesn't have this limitation is one that doesn't need to know what to look for.
This is what the assumed breach philosophy means in practice, applied specifically to the supply chain: accept that a compromised dependency may reach your environment. Design for detecting the attacker the moment they do anything with the access they've gained not after you've analysed their behaviour, not after threat intel has published a CVE, but immediately, the first time they touch anything.
Every detection tool we've discussed works by prediction trying to anticipate what an attacker looks like. Canaries work by revelation. You deploy resources that look legitimate to an attacker but serve no operational purpose. Anything that touches them is, by definition, something that shouldn't be there. No prediction required. No prior knowledge of the attacker's tooling, methods, or intent. The canary fires because the resource was touched, full stop.
An attacker who lands in your environment via a compromised supply chain dependency needs to do something with that access. They need to enumerate credentials, move laterally, escalate privileges, access data, and establish persistence. Every one of those actions involves touching resources. A well-placed canary sits in the path of those actions.
Why Traditional Honeypots Don't Hold Up
The concept is thirty years old. The execution is the problem.
Traditional honeypots require dedicated server infrastructure to deploy and maintain, regular patching to avoid becoming actual vulnerabilities, careful tuning to avoid false positives from legitimate scanners, and a small number of fixed deployment points. In a modern cloud environment that is dynamic, multi-account, ephemeral, and constantly changing, a handful of static honeypot servers doesn't provide meaningful coverage. A sophisticated attacker (or an AI agent) can enumerate the environment, identify the obvious honeypots by their static characteristics, and navigate around them.
For canaries to work against supply chain attackers operating at AI speed, they need to blend into your specific environment's naming conventions and credential formats, cover every cloud account and CI/CD pipeline not just one network segment, refresh continuously as the environment changes, and deploy through infrastructure-as-code so coverage grows automatically rather than requiring manual placement for every new account or service.
There's a further effect worth stating explicitly: a well-seeded canary environment changes the economics of every attack against you, not just the attacks that trigger a canary. An attacker who knows or suspects that an environment contains decoys can't move through it freely. They have to slow down, second-guess resources, and verify credentials before using them. That uncertainty is itself a cost one that compounds with every canary you add, regardless of whether any canary ever fires. Traditional security tools make defenders faster. Canaries make attackers slower.
Where to Start: 5 Things to Check This Week
You don't need a full canary deployment to start closing this gap. Before you do anything else, check these five things:
- Which of your npm/PyPI/CI publishing workflows still allow a classic access token as a fallback, even if OIDC trusted publishing is configured? A trusted publishing setup with an unrevoked classic token behind it isn't actually closed. This is exactly the gap Axios fell into.
- Whether you know, right now, every package your last production build pulled in. Not what your SBOM says you require, but what actually got installed. If you can't answer this in under five minutes, you have a visibility gap, not just a detection gap.
- How many of your cloud accounts have zero canary or deception coverage today? If the answer is “most of them,” that's your biggest blind spot, not your CI/CD pipeline.
- Do your vendor security reviews have an expiration date? If a vendor was approved once and never reassessed, you're trusting a point-in-time snapshot for an ongoing relationship. Ask when your top five critical vendors were last reviewed.
- What would actually alert you if an attacker did nothing wrong by any of your tools' definitions? If the honest answer is “nothing,” that's the gap the rest of this article is about.
None of these require buying anything. They just tell you where you actually stand.
The Tracebit Approach
Tracebit deploys security canaries across the attack surface that supply chain payloads actually traverse cloud environments, CI/CD pipelines, Kubernetes clusters, developer workstations, and identity systems. When an attacker touches one, you know. That's the mechanism.
Real Cloud Resources, Not Simulated Ones
Tracebit canaries are real AWS, GCP, and Azure resources: S3 buckets, IAM roles, DynamoDB tables, Secrets Manager secrets, SSM parameters. Not emulated endpoints. Not simulated services. Real resources with convincing configuration and realistic-looking data that produce genuine audit trails when accessed including which principal accessed what, from which IP, using which user agent, at exactly what time. An attacker who reads a canary Secrets Manager secret trips a real CloudTrail event. There's no way to distinguish it from touching a production secret, because it is a production-grade resource.
Five Lines of Terraform. Hundreds of Accounts.
Tracebit deploys via infrastructure-as-code. The same configuration that covers one account covers three hundred. Deploy in 30 minutes. No agents, no servers, no dedicated headcount, no months-long professional services engagement. As your environment grows, canary coverage grows with it automatically.
Canaries That Evolve With Your Environment
Tracebit observes your environment's naming conventions, credential formats, and resource patterns, continuously updating canaries to match. A canary that looks like a production credential in your account today still looks like a production credential six months from now, even as your environment changes around it. Static canaries become detectable over time. Tracebit canaries don't have a shelf life.
This matters particularly against AI attackers. Our benchmark showed that more capable models trip more canaries, not fewer because they enumerate everything that looks high-value, which is precisely how Tracebit canaries are designed to look. In the current state, 95.9% of runs that achieved admin privilege escalation had already tripped a canary before their first critical action, with a median lead time of 8 minutes. In a finding we didn't predict: simply telling an AI agent that canaries might be present dropped the full-compromise rate from 20% to 3%.
Mapped to All Three Supply Chain Layers
- Layer 1 Community Edition (the upstream package): Tracebit Community Edition is free. It deploys canary tokens as environment variables inside GitHub projects via GitHub Actions. If the project is compromised, whether through credential theft, a malicious pull request, or a backdoored build tool, and those tokens are exfiltrated, the canary fires. The project maintainer gets an alert before any downstream user is affected. This is the earliest possible detection point in the supply chain: at the source.
- Layer 2 Community Edition + Enterprise (the carrier): Canary credentials seeded inside CI/CD pipelines detect compromises at the build stage before a malicious artifact ships to customers. If a build system is compromised and begins exfiltrating secrets or pushing unauthorizedunauthorised changes, the canary fires during the build, not after deployment. Enterprise coverage extends this to the full cloud environment and developer workstations.
- Layer 3 Enterprise (the final victim): Full coverage across the attack surface a supply chain payload actually traverses after it lands in your environment. Cloud accounts, Kubernetes clusters, developer workstations, identity systems. When an attacker inside your environment via compromised software touches anything they shouldn't, you know with the full forensic context of what they touched, when, and from where.
The Quiet Canary Farm as a Signal
A canary program that never fires is evidence of a safer environment, not evidence that the canaries aren't working. Every day your canary farm stays quiet while supply chain attacks make headlines is a day you can say with confidence, something no SIEM alert absence can tell you that nothing has touched anything it shouldn't. Security tools go quiet for bad reasons all the time. Canaries go quiet because nothing malicious has happened.
The Standard Is Changing
Supply chain attacks are not a new threat category that will be patched away. They are a permanent feature of how software is built and distributed and AI is making the attacks faster, more scalable, and harder to attribute.
The industry's response so far has been to layer more tools that share the same underlying assumption: that attacks will produce a recognisable signal. SLSA provenance, SBOMs, and SCA tools address real gaps in supply chain hardening. They are worth deploying. But they don't close the detection gap for a compromise that has already landed in your environment, is indistinguishable from legitimate software, and is operating with credentials your systems legitimately granted.
The teams that handle this well are the ones that stop asking 'how do we prevent every compromise' and start asking 'how do we know the moment something happens that shouldn't.' That's a different problem. And canaries are what that approach looks like in practice.
The moment an attacker inside your environment touches a canary resource an S3 bucket they shouldn't read, a Secrets Manager secret that has no legitimate purpose, an IAM role no process ever assumes. Not after log correlation. Not after threat intel publishes a signature. Immediately. At the speed AI attackers now move, immediately is the only timeline that matters.
For Security Leaders: See how Tracebit would detect a supply chain compromise in your environment. Book a demo at tracebit.com
For Developers and Open-Source Maintainers: Deploy canary tokens in your GitHub project in minutes. Free, forever. community.tracebit.com
