How Strobes AI Turns a Supply Chain Zero-Day into a Full Exposure Assessment in Under 30 Minutes

At 00:21 UTC on March 31, 2026, threat actors published a backdoored version of the axios npm package, one of the most widely used HTTP client libraries in the JavaScript ecosystem with roughly 83 million weekly downloads. Within minutes of the first community disclosure, our team fed the initial intelligence into Strobes AI and asked a simple question: what are we exposed to, and what do we do about it?

What happened next is the subject of this post. Not the attack itself, which we covered in detail in our technical breakdown of the axios compromise, but what it looks like when an AI-native Continuous Threat Exposure Management (CTEM) platform responds to a supply chain zero-day in real time. From initial alert to a 42KB incident response report, complete with 12 novel findings that went beyond any public advisory, remediation tasks assigned to the right teams, and a full blast radius map across every affected repository.

The Problem: You Know There Is an Attack. Now What?

When a supply chain compromise like the axios incident breaks, security teams face a problem that scanners and SIEMs were never designed to solve. The malicious code arrives through a trusted channel. It self-destructs after execution. Your vulnerability scanner has no signature for it yet. Your SIEM sees HTTP traffic to an unknown domain, but so does half the internet.

The real questions are operational, not detection-oriented. Which of our applications depend on axios? Which ones pulled the compromised version during the three-hour attack window? Did any CI/CD pipeline run npm install without a lockfile? Are there Docker images built during that window sitting in our container registry right now? Which developer workstations need credential rotation?

These are exposure assessment questions, not vulnerability management questions. And answering them requires a fundamentally different operating model than the one most security programs run today.

How Strobes AI Responded: A Real-Time Walkthrough

When the axios compromise was identified, we initiated the Strobes AI incident response workflow. The platform operates on a multi-agent architecture, meaning it does not run a single analysis sequentially. Instead, it decomposes the problem into parallel workstreams and assigns specialized agents to each one, all reasoning concurrently using Claude Opus 4.6 as the backbone.

Here is exactly what happened, in order.

Phase 1: Parallel Investigation (Minutes 0 to 15)

The Strobes AI Supervisor analyzed the initial intelligence (a GitHub Gist from Elastic Security researcher Joe Desimone) and immediately decomposed the investigation into four parallel tracks, each assigned to a specialized agent:

A Threat Intel Agent performed deep intelligence enrichment: DNS enumeration on the C2 domain, IP geolocation and ASN mapping, Shodan and AlienVault OTX lookups, certificate transparency checks, and WHOIS analysis. It correlated indicators across seven sources simultaneously and confirmed the C2 at 142.11.206.73 was already offline.

A Code Review Agent recovered the actual malicious payload from jsdelivr CDN cache (the npm registry had already unpublished the packages), deobfuscated the XOR-encrypted command strings using the key OrDeR_7077, and mapped the complete delivery chain across all three target platforms: macOS, Windows, and Linux.

A Registry Analysis Agent fetched full npm registry metadata for both axios and plain-crypto-js, verified provenance attestations (confirming the critical gap between the SLSA-attested legitimate release and the unattested malicious one), and retrieved download statistics to quantify the blast radius.

An Exposure Assessment Agent evaluated every asset registered in the Strobes environment, determining which systems had Node.js stacks, which were likely to have run npm install during the three-hour attack window, and which environments had lockfile enforcement that may have provided protection.

Phase 2: Novel Discovery (Minutes 15 to 25)

After the initial investigation completed, the Strobes AI Supervisor reviewed the 60KB+ of evidence collected across all four agents and identified unexplored angles that no public advisory had covered. It then spawned a second wave of four additional agents to pursue these leads:

This second wave investigated infrastructure pivoting (reverse IP lookups, passive DNS, historical Shodan data), cross-ecosystem attacker hunting (checking if the threat actor had accounts on PyPI, RubyGems, crates.io, and GitHub), malware sample hunting across MalwareBazaar, VirusTotal, and Hybrid Analysis, and deep CDN cache extraction to recover artifacts that npm had already unpublished.

Phase 3: 12 Novel Findings (Minute 25 to 30)

The investigation produced 12 findings that went beyond anything available in public security advisories, the StepSecurity blog, Socket.dev reports, or any other published analysis at the time.

The most significant discoveries included a precursor campaign using the identical obfuscation toolkit published two weeks before the axios attack, a second attacker account that staged the malicious dependency, CDN caches actively distributing malware with one-year immutable cache headers, and confirmation that the second-stage payloads remain completely unrecovered across all public malware databases globally.

Why This Matters: Exposure Assessment Is Not Vulnerability Scanning

A traditional vulnerability scanner would have been useless during the first hours of this incident. There was no CVE for the supply chain compromise (CVE-2026-25639 is a separate denial-of-service issue). There was no signature. The malicious code was designed to self-destruct after execution, leaving node_modules looking completely clean.

What was needed was not scanning. It was exposure assessment: understanding which assets were reachable by the threat, which ones were actually affected, and what the blast radius looked like in the context of the specific environment.

This is the fundamental difference between vulnerability management and exposure assessment. Vulnerability scanning tells you what is theoretically weak. Exposure assessment tells you what is actually at risk given your specific infrastructure, your specific dependencies, and your specific attack window.

The Role of Attack Surface Management in Supply Chain Response

One of the reasons Strobes was able to respond so quickly is that the platform already maintained a continuous inventory of the entire attack surface. When the axios compromise broke, the Exposure Assessment Agent did not need to start from scratch discovering which repositories existed or which applications used Node.js. That information was already indexed through Strobes Attack Surface Management.

Continuous attack surface monitoring meant that the platform could immediately cross-reference the compromised package versions against the known dependency graph. Repositories that used axios were already catalogued. CI/CD pipelines were already mapped. The question shifted from "do we use axios?" to "which specific builds between 00:21 and 03:15 UTC pulled the compromised version?" That level of specificity is only possible when discovery has already been done continuously, not triggered reactively by an incident.

SBOM: The Foundation for Supply Chain Blast Radius Mapping

The speed of the exposure assessment was directly tied to the availability of Software Bills of Materials (SBOMs) across the monitored environment. Organizations that generate and maintain SBOMs for production deployments can answer the question "are we affected?" within minutes of a supply chain disclosure. Organizations that do not maintain SBOMs are left manually grepping through lockfiles across hundreds of repositories.

Strobes integrates SBOM data directly into the exposure assessment workflow. When a new supply chain compromise is identified, the platform can immediately query SBOM records to identify every application, every build artifact, and every deployed container that includes the affected dependency. This is not a manual process. The AI agents perform this correlation autonomously, producing a prioritized list of affected assets ranked by business criticality and exposure confidence.

From Findings to Remediation: Closing the Loop

Identifying exposure is only half the problem. The other half is driving remediation to closure. During the axios response, Strobes AI did not just produce a report. It created structured remediation tasks, automatically prioritized by asset criticality and exposure confidence, and assigned them to the appropriate teams.

This is what outcome-driven security looks like in practice. The platform moved from alert to investigation to exposure mapping to task creation in a single continuous workflow. No handoffs between tools. No copy-pasting IOCs from one dashboard to another. No waiting for a human to read a PDF and manually create Jira tickets.

The remediation guidance was tiered by urgency. Immediate actions (block the C2 domain, downgrade axios, rotate credentials on affected machines) were separated from short-term hardening (rebuild CI artifacts, deploy YARA rules, audit Docker images) and long-term structural improvements (enable npm provenance verification, implement SBOM scanning in CI, deploy pre-install dependency scanning).

The AI Agent Architecture That Makes This Possible

The speed and depth of this response is a direct consequence of the Strobes AI agent stack. The platform runs 12 purpose-built offensive security agents, each specialized for a different aspect of the CTEM lifecycle. For incident response specifically, the relevant agents include the Threat Intel Agent (intelligence enrichment and correlation), the Exposure Assessment Agent (blast radius mapping against the asset inventory), and the Report Writer Agent (synthesizing findings into structured deliverables).

The AI harness architecture is what makes these agents reliable in a security context. Unlike a general-purpose chatbot, the harness enforces scope constraints, manages state across dozens of tool calls, handles authentication and rate limiting, and provides human-in-the-loop governance for high-impact actions. The model provides the intelligence. The harness makes that intelligence operationally safe.

During the axios investigation, the agents collectively leveraged over 78 tools: web searches, CVE database lookups, DNS resolution, CDN probing, npm registry API calls, WHOIS queries, threat intelligence feed correlation, and more. Each tool call was streamed in real time, meaning the security team could watch the investigation unfold and intervene at any point.

What This Means for Your Supply Chain Security Program

The axios compromise is not an outlier. It is part of a sustained escalation in supply chain attacks that has included the Shai-Hulud worm campaign, the LiteLLM PyPI compromise (which we covered in detail), the TeamPCP Trivy campaign, and dozens of smaller incidents across npm, PyPI, and other ecosystems throughout 2025 and 2026.

The common pattern across all of these incidents is that traditional security tooling fails at the point of supply chain compromise. Scanners have no signatures. SIEMs see noise. The malicious code arrives through trusted channels and often self-destructs before detection. The only effective response model combines continuous attack surface monitoring, maintained SBOMs, and the ability to rapidly assess exposure across the entire environment when a new threat is disclosed.

This is the operational model that CTEM was designed to enable. Not periodic scanning followed by manual triage, but continuous monitoring, adversarial validation, and automated response that scales with the speed of modern attacks.

Key Takeaways

• Exposure assessment beats vulnerability scanning for supply chain incidents. When there is no CVE and no signature, the only way to determine impact is to map the blast radius against your actual dependency graph and asset inventory.
• Continuous attack surface monitoring is a prerequisite for fast response. If you have to discover your assets during an incident, you have already lost critical hours. ASM should be running continuously so the data is ready when you need it.
• SBOMs are not just a compliance checkbox. They are the operational foundation for supply chain blast radius mapping. Generate them for every production deployment and keep them current.
• AI agents enable parallel investigation at a scale humans cannot match. The axios response involved eight concurrent investigation tracks across 78+ tools. A human analyst running these sequentially would have taken days, not minutes.
• The gap between detection and remediation is where risk lives. Identifying the threat is necessary but not sufficient. The value is in connecting findings to specific assets, prioritizing by business impact, and creating remediation tasks that reach the right teams automatically.
• Supply chain attacks will continue accelerating. Build the operational infrastructure now: SBOM generation, lockfile enforcement, npm provenance verification, npm ci in all pipelines, and a CTEM platform that can correlate supply chain intelligence against your attack surface in real time.

For the full technical analysis of the axios npm supply chain compromise including the attack timeline, decoded payload analysis, complete IOC table, and detection rules, see our companion post: Axios npm Supply Chain Attack: 83M Weekly Downloads Compromised by Cross-Platform RAT.