So, you’ve probably seen the news about the internal code exposure. It sounds like a sophisticated breach, but in reality, it was a classic DevOps nightmare involving a simple misconfiguration in the CI/CD pipeline.
Let see what have happend. If you are familiar with npm (Node Package Manager), you know that the package.json is the heart of your project, acting as the manifest that tracks your metadata and dependencies. When we’re ready to share a tool, we run npm publish to push our code to the public npm registry.
Here is where the “Source Map” comes in. When we ship production code, we minify and uglify it to reduce the bundle size. This makes the code unreadable for humans. To fix bugs in production, we generate Source Maps (.map files). These files act as a “decoder ring” that maps the transpiled and minified code back to your original TypeScript or JavaScript source code.
Instead, the ignore rules were missed. When the package was published to the registry, the build artifact included that giant map file. Because that file was bundled in the public release, anyone could use a simple debugger to “un-minify” the logic. It essentially turned their private, proprietary logic back into a readable “open source book.”
It’s a huge reminder to always audit your build artifacts before they hit a public repository. One missed line in a config file can accidentally leak your entire internal codebase.