Supply chain audit
Software supply chain audit — dependencies (CVEs, maintenance, licenses, transitive risk), build/CI integrity (SHA-pinned actions, lockfile, CI-only release), artifact integrity (checksums, signing, SBOM). Triggers on: "/supply-chain-audit", "supply-chain-audit", "dependency audit". Run before adding a dep, before a release, or for periodic review. Reports; does not change deps unless asked.From its SKILL.md
npx -y skills add HetCreep/CoalMine --skill supply-chain-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 11 stars11 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.6 KB, as published. Nobody here has run it
Supply-Chain Audit
<!-- SHARED:LANGUAGE_HEADER -->Audit what the project trusts: deps, build pipeline, shipped artifact. Report; do NOT change deps unless asked.
1. Dependencies
- Scope — honor
.coalmine.jsonpackageManifestsif set: scan exactly those manifest/lockfile paths; else infer by inspecting the repo. - CVEs — run ecosystem auditor; cross-check every hit in GHSA/OSV/NVD. Cite advisory ID + affected range + fixed version. (Invoke source-grounding — never from memory.)
- Maintenance — last release, commit recency, bus-factor, archived/deprecated flag.
- License — flag copyleft inside permissive project, missing/unknown license.
- Transitive — full tree; name the parent to bump for a transitive fix.
- Behavior — phone home? install scripts? unexpected egress?
2. Build / CI
- CI-only release builds?
- Actions pinned to commit SHA (not floating tag)?
- Lockfile committed + enforced in CI?
- Minimal token scope? No
pull_request_target?
3. Artifact
- SHA-256 checksums published for every binary?
- Signed (Authenticode/GPG)? Gap documented honestly?
- SBOM generated?
- User can verify before running?
Tooling
Per-ecosystem vuln/license/outdated commands + offline fallback: read references/tooling.md when selecting scanners.
Discipline
- Ground every CVE/fixed-version in an advisory. Never from memory.
- Don't auto-change deps — report + recommend; user decides (bumps break builds).
- State what was NOT scanned. Blocked network scans → lockfile inspection fallback (see
references/tooling.md), mark live checks N-A.
Fix mode (choice-gated)
After the report, present via ask_question:
- Pin safe now — commit already-present unchanged lockfile, pin CI action to current SHA, add missing checksum step. Each: checkpoint → apply → verify.
- Let me pick — user-selected fixes only.
- Report only — change nothing.
NEVER auto-fix: dep version bump, lockfile regen (re-resolves entire transitive tree).
Grants & denials (CLASSIFY-BLOCK)
| class | step it powers | grant | on denial |
|---|---|---|---|
| read | scan manifests/lockfiles; run the ecosystem auditor | Read·Grep·Glob·Bash (read-only) | refuse that manifest, name it in "Not scanned" — never a clean bill |
| write | Fix mode's pin/commit, incl. checkpoint → apply → verify | Edit·Write·Bash (checkpoint/verify need exec) | report the pin as NOT applied AND the checkpoint/verify as NOT available, never claim done |
| network | GHSA/OSV/NVD cross-check | WebSearch·WebFetch (or delegated to source-grounding) | ⚠️ unverified: check [advisory ID] |
Output
| package | direct/transitive | issue | severity | advisory | fixed-in | action |
Build+artifact checklist · Summary (counts + top fixes) · Not scanned
For ReportFindings: file = the manifest/lockfile path that named the package (packageManifests, or the inferred one); line is best-effort (the pin/version line if easily found) or omitted and named imprecise per the shared reporting rail — never fabricate a line.
What ships with it: 2 files
991 B alongside SKILL.md
references/
- tooling.md823 B
- skill-meta.json168 B
Gives 0 of the 12 instructions most dependency audit skills give
Counted across 162 of the 192 authors here whose files we hold, read 2026-09-06
- Verify the gh tool is installed before startingin 10 of 162, across 6 files
- Find git repositories for all direct dependenciesin 9 of 162, across 5 files
- Evaluate every dependency against the risk criteriain 9 of 162, across 5 files
- Normalize repository names to full URLsin 9 of 162, across 5 files
- Query exact star and issue counts using ghin 9 of 162, across 5 files
- Ask the user to install gh if missingin 7 of 162, across 3 files
- Omit low-risk dependencies from the reportin 7 of 162, across 3 files
- Run the full test suite after each changein 7 of 162
- Flag dependencies matching any risk criterion with clear reasonsin 6 of 162, across 2 files
- Commit lockfiles and pin exact dependency versionsin 6 of 162, across 5 files
- Detect package managers from manifest filesin 6 of 162
- Review the changelogs for breaking changesin 5 of 162, across 2 files
Said here and by no other author read
- Audit dependencies, build pipeline, and shipped artifact
- Cross-check every CVE hit in GHSA, OSV, and NVD
- Cite advisory ID, affected range, and fixed version
- Honor configured manifest scope when scanning
- Check maintenance, licenses, and suspicious dependency behavior
- Analyze the full transitive dependency tree
Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once.