eris-ths/supply-chain-guardDetect, assess, and respond to supply chain attacks across npm/yarn and Python (pip/poetry/uv). Claude Code skill + standalone scripts. Built during axios RAT (2026-03-31) and Starlette BadHost CVE-2026-48710 (2026-05-22).
An incident-response toolkit for npm/yarn and Python (pip/poetry/uv) supply chain attacks — free, local, dependency-free.
SCG is not a scanning engine that competes with commercial tools on coverage. It is a Claude Code skill and standalone shell toolkit that does three things well: (1) gives you a fast, repeatable first response when a specific incident drops ("is my machine affected right now?"), (2) orchestrates existing OSS scanners (npm audit, osv-scanner, pip-audit) into one structured pass, and (3) documents hard-won design-hygiene lessons — especially for AI development environments — that generic scanners don't cover.
It was built and hardened during real incidents, including:
scripts/project-scan-py.sh with pip-audit / osv-scanner / CVE-flagged version detectionOn March 31, 2026, the widely-used axios npm package (v1.14.1 and v0.30.4) was compromised through a maintainer account takeover attributed to UNC1069/DPRK-APT (per Google Threat Intelligence Group). The attack injected a phantom dependency ([email protected]) that deployed a cross-platform RAT via postinstall scripts, disguised as legitimate system processes.
Supply Chain Guard (SCG) was built during the incident to provide:
SCG is not a replacement for existing security tools. It combines multiple detection layers with a structured verification framework and guided remediation — designed for use during active incidents or as a periodic check alongside your existing tooling.
| Tool | What it does | How SCG relates |
|---|---|---|
npm audit | Checks registry for known vulnerabilities | SCG includes npm audit as its L1 layer, then adds IOC filesystem/network scanning, malicious package detection, and a structured response workflow on top |
osv-scanner | Scans lockfiles against Google's OSV database | SCG includes OSV as its L2 layer. osv-scanner doesn't check for RAT artifacts on your filesystem or active C2 connections |
| Snyk / Socket.dev | Commercial SaaS with real-time monitoring, PR checks, license scanning | SCG is free, local-first, no account required, no data sent to third parties. Designed for immediate incident response rather than ongoing monitoring |
| Manual IR | Ad-hoc investigation with custom scripts | SCG provides a repeatable framework (8 verification gates, convergence loop, severity matrix) instead of one-off checklists that vary per incident |
When to use SCG:
When to use something else:
We'd rather be honest about the boundaries than oversell. SCG is three things:
An incident-response playbook, as code. When a named incident drops (axios RAT, Shai-Hulud, a fresh CVE), SCG turns "am I affected, and if so what do I do?" into an executable checklist — 8 verification gates, a severity matrix, and a remediation script where every destructive action needs explicit [y/N] confirmation. This is its primary value: the fast, structured first response that commercial monitoring tools aren't shaped for.
An orchestrator of existing OSS scanners. The L1/L2 layers wrap npm audit / pip-audit / osv-scanner. Most of the raw detection power is borrowed; SCG's contribution is bundling them into one pass, adding filesystem/IOC checks the registry tools don't do, and making the output readable and actionable.
Documentation of real design-hygiene lessons (SKILL.md §D.7) — things we actually hit or investigated: MCP transport choice, GCP default-SA hardening, install-time execution vectors, and threats that target AI dev tooling (Shai-Hulud reading .claude/settings.json, SANDWORM_MODE poisoning MCP configs). This niche — supply-chain hygiene for AI-assisted development — is where SCG is genuinely differentiated.
SKILL.md D.2, the L3 static lists) is hand-maintained — it holds the incidents we've read about, not the tens of thousands of malicious packages a live commercial feed tracks. A hand-curated list cannot keep pace with the real rate of new threats, and we don't pretend it does.Because a hand-curated database can't win on coverage, we're intentionally investing where SCG is hard to replace rather than where it will always lose:
The static threat DB (#2) will keep getting updated when notable incidents land, but it is explicitly not the direction we're trying to compete on.
SCG follows a Domain-Driven Design (DDD) architecture with three layers: