— Introduction
This whitepaper examines the technical root causes of a couple of recent supply chain incidents, quantifies the blast radius, and provides prescriptive controls for engineering and DevSecOps teams responsible for securing software supply chains and release pipelines.
01 Incident Overview
1.1 Anthropic Claude Code Source Map Leak
A JavaScript source map (.map file) is a development artifact that maps compiled/minified output back to its original human-readable source. It is strictly an internal debugging tool and has no legitimate place in a published npm package. On March 31, 2026, Anthropic published one to the public npm registry, in the @anthropic-ai/claude-code package, due to oversight — a 59.8 MB file exposing roughly 513,000 lines of unobfuscated TypeScript across 1,906 files.
1.2 Axios Supply Chain Attack
Independently, a threat actor compromised an npm maintainer account and published malicious versions of the widely-used axios HTTP client library during a several-hour window. The trojanized versions introduced a dependency on a decoy package, plain-crypto-js, which delivered a cross-platform remote access trojan.
02 Root Cause Analysis
2.1 Source Map Leak: The Bun Bug
Claude Code is built on Bun — a JavaScript runtime Anthropic acquired in late 2025. A known bug in Bun (oven-sh/bun#28001, filed March 11, 2026) causes source maps to be generated and served even when production mode is active. Bun's own documentation states source maps should be disabled in production builds. The bug was open and unpatched at the time of the release.
Note: This is a defense-in-depth failure — any single control described in Section 4 would have prevented publication.
2.2 Axios Supply Chain Attack: Malicious Package Publication
The axios attack followed the classic dependency confusion / malicious publish pattern. The threat actor obtained credentials sufficient to publish new versions of a legitimate, widely-used package. The payload was embedded in a transitive dependency to reduce scrutiny during manual review.
This attack is categorically distinct from the Anthropic leak — it required active adversary action rather than human error — but it shares the same delivery vector: the public npm registry with insufficient publisher verification. This is a common and rampant supply chain attack pattern, and a well-documented one: OWASP Top 10 category A08:2021, Software and Data Integrity Failures.
03 What Was Exposed
3.1 Proprietary Engineering Details
- Self-healing memory architecture and context window management logic
- Tool system internals: file read, bash execution, multi-agent orchestration
- Bidirectional IDE communication layer
- Query engine and LLM API orchestration patterns
- 44 feature flags — 20 covering unshipped functionality
3.2 Strategic Product Roadmap
- KAIROS: persistent background agent mode with autonomous task execution and push notifications
- autoDream: nightly memory consolidation and context distillation while idle
- Undercover Mode: system prompt directing Claude Code to conceal AI authorship when contributing to public open-source repositories
- Buddy: tamagotchi-style companion feature with a coded rollout window of April 1–7
3.3 Anti-Competitive Mechanisms
The leak exposed two anti-distillation mechanisms Anthropic had not disclosed publicly:
- Fake tool injection (
ANTI_DISTILLATION_CCflag): decoy tool definitions injected into API requests to poison training data collected by competitors recording API traffic - Server-side connector-text summarization with cryptographic signatures to prevent verbatim extraction of assistant reasoning chains
3.4 Internal Model Codenames and Performance Metrics
- Capybara: Claude 4.6 variant (also referenced as Mythos in a separate prior leak)
- Fennec: Opus 4.6
- Numbat: unreleased model, still in testing
- Capybara v8 false-claims rate: 29–30% (a regression from 16.7% in v4) — a benchmark competitors can now target directly
Note: Model weights, customer data, API keys, credentials, and authentication tokens were not exposed. Anthropic confirmed no sensitive customer data was involved — the leak was limited to source code and build artifacts.
04 Prevention: Engineering Controls
A two-stage release pipeline is proposed below as the primary control, with complementary hardening measures beneath it.
4.1 Two-Stage Release Pipeline: Private Registry Gate
The most architecturally sound mitigation is a two-stage release pipeline that physically separates internal builds from public distribution. Even if a packaging bug ships a .map file, it never reaches the public registry — it is caught and blocked in the internal stage.
For a commercially critical package with significant IP value, this pattern should be standard release governance. The marginal operational cost is low; the blast radius reduction is total.
4.1.1 Stage 1: Internal Publish Pipeline
Every commit to main triggers a build that publishes to a private registry (GitHub, npm, Docker, etc.). This stage runs all automated quality and security gates.
| Step | Detail |
|---|---|
| Trigger | Merge to main / release branch |
| Publish target | Private registry |
| Access control | Authenticated internal users and CI tokens only |
| Automated security gates | See 4.1.2 — all must pass before the package is promoted to candidate status |
| On failure | Pipeline fails, package is not published anywhere, alert fires to release team |
| On success | Package tagged as release-candidate in private registry; promotion request opened for human review |
4.1.2 Automated Sanitization Gates (Stage 1)
The following checks run as blocking CI steps against the private registry build. Any failure aborts promotion.
.mapfile detection: fail if any*.mapfile is present in the packed tarball- Package size assertion: fail if tarball exceeds a defined size threshold (e.g., 10 MB)
- Allowlist check: assert only whitelisted paths (
dist/,bin/,README.md) are included - Secret scanning
- Dependency vulnerability scanning
- Code vulnerability scanning
- Binary code-signing verification against a valid digital certificate
- Dependency integrity: verify all dependency hashes match the committed lockfile
- SBOM generation: produce a Software Bill of Materials for the release candidate
4.1.3 Stage 2: Human Approval and Public Promotion
After Stage 1 passes, a promotion request is opened — for example, a GitHub environment protection rule, a release ticket, or a dedicated approval workflow. A designated release engineer reviews and approves before Stage 2 executes.
| Step | Detail |
|---|---|
| Trigger | Manual approval by designated release engineer |
| Reviewer responsibilities | Confirm automated gates passed, review SBOM, verify version-bump intent, check no emergency holds are active |
| Approval mechanism | GitHub environment protection rule (required reviewers) or equivalent |
| Publish target | npmjs.com public registry |
| Post-publish | Automated smoke test: install from public registry in a clean environment, verify the binary executes, verify no .map files are present |
| Rollback | npm deprecate or npm unpublish within the 72-hour window; private registry retains the prior candidate for re-promotion |
4.1.4 Pipeline Process Summary
| Stage | Action |
|---|---|
| git push to main | Triggers Stage 1 CI |
| Stage 1 CI | Build → automated gates → publish to private registry → open promotion request |
| Private registry | Holds release candidates; accessible to internal teams for testing |
| Human approval | Release engineer reviews, approves promotion request |
| Stage 2 CI | Pull from private registry → final check → publish to npmjs.com → smoke test |
| Public registry | npmjs.com — only receives pre-verified, human-approved artifacts |
Why would this have prevented the issue? The .map file would have been caught by the automated gate in Stage 1 and never reached the public npmjs.com registry. Even if that gate had been skipped, the human reviewer in Stage 2 would have seen a multi-megabyte anomaly in the SBOM and halted promotion. Two independent failure modes would both need to be bypassed simultaneously for the leak to occur.
4.2 Harden Package Contents (Defense in Depth)
The two-stage pipeline is the primary control. These are complementary hardening measures that provide additional layers if the pipeline is bypassed.
4.2.1 Whitelist-Only Package Contents
An explicit files whitelist in package.json makes accidental inclusion of .map files structurally impossible, independent of .gitignore or .npmignore. Any change to this list has to go through human review and approval.
4.3 Dependency Security: Defending Against Supply Chain Attacks
4.3.1 Lock and Verify Dependencies
Commit lockfiles (package-lock.json, yarn.lock, bun.lockb) to version control. Use npm ci instead of npm install in all CI/CD environments — ci respects the lockfile exactly and does not resolve new versions.
4.3.2 Dependency Anomaly Monitoring
Use tools like Socket.dev, Socket Security, or Snyk to monitor for dependency anomalies: new maintainers, sudden version bumps, new transitive dependencies. These are the behavioral signals of a supply chain attack in progress.
4.4 Secrets and Credentials Management
- Never store secrets, API keys, or credentials in source code or build artifacts — use environment variables or a secrets manager/vault
- Implement automated secret scanning in CI to catch credentials before they reach version control or published artifacts
- Maintain a secret rotation policy aligned to NIST standards, and rotate credentials proactively after any suspected breach, even if no credentials are confirmed in the leaked material
4.5 Incident Response Preparation
- Maintain a private mirror of all published packages to enable rapid forced-version pulls without losing rollback capability
- Pre-draft takedown request templates for major code hosting platforms to reduce response time in the event of unauthorized redistribution
- Define package size and content anomaly thresholds in monitoring — alert on sudden publish-size increases
- Establish a clear escalation path: who authorizes an emergency unpublish, who issues external communication, who coordinates with registries
05 Conclusion
The Claude Code incident illustrates how a single unpatched toolchain bug, compounded by the absence of a private registry staging layer and human release gates, can result in significant IP exposure. The concurrent axios supply chain attack demonstrates that the npm ecosystem remains a high-value target and that package integrity cannot be assumed without active verification.
A two-stage release pipeline — private registry for automated gates, human approval before public promotion, layered with defense-in-depth measures like content whitelisting — would have contained the blast radius entirely. This is not a novel architectural pattern; it is standard release governance for any package with significant commercial or IP value. This incident is a reminder of how easily that governance gets omitted when velocity is prioritized over process rigor.
For engineering and DevSecOps teams: treat your publish pipeline as a security boundary with two distinct zones. Nothing crosses from internal to public without automated verification and human sign-off. The operational cost is measured in hours of setup; the cost of omitting it, as demonstrated here, is measured in irreversible competitive exposure.
Sources: reporting and technical analysis on these incidents is publicly available from Anthropic, CISA, Microsoft Security Response Center, Google Threat Intelligence Group, Wiz, Tenable, Socket.dev, Arctic Wolf, Huntress, and Trend Micro, among others.