It started with a sudden spike.
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.
That’s when we realised it wasn’t a normal spike.
Someone had gained access to the server. They were bouncing through more than 19,000 IPs from different countries. The entry point was CVE-2025-66478 — 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.
We moved fast. Took a full backup. Spun up a fresh droplet. Shut down the compromised server completely.
The damage was contained, but the feeling stayed with me.
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.
That night I kept thinking:
What if something had warned us before we pushed the update live?
Not after the attack.
Not after the CPU spiked.
Before the code even reached production.
That question is the reason DevCompass exists.
What I wanted the tool to do
I wanted something that could look at a project and tell me, clearly and early:
- Are there serious vulnerabilities in the dependencies we’re about to ship?
- Are there unused packages adding unnecessary surface area?
- Are there license conflicts we should know about?
- How is the overall health of this dependency tree changing over time?
- Are there safer alternatives we should consider?
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.
So I built it.
DevCompass 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.
bash
npm install -g devcompass
devcompass analyze
Top comments (0)