supply-chain-risk-auditor

Use it when:: You need to judge the third-party package risk in a project, for example before a security engagement.
It does:: Runs a bundled collector over each direct dependency and the whole lockfile tree, renders its report, then adds upgrade paths and replacement candidates.
You get:: report.md and findings.json, written outside the audited repo, with every criterion marked clean, flagged or unassessable.
Never:: Installs, builds or executes anything; it reads manifests, lockfiles and registry, advisory and repository metadata.
Needs:: uv to run its scripts, and a logged-in gh; without it, GitHub rate limits leave repository checks unassessable.

Needs uv, and gh signed in: unauthenticated GitHub allows 60 requests an hour, so repository checks come back unassessable without it. It reads only manifests, lockfiles and registry metadata, and never installs or runs your code.

TL;DR

Trail of Bits rebuilt this audit around scripts after hand-collected figures came out wrong, such as GitHub contributor counts that overstated how many people can publish a package. So a collector measures advisories matched to exact versions, abandoned or archived upstreams, how few npm publishers control a package, and install-time scripts, and the agent quotes its numbers verbatim instead of estimating them from gh, web search or memory. Missing data is never treated as risk, and a run that measured nothing fails rather than report a clean result. It covers npm, PyPI and Go only, and reads package-lock.json, npm-shrinkwrap.json, uv.lock and Go 1.17+ go.mod for exact versions; yarn, pnpm and poetry lockfiles are noted but not read. On top of the measured report the agent adds a short narrative of what to act on first, whether each advisory fix is a patch or a major version away, verified replacements for abandoned packages, and whether npm ci --ignore-scripts would work, all in an impersonal security-report style. License compliance and scanning your own source are out of scope.

Summarizes the skill at e4dd0bb.

npx skills add https://github.com/trailofbits/skills --skill supply-chain-risk-auditor

skills.sh page Source on GitHub All skills from trailofbits/skills

Weekly Downloads week to Nov 9, 2026

364

+99% in 8 weeks

More weekly downloads than 52% of skills

Weekly values

Week to	Installs
Sep 21	183
Sep 28	201
Oct 5	219
Oct 12	270
Oct 19	293
Oct 26	353
Nov 2	371
Nov 9	364

Total Downloads on skills.sh

8,900

Fewer downloads than 54% of skills

Repo stars trailofbits/skills

8,081

More stars than 54% of repos

Age published Feb 26, 2026

8 months

Older than 57% of skills

Category	category:security category:software-engineering Compliance, guardrails, skill vetting and browser fingerprinting. Everything for building software: planning, coding, debugging, design, frameworks, cloud, agents and skills.
Type	type:tool Operates a CLI, API, app or bundled script to get something done.
Effect	effect:local Its own steps create or change files, git state or local tools.
Needs	needs:cli A specific command-line tool or desktop app must be installed, such as gh, agent-browser, LibreOffice, Obsidian or a vendor CLI.
Publisher	by:official A verified publisher on skills.sh, or the company or maintainer behind the product the skill operates.
Topics	security
Stack	stack:node stack:python stack:go

SKILL.md

From trailofbits/skills at e4dd0bb. Checked daily, last changed Nov 6, 2026.

Frontmatter

name: supply-chain-risk-auditor
description: "Audits a project's dependencies for supply-chain risk: version-matched advisories for direct dependencies and the full lockfile tree, abandoned or archived upstreams, npm publisher concentration, and install-time script execution. Use when asked to audit dependencies, assess supply-chain or third-party package risk, or review a dependency tree before an engagement."
allowed-tools: Read Write Bash Glob Grep

Supply Chain Risk Auditor

Generates a supply-chain risk report for a project's direct dependencies (npm, PyPI, Go), plus an advisory sweep of everything its lockfile resolves. Two deterministic scripts do the measuring; your job is the judgment they refuse to automate.

Why the scripts do the measuring, not you

Every figure in this report is a claim about somebody else's project, and hand-collected figures were measured wrong before this skill was rebuilt around scripts: GitHub contributor counts said five-plus people maintain lodash where npm's ACL says one, and gh saw zero downloads for a package that moves 164 million a week. Do not estimate maintainer counts, downloads, staleness, or CVE history from gh, web search, or memory — run the collector, and quote what it measured.

The scripts enforce two rules worth knowing before you read their output:

Unavailable data is never evidence of risk. Every criterion resolves to assessed-clean, assessed-flagged, or unassessable-with-a-reason.
An absent measurement is never a clean verdict. A run that measured nothing exits non-zero instead of printing a report that finds nothing.

Workflow

Confirm the target directory has manifests: package.json, pyproject.toml, requirements*.txt, or go.mod. If none exist, say so and stop — do not audit an ecosystem this collector does not parse by hand. Lockfiles read for exact versions and the transitive sweep: package-lock.json/npm-shrinkwrap.json, uv.lock, and a go 1.17+ go.mod. yarn.lock, pnpm-lock.yaml, and poetry.lock are not read — the report says so when they are present, and versions fall back to pins or the latest release.
Check gh auth status. Unauthenticated GitHub allows 60 requests/hour against 5,000, and the collector makes several per dependency; expect repository criteria to come back unassessable without it. Say so rather than fixing it silently.
Collect, then render. Put outputs somewhere outside the audited repository unless asked otherwise:
```
uv run {baseDir}/scripts/collect.py <project-dir> --json <out-dir>/findings.json
uv run {baseDir}/scripts/render.py <out-dir>/findings.json --out <out-dir>/report.md
```
Expect a few minutes for ~50 dependencies — several HTTP requests per dependency, more with many Go modules, and slower without authenticated gh. If collect.py exits non-zero, it is refusing to report — relay its message verbatim instead of retrying or working around it.
Read report.md and findings.json. The report is the deliverable; the JSON carries the datum behind every verdict when you need to cite one.
Add what the collector cannot, clearly separated from what it measured:
- A short narrative for this reader: what to act on first, and why.
- Upgrade paths for advisory findings — check whether the fix is a patch or a major version away.
- Replacement candidates for abandoned or archived dependencies. Verify a candidate exists in the registry before naming it, and label these as judgment, not measurement.
- For flagged install scripts: whether npm ci --ignore-scripts is viable for this project's build.

Style for what you add

Write added prose the way a security report reads, and apply the same register to the report addendum and the final reply alike — replies get pasted into tickets and reports verbatim. State the finding, the datum behind it, and the action.

Impersonal and declarative: no first or second person ("I ran the collector", "you should upgrade"), no contractions, no exclamation points.
Active voice, with the subject matter as the actor: "upgrading to 1.19.0 clears all 25 advisories", not "it is recommended that axios be upgraded".
Objective: no intensifiers or subjective framing ("very", "significant", "fortunately"), and no guesses about why the project chose what it chose.
Tense: past for what the audit did, present for the state of the dependencies, future for the consequences of acting or not.
Constructive: a recommendation names the action and its cost, never a culprit.

If the report-writing:writing-style skill is available in the session, follow it — it is the full version of this register.

The rendered report carries facts only. The interpretive rules below are instructions to you, not content for the reader — do not copy them into the deliverable as caveats or framing.

Reading the report

Unassessable is not risk. PyPI publishes no maintainer ACL and Go has no registry; those rows say what could not be known, not what is wrong.
The coverage table bounds every claim. "No advisories" means "none among what was assessed" — check the assessed count before repeating a clean verdict.
Quote figures verbatim. Do not re-derive, round, or embellish the report's numbers; every one is reproducible from the artifact.
Absence from the findings is not endorsement. A dependency with no findings was measured against these criteria only.

Rationalizations to reject

"gh can give me maintainer counts faster than the collector." Measured wrong — repo contributors and registry publish rights are different populations.
"No findings, so the dependencies are safe." Read the coverage table; on PyPI and Go, half the criteria are structurally unassessable.
"The unassessable rows would just confuse the reader; I'll drop them." They are the boundary of every claim in the report. Dropping them turns partial coverage into a clean bill of health, which is the failure this skill was rebuilt to prevent.
"The version is probably close enough." A range checked at latest-release and a lockfile-resolved version are different claims; the report labels which one it makes. Keep the label.

When not to use

License compliance auditing.
Scanning the target's own source for vulnerabilities or secrets — this skill never reads dependency source, only registry, advisory, and repository metadata.
Judging whether the project installs or builds. The audit is designed to work from nothing more than the dependency list — manifests and lockfiles — and never installs, builds, or executes anything. Broken installs and import-time breakage are out of scope, and worth saying so if the user seems to expect them.
Ecosystems other than npm, PyPI, and Go; say the ecosystem is unsupported rather than improvising an audit for it.