supply-chain-risk-auditor

Overview

security-devsecops Step 1 (npm audit) catches known CVEs in your dependencies. It does not catch whether the dependency itself is trustworthy: a clean dependency that's maintained by one person who hasn't logged in for 8 months is a higher risk than a noisy dependency with a healthy maintainer pool. CVE scanners run on the package metadata; supply-chain risk audits the supply side — who maintains it, how, and whether continuing to depend on it is reasonable.

This skill evaluates the trustworthyness of dependencies against 5 standard axes + 1 temporal-pattern axis (Axis 5.6, the long-game social-engineering signal):

Single-maintainer risk: is the package a bus-factor-1 project? (See also security-ownership-map — same methodology, applied to your dependencies.)
Abandoned-repo risk: last commit, last release, stale issue backlog, unmerged PRs.
Low-popularity risk: stars / downloads / dependents. Low numbers ≠ bad (some niche deps are gems), but worth questioning in security-sensitive paths.
Maintainer-identity hygiene: how is the maintainer account secured? Has it joined the project recently? Has it transferred ownership? Two-factor / GPG signing history?
Social-engineering resistance: how easy would it be to take over the package? (Maintainer accountability trail, code review on PRs, security policy, / SECURITY.md, PGP-signed releases.)

Distinct from: security-devsecops (CVE scan, SBOM, IaC, pre-deploy) and security-incident-response (post-breach). This skill is before the dep enters your lockfile or at policy-review time to decide whether to keep it.

Path Convention (两轴原则)

输入与输出都落在 docs/supply-chain-risk/ 下,git tracked 项目级 audit log: