harden

加固代码库技能

主动强化安全性：扫描现有代码库中的漏洞和前瞻性威胁，然后提出具体的修复方案，供用户批准、推迟处理或记录。

此技能是 /harden 的核心。它与 Claude Code 内置的 /security-review（扫描待提交的差异）互为补充，会针对整个代码库执行基于引用的检查，而不是逐行审查正在开发的代码。

适用场景

• 每季度进行安全态势审计。
• 发布涉及敏感代码路径的版本前。
• 发布的安全公告影响到语言生态后。
• 接手新代码库并希望建立基线时。
• 集成新的依赖项或上游服务后。

不适用场景

• 审查单个 PR 中待提交的差异。请使用 /security-review。
• 架构层面的威胁建模。请使用 attune:war-room 并组建以安全为重点的评审小组。
• 密码协议审查。此技能会标记可疑的加密方案，但不会提出协议修复方案（这需要专家处理）。
• 一次性查找 Bug。请使用 pensive:bug-review。

必需的进度项

1. harden:discovery：盘点语言、构建文件、钩子和 CI 工作流
2. harden:scan-python：存在 Python 时运行 python-checks.md 中的检测器
3. harden:scan-rust：存在 Rust 时运行 rust-checks.md 中的检测器
4. harden:scan-cross-cutting：运行 cross-cutting.md 中的检测器（依赖项、密钥、SBOM、CI）
5. harden:scan-frontier：运行 frontier-checks.md（PQC、LLM 供应链、沙箱）
6. harden:nist-mapping：将发现映射到 NIST SSDF 实践
7. harden:proposals：对于每项超过阈值的发现，根据 modules/proposal-shape.md 起草具体的修复方案
8. harden:approval-gate：向用户展示修复方案，供其选择应用、记录、推迟或拒绝
9. harden:apply-and-validate：将获批的修复方案作为独立提交应用，重新运行门禁检查并收集证据
10. harden:findings-verified：通过 citation_verifier.py 确认引用
11. harden:report：编写 reviews/harden-<date>.md，并可选择发布到 Discussions

渐进式加载

根据发现步骤的结果加载模块。

检测到	加载
Python 文件（*.py、pyproject.toml）	modules/python-checks.md
Rust 文件（*.rs、Cargo.toml）	modules/rust-checks.md
任意情况	modules/nist-controls.md（引用依据）
任意情况	modules/cross-cutting.md（依赖项、密钥、CI）
使用 LLM SDK（anthropic、openai）、MCP 服务或后量子相关面	modules/frontier-checks.md
启用修复方案时的任意情况	modules/proposal-shape.md

模块中心会将 SKILL.md 自身控制在 estimated_tokens: 1100 的预算内。详细内容位于各模块中。

核心工作流

阶段 1：发现

盘点代码库，不做任何修改：

# 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

如果代码库的源文件超过 5000 个，则分派 /discovery-prefilter，以限制扫描范围。

阶段 2：基于引用的扫描

针对检测到的每种语言，加载对应模块并运行其检测器列表。每个检测器都会根据 modules/proposal-shape.md 中定义的架构输出发现结果。引用列为必填项：没有 NIST/CWE 参考的发现会降级为“提示”，不符合主动提出修复方案的条件。

阶段 3：NIST 映射

按 SSDF 实践（PW.4、PW.8、RV.1 等）和 CWE ID 对发现进行分组。映射表位于 modules/nist-controls.md。报告的执行摘要会列出 SSDF 实践覆盖情况，以便对不同轮次的审计进行比较。

阶段 4：生成修复方案

对于每项严重性超过已配置阈值的发现，根据 modules/proposal-shape.md 起草具体的修复方案：

• 涉及的具体文件和行
• 差异或配置片段（而非“考虑执行 X”）
• 通过 pensive:blast-radius 评估影响范围
• 回退计划：如果更改导致行为异常，如何撤销
• 更改后应通过的测试

阶段 5：审批关卡

通过 AskUserQuestion 一次展示一项提案。默认 选项：应用、作为问题提交、推迟到待办事项、 拒绝。只有主动选择 --auto-apply 标志才会自动应用， 并且会遵循每项发现对应的严重性阈值。

阶段 6：应用并验证

将每项获批提案作为独立提交应用：

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

每次应用后，重新运行项目关卡：

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

如果某个关卡失败，则撤销该提交（git revert HEAD --no-edit）， 并将该项发现降级为“需要人工设计”。

阶段 7：报告

将报告写入 reviews/harden-<date>.md，内容包括：

• 执行摘要（SSDF 实践覆盖情况、CWE 分布）
• 按严重性分组的发现表
• 每项发现的详情：检测信号、引用、提案、状态
• 处置表（已应用 / 已提交 / 已推迟 / 已拒绝）
• 重新运行说明

如果在 PR 上下文中运行，则通过 abstract:post_review_insights 发表评论，发布执行摘要。

严重性分类

严重性	定义	默认处置
CRITICAL	存在可利用的攻击路径、RCE、凭据泄露	立即应用或提交
HIGH	存在合理的利用可能，或攻击面缺少纵深防御	提议应用
MEDIUM	不符合最佳实践，存在加固机会	提议应用，并使用 --auto-apply medium
LOW	与安全相关的风格 / 文档问题	作为问题提交
ADVISORY	检测到某种模式，但没有利用场景说明	仅报告

输出格式

# 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:** ...

安全护栏

• 未经批准绝不应用。 即使使用 --auto-apply， CRITICAL 级别的发现也始终需要确认。
• 每项发现单独提交。 撤销操作针对单项发现，而非 整批发现。
• 每次应用后重新运行关卡。 如果关卡失败，则撤销 提交并降低该项发现的级别。
• 必须提供引用。 没有 NIST/CWE/RustSec 参考资料的发现仅作为建议，并跳过应用阶段。
• 首次运行时只读。 首次调用默认使用 --report-only，直到用户至少审阅过一份 报告，并明确选择启用提案。

集成

该技能组合使用（而非重新实现）以下功能：

• pensive:rust-review：存在 Rust 时进行完整的 Rust 审计
• pensive:bug-review：漏洞搜寻的核心
• pensive:safety-critical-patterns：经调整以适用于 NASA 的 Power-of-10
• pensive:tiered-audit：三层审计纪律（--tier 1/2/3）
• pensive:blast-radius：评估提案的变更影响
• leyline:supply-chain-advisory：依赖项安全态势
• leyline:authentication-patterns：认证 / 凭据审查
• leyline:content-sanitization：输入处理
• abstract:hook-authoring：钩子事件安全
• imbue:proof-of-work：发现的证据纪律

验证发现是否有据可依（harden:findings-verified）

将发现写入 .review/findings.json，运行引用验证器 （Skill(imbue:review-core) 第 5 步），并删除验证器拒绝的发现， 或将其标记为 UNVERIFIED。

退出标准

• 发现结果列出仓库中检测到的每种语言和构建清单。
• 每项发现均附有 CWE 或 NIST SSDF 引用；报告执行摘要列出 SSDF 实践覆盖情况。
• 每项严重性高于阈值的发现均附有具体提案（文件、差异或配置片段、影响范围、回退计划、预期通过的测试）。
• 未经用户明确批准（或未使用覆盖其严重性的 --auto-apply 标志），不得应用任何提案。
• 每项已应用的提案均单独提交，且便于回退。
• 每次应用后均重新运行项目门禁；如果任何门禁失败，则回退该提交并降低该发现的级别。
• reviews/harden-<date>.md 文件存在，并列出每项发现及其处置方式（已应用 / 已记录 / 已延期 / 已拒绝 / 仅供参考）。
• 每项报告的发现均带有经 citation_verifier.py（退出码为 0）确认的 Location + 原文 Anchor；否则，未验证的发现已删除或标记为 UNVERIFIED。