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

Phase 7: Report

Write reviews/harden-<date>.md with:

• Executive summary (SSDF practice coverage, CWE distribution)
• Findings table grouped by severity
• Per-finding detail: detection signal, citation, proposal, status
• Disposition table (applied / filed / deferred / rejected)
• Re-run instructions

If running inside a PR context, post the executive summary as a comment via abstract:post_review_insights.

Severity Classification

Output Format

# Hardening Report — <date>

## Executive Summary

- Codebase: <repo> @ <sha>
- Languages scanned: Python (X files), Rust (Y files)
- NIST SSDF practices covered: PW.4, PW.7, PW.8, RV.1, RV.2
- CWE Top 25 hits: <count> across <distinct CWEs>
- Disposition: <N> applied, <N> filed, <N> deferred, <N> rejected

## Findings

| ID | Severity | Citation | File:Line | Disposition |
|----|----------|----------|-----------|-------------|
| H1 | CRITICAL | CWE-502, NIST SSDF PW.7 | `src/x.py:45` | applied (commit abc123) |
| H2 | HIGH | CWE-89, NIST SSDF PW.4 | `src/y.py:120` | filed (#456) |

## Per-finding detail

### H1 — Unsafe deserialization

**Citation:** CWE-502 (Deserialization of Untrusted Data),
NIST SSDF PW.7 (Review and analyze human-readable code).

**Detection signal:**
- File: `src/x.py:45`
- Anchor: `data = pickle.loads(user_supplied_input)`
- Pattern: <module>.loads(user_supplied_input)
- Reachability: untrusted, comes from request body

**Proposal:** ...

**Blast radius:** ...

**Reversal plan:** ...

Safety Rails

• Never apply without approval. Even with --auto-apply,

CRITICAL findings always prompt.

• One finding per commit. Reversals are per-finding, not

per-batch.

• Re-run gates after each apply. A gate failure reverts the

commit and downgrades the finding.

• Citation is mandatory. Findings without a NIST/CWE/RustSec

reference are advisory only and skip the apply phase.

• Read-only on first run. First invocation defaults to

--report-only until the user has reviewed at least one report and explicitly opts into proposals.

Integration

The skill composes (rather than re-implements):

• pensive:rust-review: full Rust audit when Rust is present
• pensive:bug-review: bug-hunting backbone
• pensive:safety-critical-patterns: NASA Power-of-10 adapted
• pensive:tiered-audit: three-tier discipline (--tier 1/2/3)
• pensive:blast-radius: change-impact assessment for proposals
• leyline:supply-chain-advisory: dependency posture
• leyline:authentication-patterns: auth/credential review
• leyline:content-sanitization: input handling
• abstract:hook-authoring: hook-event security
• imbue:proof-of-work: evidence discipline for findings

Verify Findings Are Grounded (harden:findings-verified)

Every finding must cite a real location and a verbatim anchor. Write findings to .review/findings.json and confirm each citation resolves:

python plugins/imbue/scripts/citation_verifier.py \
  --findings .review/findings.json --repo-root .

Drop or label UNVERIFIED any finding the verifier fails (exit 1); only verified findings enter the report. See Skill(imbue:review-core) Step 5 and Skill(imbue:structured-output) for the schema.

Exit Criteria

• [ ] Discovery output lists every language and build manifest

detected in the repo.

• [ ] Each finding carries a CWE or NIST SSDF citation; the

report executive summary lists the SSDF practice coverage.

• [ ] Each finding above the severity threshold has a concrete

proposal (file, diff or config snippet, blast radius, reversal plan, expected-passing test).

• [ ] No proposal was applied without explicit user approval

(or without an --auto-apply flag covering its severity).

• [ ] Each applied proposal is its own commit, reversal-friendly.
• [ ] After every apply, the project gates were re-run; any

gate failure reverted the commit and downgraded the finding.

• [ ] reviews/harden-<date>.md exists and lists every finding

with a disposition (applied / filed / deferred / rejected / advisory).

• [ ] Every reported finding carries a Location + verbatim Anchor

confirmed by citation_verifier.py (exit 0), or unverified findings were dropped or labeled UNVERIFIED.

Cross-Cutting Hardening Checks

Checks that apply regardless of the source language: dependency posture, secret hygiene, CI/CD chain, container shape, and the SBOM.

Dependency posture (composes leyline:supply-chain-advisory)

Secret hygiene

CI/CD chain (GitHub Actions example)

Container hardening (when Dockerfiles exist)

SBOM and provenance

# CycloneDX SBOM for the whole repo
syft . -o cyclonedx-json > sbom.cdx.json

# SPDX SBOM (alternative format)
syft . -o spdx-json > sbom.spdx.json

# Verify against the in-toto attestation if released
cosign verify-attestation --type slsaprovenance \
  --certificate-identity-regexp '.*' --certificate-oidc-issuer-regexp '.*' \
  ghcr.io/<org>/<image>:<tag>

The hardening report includes an SBOM-coverage row: present / absent for each release artifact in the repo.

Pre-commit security suite

The skill proposes adding (or extending) .pre-commit-config.yaml with:

repos:
  - repo: https://github.com/PyCQA/bandit
    rev: 1.7.10
    hooks:
      - id: bandit
        args: ["-c", "pyproject.toml"]
        additional_dependencies: ["bandit[toml]"]
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.21.2
    hooks:
      - id: gitleaks
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.5.0
    hooks:
      - id: detect-secrets
        args: ["--baseline", ".secrets.baseline"]

If cargo is on PATH:

  - repo: local
    hooks:
      - id: cargo-deny
        name: cargo deny
        entry: cargo deny check
        language: system
        files: 'Cargo\.(toml|lock)$'

Severity defaults

A finding can be promoted from default with evidence (e.g., DEP01 promoted to HIGH if the lockfile is missing AND auto-merge is enabled on dep PRs).

Frontier Hardening Checks (2025-2026)

Forward-facing checks that defend against threats just emerging in production. Findings here are usually MEDIUM by default because exploitation is non-trivial; promote to HIGH when the codebase has a high-value attack surface (auth provider, signing service, data plane).

Post-quantum migration readiness

The NSA CNSA 2.0 timeline targets quantum-resistant crypto for NSS by 2030; PCI DSS 4.0.1 expects an inventory by 2026. Most application code is not the right place to swap algorithms, but the crypto-agility posture is.

The proposal for PQ02 is usually a small refactor: move algorithms = ["EdDSA"] into a config table the operator can override. The skill does not propose ML-DSA / Falcon migration in application code (still specialist work).

LLM and agentic supply chain

A new failure mode in 2025: AI assistants suggest dependencies that look plausible but do not exist (or are typosquats). The checks below defend the development pipeline itself.

Sandbox / isolation posture

For codebases that execute user-supplied or AI-supplied code:

eBPF / runtime security hooks

Production codebases benefit from runtime monitoring even when the static defenses are good. The skill flags absence:

Differential-privacy / PETs awareness

For codebases that handle aggregable user data (analytics, ML training, telemetry):

Memory-safety migration triage (when C/C++ is present)

Per CISA's "Secure by Design" pledge and the ONCD memory-safety report (Feb 2024), new code in safety-critical contexts should be in a memory-safe language by default. The skill flags the opportunity, not the migration:

Output

Findings here use the same schema as the other modules. Severity is MEDIUM by default; promote to HIGH when:

• The repo is an auth/signing/credentialing service (PQ findings)
• The repo ships an MCP server or agent harness (LLM findings)
• The repo has untrusted-code-exec posture (SB findings)
• The repo handles regulated PII (DP findings)

NIST and CWE Citation Backbone

Every finding in a hardening report carries a citation. This module is the lookup table.

NIST SSDF (SP 800-218) practice mapping

The Secure Software Development Framework defines four practice groups: Prepare the Organization (PO), Protect Software (PS), Produce Well-Secured Software (PW), Respond to Vulnerabilities (RV). Findings map to PW and RV most often.

The skill's executive summary lists each practice and whether the codebase has at least one detector firing for it. Coverage <80% of PW.4-PW.9 is itself a finding (RV.1 unmet).

CWE Top 25 (2024) mapping

The skill prioritizes detectors that map to the CWE Top 25 most dangerous software weaknesses. Per-finding citations name the specific CWE, not just "Top 25."

OWASP ASVS level targets

Findings track the ASVS level they aim at:

RustSec advisory database

For Rust findings, cite the specific advisory ID (RUSTSEC-YYYY-NNNN). The cargo audit JSON output contains these directly. Use them in the proposal's reversal plan to explain why the upgrade is required.

How findings cite

Each finding's Citation: line names:

1. Primary CWE (always) 2. NIST SSDF practice (always; pick the closest match) 3. Optional: OWASP ASVS section, RustSec ID, PEP number, CVE

Example:

Citation: CWE-502 (Deserialization of Untrusted Data),
NIST SSDF PW.7 (Review and analyze human-readable code),
OWASP ASVS V5.5 (Deserialization Prevention).

A finding with no primary CWE cannot be classified above ADVISORY severity.

Proposal Shape

Every proposed remediation in a hardening report follows this schema. The schema is not optional: a finding without a complete proposal cannot be applied (the user can still choose to file or defer it).

Required fields

Severity to default disposition

CRITICAL findings always prompt even under --auto-apply.

Blast radius scale

The proposal queries Skill(pensive:blast-radius) for the change-impact graph and reports one of:

High-blast-radius proposals require explicit approval even under --auto-apply. The skill warns when the radius rises above the user's current --auto-apply ceiling.

Reversal plan template

Reversal:
  command: git revert <sha> --no-edit
  retry condition: <when it would be safe to reapply>
  evidence file: reviews/harden-<date>.md (this report)

For config changes that cannot be reverted by git revert alone (e.g., a CI permission change that runs only on push):

Reversal:
  command: git revert <sha> --no-edit
  follow-up: re-trigger the workflow on master to confirm the
             permissions are restored
  evidence file: reviews/harden-<date>.md

Expected-passing test

Each proposal cites a test that should pass after the change:

• If a test already exists, name it: tests/unit/x.py::test_y.
• If a test must be added, the proposal includes the test code in

the same diff block. The test must fail against the pre-proposal code (RED) and pass after (GREEN).

A proposal without an expected test is downgraded to ADVISORY. This is the harden equivalent of Skill(imbue:proof-of-work)'s Iron Law.

Approval options (per finding)

When the approval gate fires, the user gets:

1. apply: apply the diff, commit, run gates, advance. 2. file: create a GitHub issue with the proposal body and close out the finding. 3. defer: log to .harden/backlog.md for future runs to surface again. 4. reject: record a rejection with optional rationale; the finding will not surface again unless code changes invalidate the rejection.

The auto-apply ceiling determines which severities skip the gate entirely:

/harden --auto-apply low      # apply LOW automatically
/harden --auto-apply medium   # apply LOW + MEDIUM automatically
/harden --auto-apply high     # apply LOW + MEDIUM + HIGH automatically

CRITICAL is never auto-applied.

Worked example

id: PY01
severity: HIGH
citation: "CWE-502 (Deserialization of Untrusted Data), NIST SSDF PW.7"
file: src/api/loader.py
lines: 42-44
detection_signal: |
  Module imports the Python stdlib unsafe-deserialization helper
  and calls its loads() helper on bytes that originate from the
  request body (data flows from request.body through validate()
  into loader.loads()).
proposal: |
  Replace the unsafe loader call with json.loads. The payload
  shape is JSON-compatible per the API spec (verified by reading
  the OpenAPI schema for /v1/upload). This eliminates the
  arbitrary-code-execution attack path while preserving the
  positive-path behavior.
diff: |
  --- a/src/api/loader.py
  +++ b/src/api/loader.py
  @@ -42,3 +42,5 @@
  -from <stdlib-unsafe-loader> import loads
  +import json
  -    obj = loads(payload)
  +    obj = json.loads(payload)
blast_radius: low
reversal_plan:
  command: "git revert <sha> --no-edit"
  retry_condition: "do not retry; the previous form was unsafe by design"
  evidence_file: "reviews/harden-2026-05-10.md"
expected_test: tests/unit/api/test_loader.py::test_round_trip_json

Multi-file proposals

When a hardening fix needs touches across multiple files (e.g., adding a Tier Literal requires updates in classifiers, the DORAMetrics dataclass, and the tests), split into sibling proposals (PY01a, PY01b, PY01c) with a shared parent_id. The approval gate applies them as one unit, but each is its own commit so reverts stay surgical.

What a proposal must NOT do

• Modify generated code, vendored code, or node_modules.
• Touch the changelog except to add a ### Security bullet.
• Bump dependency versions beyond the minimum required for the

fix (a separate proposal per dep upgrade).

• Introduce a new dependency without an imbue:proof-of-work

evidence trail showing the dep was vetted.

• Disable existing tests or assertions to make the fix easier.

Python Hardening Checks

Detectors for Python codebases. Each row is a discrete check the skill runs; each carries a CWE citation for the report.

The detection-signal column uses placeholder syntax for patterns that the project's pre-commit security hooks block writing literally. The hooks exist for a reason: this doc describes the rules, but the regexes themselves live in code where the safety review treats them as data, not source. If a future contributor needs to inspect the literal patterns, see the corresponding detector module under plugins/pensive/skills/harden/detectors/ (future work; not part of the v1 skill).

Detection ruleset

Library substitution table

When a finding fires, the proposal usually swaps the offending library or call. The substitution table:

Static-analyzer integration

Run the canonical Python security tools and treat their findings as first-class harden findings:

# Bandit ruleset (PyCQA-maintained AST scanner)
uv run bandit -r src/ -f json -o /tmp/harden-bandit.json

# pip-audit on the lockfile (PyPA + Trail of Bits, OSV-backed)
uv run pip-audit --lockfile uv.lock --format json > /tmp/harden-pipaudit.json

# osv-scanner reads pyproject + lockfiles + Cargo.lock
osv-scanner --format json . > /tmp/harden-osv.json

# semgrep with the security-audit ruleset
semgrep --config=p/python --json --output=/tmp/harden-semgrep.json

Findings from these tools convert to the harden schema by joining on file:line and severity. A bandit B301 finding (the unsafe deserialization rule) becomes the same finding shape as the internal PY01 detector, so the report does not double-count.

Frontier Python concerns (2025-2026)

Loaded from frontier-checks.md for full coverage. Brief list:

• PEP 740 sigstore attestations on PyPI (verify before install);

see Trail of Bits' "Attestations: a new generation of signatures on PyPI" (Nov 2024).

• Tarfile member filter (PEP 706): tarfile.data_filter default

in Python 3.12+; verify the codebase does not still pass filter=None.

• pyproject.toml [[tool.uv.index]] priority pinning to defeat

dependency confusion attacks.

• LLM SDK prompt-injection patterns and MCP server hardening

(CWE-1426; OWASP LLM Top 10 #01, #02).

• ASGI middleware request smuggling (CVE-2024-23829 class).
• Sandboxing application code: WASM (Pyodide), gVisor, nsjail.
• Slopsquatting / package hallucination (arXiv 2406.10279):

LLM-suggested non-existent packages later registered as malware. Mitigation: lockfile and --require-hashes and human review on every dep addition.

Output schema

Each Python finding follows the schema in modules/proposal-shape.md. The detection-signal text uses safe placeholders so the doc itself does not trip secret-scanners or the project's security pre-commit hooks; the actual scanner emits the literal pattern with file:line context in the report.

Rust Hardening Checks

Detectors for Rust codebases. The Rust ecosystem ships strong default safety; the harden skill verifies the discipline is actually applied and the supply chain is curated.

For a deep ownership/unsafe audit, the skill defers to Skill(pensive:rust-review). This module focuses on the hardening posture (capability use, supply-chain hygiene, side-channel defense) and frontier 2025-2026 practices.

Detection ruleset

Tooling integration

# Vulnerability scan against RustSec advisory DB
cargo audit --json > /tmp/harden-cargo-audit.json

# Policy enforcement (license, advisory, source, ban list)
cargo deny check --format json 2>/tmp/harden-deny.json

# Cryptographic-supply-chain audit
cargo vet check 2>&1 | tee /tmp/harden-vet.log

# Unsafe block inventory (third-party tool; requires install)
cargo geiger --output-format json > /tmp/harden-geiger.json

# Mutation testing (high-leverage; expensive)
cargo mutants --in-diff origin/main..HEAD --no-times --json

The harden report joins these on file:line and advisory ID.

Capability-style hardening (frontier 2025-2026)

These are recommendations rather than blocking findings: surface in the report as MEDIUM advisories with the rationale in the proposal.

Concurrency hardening

Compiler hardening flags

In .cargo/config.toml:

[target.'cfg(all())']
rustflags = [
    # Stack-smashing protection
    "-C", "force-frame-pointers=yes",
    # Disable sources of UB
    "-D", "warnings",
    # Treat unsafe-op-without-unsafe-fn as error in 2024 edition
    "-D", "unsafe_op_in_unsafe_fn",
]

For sanitizer-instrumented test runs:

RUSTFLAGS="-Z sanitizer=address" cargo +nightly test --target x86_64-unknown-linux-gnu

Output schema

Same as python-checks.md. Each Rust finding emits a single proposal with diff, blast radius, reversal plan, and expected test. RustSec IDs go in the citation column when applicable.