agentsclimarketplace

Supply chain audit

Skill HetCreep/CoalMine/skills/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

Install
npx -y skills add HetCreep/CoalMine --skill supply-chain-audit

Assembled 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.json packageManifests if 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)

classstep it powersgranton denial
readscan manifests/lockfiles; run the ecosystem auditorRead·Grep·Glob·Bash (read-only)refuse that manifest, name it in "Not scanned" — never a clean bill
writeFix mode's pin/commit, incl. checkpoint → apply → verifyEdit·Write·Bash (checkpoint/verify need exec)report the pin as NOT applied AND the checkpoint/verify as NOT available, never claim done
networkGHSA/OSV/NVD cross-checkWebSearch·WebFetch (or delegated to source-grounding)⚠️ unverified: check [advisory ID]
<!-- SHARED:CLASSIFY_BLOCK -->

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.

<!-- SHARED:REPORTING_FOOTER --> <!-- SHARED:ORCHESTRATION --> <!-- SHARED:ESCALATION_FOOTER -->

What ships with it: 2 files

991 B alongside SKILL.md

references/

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.

Keep looking

Skills are one crate of 626,194. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.