Audit supply-chain pinning and dependencies

Separate 'does this package exist' from 'is this reference pinned tightly enough to be reproducible' before trusting either.

Also usesclaude-plugins-official

Two different questions hide under one heading. "Does this package exist?" is answerable against a registry. "Is this reference pinned tightly enough to be reproducible?" is a policy question about mutable refs, and no werkstoff skill answers it alone.

Start here

One prompt to start

Audit our dependencies and supply-chain pinning -- check whether every declared package actually exists before trusting the lockfile, run an adversarial security pass over the manifests and workflows, and then prove whether every third-party reference is actually pinned tightly enough to be reproducible rather than assuming it from the CVE scan alone.

Needsconfab, code-modernization, andon

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

1. confab:confab-dependency-auditalso in 2 other recipes

   • Verify a brief's premises before acting
   • Perform a same-stack version uplift

   Hallucinated and typosquat-adjacent entries are cheapest to catch at declaration time, before a lockfile blesses them.

   Run this beat on its own

   audit every dependency in our manifests — I want to know if any of them don't actually exist or look like typosquats

2. code-modernization:security-auditor

   A standalone adversarial leaf; dispatched directly, without adopting the modernization pipeline.

   Run this beat on its own

   run an adversarial security pass over this repo — OWASP, CVEs in dependencies, secrets, injection

3. andon:andon-verifyalso in 13 other recipes

   • Finish and integrate a development branch
   • Investigate a job that reports success but changed nothing
   • Investigate a fix that did not stick
   • Investigate tests that pass while the code is broken
   • Root-cause a bugfix from a tracked issue
   • Build a new feature in an existing codebase
   • Collapse duplication hand-synced across N sites
   • Execute a written plan across parallel workstreams
   • Migrate a return shape or type representation
   • Propagate a vendored artifact to N copies
   • Audit your own agent and skill definitions for loop-reliability defects
   • Do oracle engineering and numerical V&V
   • Whole-branch review without re-trusting the branch's own self-assessment

   "Everything is pinned" is a contract; a float tag silently violates it and only evidence catches that.

   Run this beat on its own

   we claim every third-party reference is pinned. Prove it or refute it with evidence.

Worked example

Grounded in — why this beat order is trustworthy

every `uses:` reference in `.github/workflows/` is a float tag, not a commit SHA: `actions/checkout@v7`, `anchore/sbom-action@v0`, `actions/attest-build-provenance@v4`, and `pypa/gh-action-pypi-publish@release/v1` — the last a moving branch ref inside the publish path that already emits an SBOM and a provenance attestation.

Do / Don't

• ✓Audit every dependency for existence and typosquat-adjacency before the lockfile blesses it -- cheapest to catch at declaration time.
• ✓Dispatch a standalone adversarial security pass -- OWASP, CVEs, secrets, injection -- without adopting the whole modernization pipeline.
• ✓Prove the pinning claim with evidence -- 'everything is pinned' is a contract, and a float tag violates it silently.

• ×Don't conflate 'does this package exist' with 'is this reference pinned tightly enough to be reproducible' -- they're different questions with different answers.
• ×Don't trust a `uses:` reference just because it names a version tag -- a float tag like `@v7` or `@release/v1` is not a commit SHA and can move underneath you.
• ×Don't assume dependency existence and pin strength both hold just because one of them was checked.