devsecops-supply-chain-audit

name	devsecops-supply-chain-audit
description	Audit software supply chain across every ecosystem (npm, pip, Go, Ruby, Cargo, Maven, Docker, Terraform) — pinning, vulnerabilities, secrets, SBOM, signing, branch protection, CODEOWNERS. One sub-agent per ecosystem. Three modes.
argument-hint	["repo-path"]
allowed-tools	Read Grep Glob Write Edit Bash(bash:*) Agent
effort	high

DevSecOps Supply Chain Audit

ultrathink

Output path directive (canonical — overrides in-body references). All file outputs from this skill MUST be written under .anthril/audits/devsecops-supply-chain-audit/. Run mkdir -p .anthril/audits/devsecops-supply-chain-audit before the first Write call. Primary artefact: .anthril/audits/devsecops-supply-chain-audit/<artefact>. Do NOT write to the project root or to bare filenames at cwd. Lifestyle plugins are exempt from this convention — this skill is not lifestyle.

When to use

Run this skill when the user mentions:

• Supply-chain audit, DevSecOps
• SLSA, SBOM, Dependabot, Renovate
• Dependency security, secrets scanning, SCA
• Branch protection review

Detects every ecosystem in the repo (npm, pnpm, yarn, pip, Poetry, Go modules, Cargo, Bundler, Maven, Gradle, Composer, Docker images, Terraform providers) and spawns one sub-agent per ecosystem. Covers dependency pinning (lockfile committed, exact-vs-range, integrity hashes), vulnerability surface (npm audit, pip-audit, govulncheck, bundler-audit, trivy, grype), secret scanning (gitleaks-style patterns against HEAD and history), SBOM generation (Syft, CycloneDX), provenance and signing (SLSA level, cosign, sigstore, npm --provenance), branch protection, CODEOWNERS coverage, and Dependabot/Renovate configuration.

Before You Start

1. Determine operating mode. --live runs vulnerability scanners available on the system (npm audit, pip-audit, govulncheck, bundler-audit, trivy). --apply can open PRs pinning dependencies, adding dependabot.yml, or hardening branch protection via gh api.
2. Detect ecosystems. Run scripts/detect-ecosystems.sh. One sub-agent per ecosystem detected.
3. Load .secops-ignore for suppression (e.g., accepting a vulnerability in a dev dependency).
4. Sub-agent budget. One agent per ecosystem. 2–6 sub-agents typical.

User Context

$ARGUMENTS

Ecosystems detected: !bash "${CLAUDE_PLUGIN_ROOT}/skills/devsecops-supply-chain-audit/scripts/detect-ecosystems.sh"

Live scanners: !which npm pip-audit govulncheck trivy 2>/dev/null | head -4 || echo "none available"

---

Audit Phases

Phase 1: Discovery & Mode Selection

1. Parse ecosystem output. Set up one sub-agent per ecosystem.
2. Check for repo-wide signals (Dependabot config, CODEOWNERS, branch-protection docs, signing config).
3. Confirm mode with user.

Phase 2: Repo-wide Signal Snapshot

Collect:

• .github/dependabot.yml presence and ecosystem coverage
• renovate.json / .renovaterc presence
• .github/CODEOWNERS presence and coverage
• Branch protection (via gh api repos/:owner/:repo/branches/main/protection in live mode)
• Commit signing (git log --show-signature -1 in live mode)
• SLSA level clues (--provenance in publish workflows, signed releases, reproducible builds)
• SECURITY.md presence
• .gitleaks.toml / secret scan config

Phase 3: Parallel Sub-Agent Audit (one per ecosystem)

Spawn sub-agents simultaneously. Each receives:

• Ecosystem identifier (npm / pip / go / ruby / cargo / maven / docker / terraform)
• Pre-detected manifest files and lockfiles
• The audit taxonomy and severity rubric from reference.md
• The operating mode
• Scanner output from live mode (if available)

Each sub-agent walks categories A–H:

• A. Dependency pinning — lockfile present and committed? exact vs range? integrity hashes where supported (npm integrity, pip hash, cargo checksum, go go.sum)
• B. Vulnerability surface — count CRITICAL/HIGH/MEDIUM/LOW from scanner. Known-actively-exploited CVEs called out.
• C. Secret patterns — gitleaks/trufflehog-style patterns (AWS keys, private key headers, high-entropy strings) across tracked files. Live mode extends to git log -p (history).
• D. SBOM & provenance — SBOM generation configured? SLSA level (L0–L4)? npm publish --provenance for npm packages?
• E. Image signing — cosign config? sigstore? cosign verify works live?
• F. Branch protection (repo-wide) — required reviews, required status checks, signed commits, linear history, restrict deletions
• G. CODEOWNERS — covers sensitive paths (.github/, infra/, auth/, payments/)
• H. Automation — Dependabot / Renovate grouping sensible, security-only fast-lane for critical vulns

Phase 4: Merge & SLSA Self-Assessment

1. Merge sub-agent findings. Apply .secops-ignore.
2. Compute SLSA level per reference.md §3:
   • L0: no provenance
   • L1: provenance generated
   • L2: hosted build with authenticated publish
   • L3: hardened, tamper-evident build service
   • L4: two-party review + reproducible builds
3. Assign SEC-001… IDs.

Phase 5: Remediation Drafting

Per finding, emit actionable remediation:

• Dependency pinning fixes → commented diff for package.json / requirements.txt / go.mod
• Vulnerability surface → npm audit fix / pip install -U commands (but commented — user runs)
• Secret leaks (current files) → listed with file:line and a rotation instruction
• Secret leaks (history) → git filter-repo command block (requires explicit user action)
• Branch protection gaps → gh api PATCH commands (commented)

Output files: devsecops-supply-chain-audit.md, devsecops-supply-chain-audit.json, slsa-self-assessment.md, and sbom.json if generated in live mode.

Phase 6: Apply Mode (opt-in)

Interactive. Per finding:

• Safe: lockfile regeneration, .github/dependabot.yml creation, SECURITY.md stub, CODEOWNERS addition.
• Require confirmation: branch-protection API calls, opening PRs.
• Never auto-applied: history rewrites (git filter-repo), secret rotation, publishing changes.

Phase 7: Reporting

Render report from templates/output-template.md.

---

Scoring

Weights: A=15, B=25, C=20, D=10, E=5, F=15, G=5, H=5 (sum 100). See reference.md §4.

Total	Verdict
90+	PASS
70–89	PASS WITH WARNINGS
50–69	CONDITIONAL
<50	FAIL

---

Important Principles

• Known-exploited CVEs are always CRITICAL. Check against CISA's Known Exploited Vulnerabilities (KEV) catalogue.
• A leaked secret in the current HEAD is CRITICAL even if the secret was later "removed". It's in history. Surface + rotate.
• SLSA L1 is achievable in a weekend. SLSA L3 requires infrastructure. Set expectations.
• Dependabot on its own isn't enough. Many teams enable it and ignore the PRs. Flag if the last 10 Dependabot PRs are unmerged.
• Dev dependencies matter. A compromised dev-dep can exfiltrate secrets during npm install.
• Signed commits are a weak signal alone — combine with branch-protection-required and required-reviews.
• Australian English. DD/MM/YYYY. Markdown-first.

---

Edge Cases

1. Monorepo. Sub-agents may need to walk multiple package.jsons / requirements.txts inside one ecosystem. Aggregate findings per ecosystem.
2. Private registry. If lockfile references a private registry, live-mode scanners may fail with auth errors — record as limitation and continue static.
3. Archived repo. Downgrade findings by one tier; note archival state.
4. First-party code vulnerabilities. Out of scope — refer to software-development plugin.
5. Secrets found in history but rotated. Document but do not suppress — history rewrite is still recommended.
6. No lockfile (pure package.json). CRITICAL for JS/TS, HIGH for Python (requirements.txt without ==).
7. Go modules with replace directives pointing at forks. Audit the fork's provenance.