What Happened
Security researcher Chaofan Shou recently discovered that Anthropic accidentally exposed the complete source code for Claude Code—their AI coding agent—through a public npm package. The leak involved a 59.8 MB JavaScript source map file containing 513,000 lines of TypeScript. Within hours, thousands of GitHub repositories began hosting copies of the leaked code and derivatives. Although Anthropic issued DMCA takedown notices on some mirrors, the code remains widely available.
Timeline
Discovery Phase: Chaofan Shou identifies the exposed source map file in a public npm package.
Initial Spread: The leaked code is shared across developer communities and forums.
Mass Distribution: Thousands of GitHub repositories clone or fork the exposed code.
Response: Anthropic issues DMCA notices targeting some repositories.
Current State: Despite takedown efforts, the code remains accessible through numerous channels.
Which Controls Failed or Were Missing
Pre-Publication Review
Your build pipeline should never ship source maps to production. This leak occurred because no one caught a 59.8 MB file before it went to npm. Implement automated checks that flag:
- Files over a size threshold (e.g., 10 MB)
- .map extensions in production artifacts
- Any file containing unminified source code references
Secrets and Sensitive Data Scanning
Source maps reveal your architecture, dependencies, internal APIs, and implementation details. Your CI/CD pipeline should treat them like API keys or database credentials—as artifacts that never leave your controlled environment.
Package Integrity Verification
The npm package went live without verifying its contents matched the intended release manifest. Implement a signing process where a human or automated policy engine explicitly approves what gets published to public registries.
Access Control on Public Repositories
Once the code leaked, the damage multiplied because anyone could fork and redistribute it. Monitor unauthorized mirrors of your code and have a documented response plan for when leaks occur.
What the Standards Require
ISO/IEC 27001:2022 Control 8.10 (Information Deletion)
This control requires you to delete information when it's no longer needed. Source maps should be stripped from production. Document which artifacts belong in which environments and enforce those boundaries with automation.
NIST 800-53 Rev 5 Control SA-15 (Development Process, Standards, and Tools)
SA-15(8) addresses the reuse of threat and vulnerability information. When you ship source maps, you're handing threat actors a blueprint. Implement:
- Automated scanning of build artifacts before release
- Verification that production packages contain only intended files
- Audit logs showing who approved each release
SOC 2 Type II CC6.6 (Logical and Physical Access Controls)
Your auditor will ask how you restrict access to source code. Publishing it to npm is the opposite of access control. Implement:
- Role-based access to your build and release systems
- Approval workflows for public package publication
- Automated gates that prevent accidental exposure
PCI DSS v4.0.1 Requirement 6.2.4
If your code processes payment data, Requirement 6.2.4 mandates secure management of all payment software and application accounts and credentials. Source maps can expose how you handle credentials, session tokens, and authentication flows.
Lessons and Action Items for Your Team
1. Audit Your Build Pipeline Today
Run this command on your production artifacts:
find . -name "*.map" -o -name "*.ts" -o -name "*.jsx"
If you get results, you're shipping source code. Fix it before someone finds it.
2. Implement Source Map Upload to Private Storage
Tools like Sentry and Datadog let you upload source maps for debugging without including them in your production bundle. Configure your build to:
- Generate source maps during build
- Upload them to your error tracking service
- Strip them from the final package
3. Add Pre-Publication Checks
Create a .npmignore or adjust your package.json files array to explicitly exclude:
*.mapfiles- TypeScript source files
- Test directories
- Internal documentation
- Configuration files with environment-specific settings
4. Require Manual Approval for Public Packages
Add a manual approval step for public package publication. One person writes the code, another reviews the package contents before publication. Your CI/CD should block automatic publication without this approval.
5. Monitor for Unauthorized Mirrors
Set up Google Alerts and GitHub search notifications for your organization name plus terms like "leaked," "source," or "mirror." Quick response limits the spread of leaked code.
6. Document Your Incident Response Plan
Plan for code leaks now. Decide who issues DMCA notices and who contacts affected customers. As Anthropic learned, DMCA notices don't remove code from the internet—they just slow its spread.
7. Review Third-Party Dependencies
The thousands of repositories now hosting Anthropic's code create a supply chain risk. Audit your dependencies for suspicious sources or recently created packages that might contain leaked code.
8. Train Developers on Source Map Risks
Most developers don't think about source maps as security risks. Add source map handling to your secure development training. Explain why shipping them is like publishing your architectural diagrams and code comments to the world.
The Anthropic leak wasn't sophisticated. It was a build configuration mistake that exposed 513,000 lines of code. Your organization likely has similar risks in your CI/CD pipeline. Find them before someone else does.
