/harden

name: harden
description: Applies NIST/CWE security hardening to Python and Rust code. Use when auditing code for vulnerabilities or proposing concrete security remediations.
globs: "**/*.{py,rs,toml,yaml,yml,sh}"
alwaysApply: false
category: security
tags:
- security
- hardening
- nist
- supply-chain
- python
- rust
- cwe
tools: []
provides:
  governance:
  - hardening-report
  - remediation-proposal
  security:
  - vuln-detection
  - hardening-posture
usage_patterns:
- security-hardening
- quarterly-posture-audit
- pre-release-security-gate
complexity: advanced
estimated_tokens: 1100
progressive_loading: true
dependencies:
- pensive:safety-critical-patterns
- pensive:rust-review
- pensive:bug-review
- pensive:tiered-audit
- pensive:blast-radius
- leyline:supply-chain-advisory
- leyline:authentication-patterns
- leyline:content-sanitization
- abstract:hook-authoring
- imbue:proof-of-work
- imbue:review-core
- imbue:structured-output
modules:
- modules/nist-controls.md
- modules/python-checks.md
- modules/rust-checks.md
- modules/cross-cutting.md
- modules/frontier-checks.md
- modules/proposal-shape.md

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 Progress 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.

| Detected | Load | |----------|------| | Python files (`*.py`, `pyproject.toml`) | `modules/python-checks.md` | | Rust files (`*.rs`, `Cargo.toml`) | `modules/rust-checks.md` | | Any | `modules/nist-controls.md` (citation backbone) | | Any | `modules/cross-cutting.md` (deps, secrets, CI) | | LLM SDK use (`anthropic`, `openai`), MCP server, post-quantum surface | `modules/frontier-checks.md` | | Any with proposals enabled | `modules/proposal-shape.md` |

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 t