Two Incidents, One Registry, Zero Excuses

On March 31, 2026, the npm package registry, the single largest software distribution platform in the JavaScript ecosystem, was at the center of two separate cybersecurity events within hours of each other. In the first, Anthropic accidentally leaked over 512,000 lines of Claude Code source code after a debugging file was inadvertently bundled into a routine update and pushed to the public registry, exposing the full architecture and unreleased features of one of the most prominent AI coding tools on the market (Axios, 2026). In the second, a North Korean threat group tracked by Google Threat Intelligence as UNC1069 hijacked the axios JavaScript library downloaded roughly 100 million times per week and present in approximately 80 percent of cloud environments by compromising the lead maintainer’s npm account and publishing two malicious versions containing a cross-platform remote access trojan that reached an estimated 600,000 installations before removal (CyberScoop, 2026; Google Threat Intelligence, 2026). Neither incident involved a zero-day exploit or a sophisticated intrusion that bypassed advanced defenses. Both were failures of frameworks, policies, procedures, and controls, precisely the pillars we are discussing this week. What makes these events particularly instructive is that NIST Special Publication 800-161r1, Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations, already provides a comprehensive framework for preventing exactly this type of compromise. The publication defines C-SCRM as a systematic process for managing cybersecurity risks throughout the supply chain, operating across three enterprise levels: Level 1 for enterprise-wide strategy and governance; Level 2 for mission and business processes; and Level 3 for operational, system-specific controls (NIST, 2022). Both incidents demonstrate what happens when organizations fail to implement the controls this framework prescribes, and both trace back to the same registry infrastructure.

The Anthropic leak is a textbook example of what NIST 800-161r1 warns about at the operational level. A source map file used internally for debugging obfuscated code was accidentally included in npm version 2.1.88 of Claude Code. That file pointed directly to a cloud storage archive containing nearly 2,000 TypeScript files comprising the tool’s complete codebase (The Hacker News, 2026). This was not some edge case that no framework could anticipate; it maps directly to failures across multiple C-SCRM control families. SR-1 (Policy and Procedures) requires organizations to develop C-SCRM policies at Level 1 that define what is and is not acceptable for software release, and C-SCRM procedures at Level 3 that specify the step-by-step instructions for packaging and publishing code. In 800-161r1’s own language, enterprise functions including information security, legal, risk management, and acquisition should review and concur on these policies and procedures. Anthropic apparently had no documented procedure, no checklist, no gate, no sign-off step requiring an engineer to verify that debug artifacts had been stripped before publishing to a public registry. SI-7 (Software, Firmware, and Information Integrity) and its enhancement SI-7(14) on code authentication call for integrity verification mechanisms at every stage of the software development lifecycle, a simple validation gate in the CI/CD pipeline, checking the .npmignore configuration, or scanning the build artifact for source map references would have caught this before it ever reached npm. Configuration management controls CM-2 and CM-3, which address baseline configurations and configuration change control, exist precisely to prevent situations where a single packaging error cascades into an entirely new attack surface. And cascade it did: within hours of the leak, attackers published malicious packages through dependency confusion attacks targeting developers who attempted to rebuild the leaked source code (The Hacker News, 2026). This was the second time in 13 months that Anthropic leaked its own source code through the same mechanism, undermining its positioning as a safety-first AI company and raising serious questions about whether any Level 2 mission-level risk assessment was conducted after the first incident to prevent recurrence.

The Axios compromise, by contrast, was not an accident but a deliberate nation-state supply chain attack, and it exposes framework and policy failures at the ecosystem level that NIST 800-161r1 was specifically designed to address. UNC1069 compromised the primary axios maintainer’s npm account by obtaining a long-lived classic access token, bypassing the OIDC Trusted Publisher mechanism that npm offers as an optional security feature but does not mandate (StepSecurity, 2026). The attacker staged the operation methodically: a clean decoy package called plain-crypto-js version 4.2.0 was published a full day before the malicious 4.2.1 payload, and then two poisoned axios versions were released within thirty-nine minutes of each other. The injected trojan called home to its command-and-control server within two seconds of npm install, before npm even finished resolving dependencies, and deployed platform-specific payloads across macOS, Windows, and Linux that scraped credentials and established persistent backdoors (StepSecurity, 2026). This maps directly to several 800-161r1 controls and, critically, to the framework's distinction between policies and controls. At the policy level, npm has no organizational rule requiring maintainers of critical packages to use cryptographically bound authentication. OIDC Trusted Publisher is a feature, not an enforced policy expectation. SR-5 (Acquisition Strategies, Tools, and Methods) calls for using acquisition processes that ensure the integrity of acquired components, and any organization writing a C-SCRM policy aligned with SR-5 would define a rule that high-criticality dependencies must originate from verified, cryptographically signed build pipelines. npm’s voluntary model fails this standard entirely because it allows maintainers of packages with hundreds of millions of weekly downloads to authenticate using static tokens with no expiration and no binding to a verified source. At the controls level, SR-11 (Component Authenticity) requires enterprises to develop anti-counterfeit policies and procedures and to implement controls that verify the provenance and integrity of components before deployment. The framework specifically calls for input from and coordination with acquisition, information technology, IT security, legal, and the C-SCRM PMO in developing these controls (NIST, 2022). The malicious Axios versions lacked corresponding GitHub commits or tags, a fundamental authenticity indicator that any organization with an SR-11-aligned control would have flagged immediately (StepSecurity, 2026). SR-3 (Supply Chain Controls and Processes) further requires enterprises to establish processes that identify and address weaknesses in supply chain elements, including software dependencies, and its enhancement SR-3(1) on a diverse supply base pushes organizations to identify single points of failure, which is exactly what a single compromised maintainer account for a package used in 80 percent of cloud environments represents. And yes, the irony of citing Axios, the news organization, while discussing Axios, the compromised npm library, is not lost on me.

What ties these two incidents together is the uncomfortable reality that the npm registry now functions as critical digital infrastructure for virtually every organization that builds or deploys software, yet it remains largely ungoverned by any mandatory supply chain risk management framework. NIST 800-161r1 provides exactly the kind of multilevel governance model the software supply chain needs. Its three-tier approach, enterprise strategy and policy at Level 1, mission-specific risk assessment and procedures at Level 2, and operational controls at the system level at Level 3, maps cleanly onto the problem. The framework even includes templates in Appendix D for C-SCRM strategy documents, policies, plans, and risk assessments, and Appendix F specifically addresses software supply chain security in response to Executive Order 14028 on Improving the Nation’s Cybersecurity (NIST, 2022). The guidance exists. The controls are defined. The problem is adoption and enforcement. For the private sector, 800-161r1 is voluntary. Anthropic, a company valued at tens of billions of dollars that handles sensitive enterprise and government workloads, failed to implement basic Level 3 release packaging procedures twice. npm’s OIDC Trusted Publisher mechanism, which would have prevented the axios account compromise entirely, remains optional for even the most critical packages in the ecosystem. When a single compromised maintainer account can deliver a North Korean remote access trojan to 600,000 installations in under three hours, and when a single misconfigured build artifact can expose half a million lines of proprietary source code for an AI tool used across government and industry, voluntary adoption of supply chain risk management frameworks is no longer a defensible position. The controls prescribed in NIST 800-161r1, from SR-1 policy and procedures to SR-3 supply chain processes to SR-11 component authenticity to SI-7 integrity verification, are not aspirational suggestions. They are the minimum standard any serious organization should enforce across every dependency it consumes and every artifact it publishes.