The latest articles on DEV Community by Ajay Thorat (@ajaybthorat20). https://dev.to/ajaybthorat20 https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F674489%2Fc574d515-9dcc-49de-a41e-be3a12807719.png https://dev.to/ajaybthorat20 en Ajay Thorat Mon, 21 Sep 2026 05:57:46 +0000 https://dev.to/ajaybthorat20/the-night-our-server-got-owned-and-why-i-built-devcompass-1kbi https://dev.to/ajaybthorat20/the-night-our-server-got-owned-and-why-i-built-devcompass-1kbi <p>It started with a sudden spike.</p> <p>CPU cores were maxed out. Memory was climbing fast. At first we thought it was just a heavy process. We killed it. The numbers dropped. Then they climbed again.</p> <p>That’s when we realised it wasn’t a normal spike.</p> <p>Someone had gained access to the server. They were bouncing through more than 19,000 IPs from different countries. The entry point was <strong>CVE-2025-66478</strong> — a critical remote code execution vulnerability. Once inside, they dropped a crypto miner and started burning through every core and every bit of memory they could find.</p> <p>We moved fast. Took a full backup. Spun up a fresh droplet. Shut down the compromised server completely.</p> <p>The damage was contained, but the feeling stayed with me.</p> <p>We had deployed code that carried a known critical vulnerability. We only found out after the attacker was already inside, after the miner was already running, after the server was already under load.</p> <p>That night I kept thinking:</p> <blockquote> <p>What if something had warned us <em>before</em> we pushed the update live?</p> </blockquote> <p>Not after the attack.<br><br> Not after the CPU spiked.<br><br> Before the code even reached production.</p> <p>That question is the reason <strong>DevCompass</strong> exists.</p> <h2> What I wanted the tool to do </h2> <p>I wanted something that could look at a project and tell me, clearly and early:</p> <ul> <li>Are there serious vulnerabilities in the dependencies we’re about to ship?</li> <li>Are there unused packages adding unnecessary surface area?</li> <li>Are there license conflicts we should know about?</li> <li>How is the overall health of this dependency tree changing over time?</li> <li>Are there safer alternatives we should consider?</li> </ul> <p>And if something looked risky, I wanted a way to fix it carefully — with a backup and a clear risk level — instead of hoping nothing breaks.</p> <p>So I built it.</p> <p><strong>DevCompass</strong> is a CLI tool focused on dependency health for Node.js projects. You run it locally or in CI, and it gives you a picture of the real state of your dependencies before that code goes live.</p> <div class="highlight js-code-highlight"> <pre class="highlight plaintext"><code> bash npm install -g devcompass devcompass analyze </code></pre> </div> node javascript security devtools