DEV Community: Joseph Yeo

Case Study: How I Dogfood DevRadar Guard on a 954-Dependency Project

Joseph Yeo — Mon, 06 Apr 2026 13:25:37 +0000

This is a follow-up to my earlier post: Axios Was Compromised. Here's What It Means for Your Repo.

The Setup

GloriaPPT is a presentation tool I built and maintain. It's a fairly typical modern JavaScript app: a Next.js frontend, a Node.js backend, and deployment on Vercel. What makes it interesting for this case study is its dependency tree: 954 npm packages in the lockfile.

Most of those packages are transitive. I haven't read the source code for most of them, and realistically, neither do most small teams. If one of them were compromised tomorrow, I probably wouldn't know right away.

That's the problem I built DevRadar Guard to solve.

Before DevRadar Guard

Dependency monitoring: Manual npm audit when I remembered to run it
Supply chain alerts: None — I found out about incidents from social feeds and security threads
.npmrc hardening: Default settings
CLAUDE.md security section: Didn't exist
Pre-install hooks: None
CI/CD security checks: Basic Dependabot, no custom policy
Response time to incidents: Hours to days, depending on when I saw the news

After DevRadar Guard

I deployed DevRadar Guard's hosted monitoring on a small VPS that checks every 30 minutes. Here's what changed.

Signal Collection

The Signal Engine collects threat intelligence from GitHub Security Advisories every 30 minutes. In the first 24 hours, it ingested 467 raw events — advisories affecting npm packages — and normalized all of them into structured threat candidates with confidence scores.

Each signal is scored across five dimensions, including source quality, technical specificity, cross-reference validation, discussion velocity, and ecosystem relevance.

Exposure Matching

Out of 467 normalized signals, the Exposure Engine matched 1 against GloriaPPT's actual dependency tree: axios.

Package: axios
Installed version: 1.14.1
Confidence score: 65/100
Exposure score: 50/100
Final risk: 57/100 (alert threshold: 50)

The confidence score reflects signal quality: a high-trust source, a named package and version, and enough technical detail to treat the advisory seriously.

The exposure score reflects how directly the issue touched this repo: axios was a direct dependency, and the affected version was present in the lockfile.

The Alert

At 00:24 KST (UTC+9) on April 6, a Slack alert landed in #devradar-alerts:

🛡️ DevRadar Guard Alert

Package: axios
Version: 1.14.1
Risk Score: 57/100
Confidence: 65
Exposure: 50
Path: direct

Signal: Compromised axios versions 1.14.1 and 0.30.4 were
reported to deliver a remote access trojan...

I didn't find out about the axios compromise from social media. The alert was waiting for me when I checked Slack.

Guardrail Bundle

DevRadar Guard generates a guardrail bundle — a set of files you can drop into a repo to harden installs, guide AI coding agents, and surface risky dependency changes during review:

File	Purpose
`CLAUDE.md` security section	Security policy for AI coding agents
`.npmrc` hardening	`ignore-scripts=true`, `audit=true`, registry pinning
Pre-install hook	Warns before installing packages younger than 7 days
GitHub Actions workflow	PR check that flags risky dependency changes (alert-only)
`devradar-policy.json`	Machine-readable policy for CI/CD integration

GloriaPPT now uses all 8 generated guardrail files. The pre-install hook would likely have flagged the malicious plain-crypto-js dependency used in the attack, since it had been published less than 24 hours earlier.

The Numbers

Metric	Value
Dependencies monitored	954
Raw threat signals collected (first 24h)	467
Normalization success rate (first 24h sample)	100%
Signals matched to GloriaPPT	1 (axios)
False positives in this case study	0
Time from advisory to alert	< 30 minutes (cron cycle)
Guardrail files generated	8
Manual intervention during detection	0

What This Doesn't Prove

I want to be honest about what this case study shows and what it doesn't.

It shows: A real supply chain threat was detected, matched to a real project, and surfaced as an actionable alert — automatically, without manual intervention.

It doesn't show: DevRadar Guard catching a zero-day before anyone else. The axios advisory was already published when my pipeline picked it up. I'm not claiming to be faster than GitHub Advisory. I'm claiming to be faster than manual monitoring — finding out from social feeds, security threads, or a post after the fact.

It doesn't show: Protection against all supply chain attacks. The Signal Engine currently monitors GitHub Advisories only. Reddit, npm registry anomaly detection, and other sources are planned but not yet active in Alpha.

It doesn't show: Automatic blocking. DevRadar Guard Alpha is alert-only. No PR failures, no install blocks, no surprises. You get the information; you decide what to do.

Try It

DevRadar Guard is still in Alpha, and I'm testing it with a small number of pilot teams. Right now that includes hosted monitoring on a 30-minute cycle, matched alerts in Slack or Discord, a generated guardrail bundle for the repo, and a weekly threat briefing. All I ask in return is a few minutes of feedback each week.

If your project has a package-lock.json and you want earlier, repo-specific visibility into supply chain incidents, the starter kit and waitlist are below:

DevRadar Guard Alpha — alert-only, no automatic blocking. You stay in control.

Axios Was Compromised. Here's What It Means for Your Repo.

Joseph Yeo — Mon, 06 Apr 2026 03:58:03 +0000

On March 31, 2026, the axios npm package — with over 100 million weekly downloads — was compromised and used to distribute malware.

A threat actor took over the lead maintainer's npm account, published two backdoored versions (1.14.1 and 0.30.4), and added a hidden dependency that deployed a cross-platform remote access trojan. The payload targeted Windows, macOS, and Linux. The malicious versions were live for only about three hours before they were removed.

In practice, three hours was enough.

Microsoft attributed the attack to Sapphire Sleet, a North Korean state actor. Google's Threat Intelligence Group confirmed UNC1069 involvement. This was a coordinated, pre-staged operation — the malicious dependency was planted 18 hours before activation.

Why This Matters to You

If your package.json uses caret ranges like ^1.x, a routine npm install could have pulled the compromised version automatically. No unusual action required. Just your normal CI/CD pipeline doing what it was designed to do.

Most teams would not have caught this in time.

Not because they're careless, but because the tooling gap is real:

npm audit looks for known CVEs. This wasn't a CVE when it hit.
Dependabot follows published advisories. This version came from the real maintainer account.
Lockfiles help, but only if they're pinned and not being updated automatically.

The teams that stayed safe had one thing in common: they treated dependency management as part of their security practice, not just routine package maintenance.

What Happened in Our Setup

I maintain a project called GloriaPPT — a typical Next.js app with 954 npm dependencies. When the axios advisory dropped, I wasn't refreshing Twitter. I got a Slack alert.

I built DevRadar Guard to answer one practical question fast: does this incident actually touch one of my repos? In this case, the flow looked like this:

Signal Engine picked up the GitHub Advisory within its 30-minute collection cycle.
Exposure Engine matched it against GloriaPPT's package-lock.json, where axios was a direct dependency.
Guardrail Engine sent a Slack alert with the risk score, confidence level, and affected version.

No manual checking. No scrolling through threads or advisories. The alert landed with the information I needed to decide what to do next.

Axios Was One Incident. The Pattern Keeps Repeating.

Axios will be patched. Credentials will be rotated. Postmortems will be published.

But the pattern repeats. Before axios, it was event-stream. Before that, ua-parser-js. The attack surface keeps growing with every install that pulls in packages your team didn't explicitly choose or review.

The question isn't whether the next supply chain attack will happen. It's whether your repo will know about it before your CI/CD pipeline installs it.

What You Can Do Today

Even without new tooling, these steps can reduce your risk right away:

Pin your dependencies. Remove ^ and ~ from critical packages. Use exact versions.
Set ignore-scripts=true in .npmrc. In this incident, that setting would have blocked the malicious install script.
Review your lockfile after every install. If a new transitive dependency appears that you didn't add, investigate.
Audit your CI/CD pipeline permissions. Does your build environment need network access during npm install?

What We're Building

I'm also building DevRadar Guard around this workflow: early signal collection, repo exposure checks, and guardrail generation. Part of it is open source, including starter config for .npmrc, pre-install hooks, CLAUDE.md (security policy for AI coding agents), and GitHub Actions.

DevRadar Guard is still in Alpha and runs in alert-only mode. No automatic blocking, and no surprise PR failures. You stay in control.

If your team depends on npm and this workflow sounds useful, take a look at the starter kit or join the waitlist: