supply-chain-security

Supply Chain Security

Rank by reachability, not CVSS

CVSS describes a vulnerability in the abstract. Reachability describes your exposure. A critical CVE in a package whose vulnerable function you never call is a batch-with-the-next-upgrade item. A medium CVE on your auth path is not.

Tier	Definition
Reachable — exposed	A call path exists from a network-facing entry point to the vulnerable symbol
Reachable — internal	A path exists from internal or CLI entry points only
Present, unreachable	Installed; the vulnerable symbol is never called
Dev-only	`devDependencies` — not shipped, still in the CI supply chain
Transitive, unreachable	Pulled in by another package, never invoked

Print the path. The ranking is only trustworthy if it is auditable:

src/api/webhook.ts:41  handler(req)              ← unauthenticated route
  → src/billing/invoice.ts:88  buildInvoice(req.body)
    → lodash.merge(defaults, untrusted)          ← vulnerable symbol

If you cannot construct a path, say "no path found" — not "probably unreachable". The reader needs to know whether you looked or guessed.

Committed secrets — revoke first

A secret pushed to a remote is compromised. Removing the commit does not un-compromise it: it lives in forks, clones, CI caches, mirrors, and the events API.

Revoke. Rotate at the source. Everything else is theatre until this is done.
Remove. Delete from the tree, replace with an env or vault reference.
Rewrite history — only with explicit approval, only after revocation, and knowing it invalidates every open PR and clone. Usually not worth it.
Audit the credential's activity during the exposure window.

Never print a secret value — not in output, logs, commits, issues, PR comments, or telemetry. Type, file, line, and first-seen commit only.

Reducing false positives

Test fixtures with obviously fake values (sk_test_, AKIAIOSFODNN7EXAMPLE) · placeholders in .env.example · public identifiers that look secret (publishable keys, client ids) · high entropy from hashes, UUIDs, or base64 assets.

Report uncertain findings as "possible", with the reason — a wrong secret alert costs a rotation nobody needed.

Verifying code-scanning alerts

Static analysis produces false positives, and a fix for a false positive is churn plus risk. Attempt to construct a concrete exploitation path for each alert. Dismiss as false positive only with the reasoning recorded — the sanitizer the analyzer missed, the framework escaping it did not model. A silently dismissed alert is indistinguishable from an ignored one.

Maintenance risk

A current version of an abandoned package is still a liability:

Signal	Why
Last publish > 24 months	No fix is coming
Single maintainer, no org	Bus factor and account-takeover risk
Recent maintainer change	The most common compromise vector
Install scripts (`postinstall`)	Arbitrary code at install time
Deprecated by author	Migration is inevitable
High fan-in transitive	Large blast radius

Recent maintainer change plus an install script is a security finding, not a maintenance note.

Provenance

Are artifacts built in CI with attestation, or uploaded from a laptop? Are third-party actions pinned to a commit SHA — a tag is mutable, and a compromised tag is a supply-chain compromise with your name on the commit. Are registry credentials scoped to publish only what they should?

Never

Never post vulnerability details publicly before a fix ships. Never suppress an alert without a recorded justification and an accepter. Never auto-merge a security fix that changes behavior without review — a rushed patch that breaks auth is worse than the bug it fixed.

About this skill