Harden

Harden Codebase Skill

Active security hardening: scan the existing repository for vulnerabilities and forward-facing threats, then propose concrete remediations the user can approve, defer, or file.

This skill is the engine behind /harden. It complements the Claude Code built-in /security-review (which scans the pending diff) by sweeping the whole repository against citation-backed checks rather than line-level review of in-flight code.

When To Use

• Quarterly security-posture audits.
• Before tagging a release that touches sensitive code paths.
• After a published advisory affects the language ecosystem.
• When onboarding a new repository and want a baseline.
• After integrating a new dependency or upstream service.

When NOT To Use

• Pending-diff review on a single PR. Use /security-review.
• Architecture-level threat modeling. Use attune:war-room with a security-focused panel.
• Cryptographic protocol review. The skill flags suspect crypto but does not propose protocol fixes (specialist work).
• One-off bug hunting. Use pensive:bug-review.

Required TodoWrite Items

1. harden:discovery: inventory languages, build files, hooks, CI workflows
2. harden:scan-python: run python-checks.md detectors when Python is present
3. harden:scan-rust: run rust-checks.md detectors when Rust is present
4. harden:scan-cross-cutting: run cross-cutting.md detectors (deps, secrets, SBOM, CI)
5. harden:scan-frontier: run frontier-checks.md (PQC, LLM supply chain, sandboxing)
6. harden:nist-mapping: map findings to NIST SSDF practices
7. harden:proposals: for each finding above the threshold, draft a concrete remediation per modules/proposal-shape.md
8. harden:approval-gate: present proposals to the user for apply / file / defer / reject
9. harden:apply-and-validate: apply approved proposals as discrete commits, re-run gates, capture evidence
10. harden:findings-verified: citations confirmed by citation_verifier.py
11. harden:report: write reviews/harden-<date>.md and optionally post to Discussions

Progressive Loading

Load modules based on what the discovery step finds.

The module hub keeps the SKILL.md itself under the estimated_tokens: 1100 budget. Detail lives in the modules.

Core Workflow

Phase 1: Discovery

Inventory the repo without modifying anything:

# Languages and build files
find . -type f \( -name '*.py' -o -name '*.rs' -o -name '*.sh' \) \
  | head -200 > /tmp/harden-langs.txt

# Build manifests
ls pyproject.toml Cargo.toml package.json go.mod 2>/dev/null

# CI workflows and pre-commit
ls .github/workflows/ .pre-commit-config.yaml 2>/dev/null

# Hooks and Dockerfiles
find . -path ./node_modules -prune -o -type f \
  \( -name 'hooks.json' -o -name 'Dockerfile*' \) -print

Dispatch /discovery-prefilter if the repo has > 5000 source files to bound the scan.

Phase 2: Citation-backed scan

For each detected language, load the matching module and run its detector list. Each detector outputs findings with the schema defined in modules/proposal-shape.md. The citation column is mandatory: a finding without a NIST/CWE reference is downgraded to "advisory" and not eligible for active proposal.

Phase 3: NIST mapping

Group findings by SSDF practice (PW.4, PW.8, RV.1, etc.) and CWE ID. The mapping table lives in modules/nist-controls.md. The report's executive summary references SSDF practice coverage so the audit is comparable across runs.

Phase 4: Proposal generation

For each finding above the configured severity threshold, draft a concrete remediation per modules/proposal-shape.md:

• Specific files and lines touched
• Diff or config snippet (not "consider doing X")
• Blast-radius assessment via pensive:blast-radius
• Reversal plan: how to revert if the change breaks behavior
• Test that should pass after the change

Phase 5: Approval gate

Present proposals one at a time via AskUserQuestion. Default options: apply, file as issue, defer to backlog, reject. Auto-apply is opt-in via the --auto-apply flag and respects a per-finding severity threshold.

Phase 6: Apply and validate

Apply each approved proposal as a discrete commit:

git add <touched files>
git commit -m "harden: <finding-id> <one-line summary>"

After each apply, re-run the project gates:

make test --quiet && make lint && make type-check

If a gate fails, revert the commit (git revert HEAD --no-edit) and downgrade the finding to "needs human design."