/dependency-supply-chain-review

name: dependency-supply-chain-review
description: >-
  Review third-party dependencies for supply-chain trust risk — typosquatting,
  dependency confusion, maintainer/abandonment risk, unpinned versions, and
  malicious install scripts — not just known-CVE counts. Use when assessing how
  much a project trusts code it didn't write, or vetting a new dependency.

Goal

A trust assessment of the dependency graph: which packages could become an attack path, and the controls (pinning, allowlists, verification) that close them. This is about **provenance and trust**, complementing the known-CVE scanning in `sast-sca`.

What to look for

• **Typosquatting / brandjacking** — names a character off from popular packages,

or impersonating an internal/well-known library.

• **Dependency confusion** — internal package names resolvable from public

registries; scoping/namespace not reserved; public takes precedence over private.

• **Maintainer & health risk** — single maintainer, recently transferred ownership,

abandoned/unmaintained, sudden new maintainer before a release, low download trust.

• **Install-time execution** — `postinstall`/build scripts, `setup.py` code, native

build steps that run arbitrary code on `install`.

• **Pinning & integrity** — floating ranges vs. pinned versions; lockfile present and

enforced; hash/integrity verification on install.

• **Transitive blast radius** — deep/risky transitive deps pulled by a trusted top

level one.

Steps

1. Inventory direct + transitive dependencies (ingest an SBOM or generate one — CycloneDX/SPDX). 2. Screen each against the risk patterns above; flag the install-script and confusion/typosquat cases first — those are active attack paths, not hygiene. 3. Check registry/namespace controls: are internal names reserved on public registries? Is a private-first resolver / allowlist enforced? 4. Recommend controls: pin + lockfile + integrity hashes, internal proxy/registry with allowlisting, scoped namespaces, and review gates for new dependencies.

Output

A ranked findings list (package · risk type · evidence · blast radius · fix) plus recommended org-level controls. Route CVE/version remediation to `vulnerability-management`; formalize with `security-reporting`.

Notes

The dangerous supply-chain attacks aren't "old CVE in a lib" — they're malicious code shipped in a *legitimate* package (compromised maintainer, confusion, typo). `sast-sca` answers "is this dependency vulnerable?"; this skill answers "should I trust this dependency at all?"