mcpField
H
harden

harden

github.com/atholaセキュリティ34348 回インストール2 日前に更新
リポジトリ

harden について

hardenは、定期監査、リリース前の確認、依存関係の変更後の評価に使うコードベースのセキュリティ強化スキルです。検出した言語やリポジトリの特徴に応じて根拠付きスキャンを行い、承認を得て修正を提案・適用・検証します。

主な機能

  1. 01言語、ビルドファイル、フック、CIの棚卸し
  2. 02Python、Rust、横断的なチェックによるスキャン
  3. 03検出事項をNIST SSDFとCWEに対応付け
  4. 04具体的な修正案の作成
  5. 05承認済みの変更を個別に適用し再チェック
  6. 06対応状況を含む監査レポートの作成

活用シーン

  1. 01四半期ごとのコードベースセキュリティ監査
  2. 02機密コードに関わるリリース前のリスク確認
  3. 03依存関係や上流サービス追加後の安全性評価
  4. 04新しいリポジトリのセキュリティ基準作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/athola/claude-night-market --skill harden

インストール後、Claude Code で/hardenを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

modules/
cross-cutting.md
frontier-checks.md
nist-controls.md
proposal-shape.md
python-checks.md
rust-checks.md

詳細

コードベース強化スキル

セキュリティ強化を積極的に実施します。既存のリポジトリをスキャンして脆弱性と将来的な脅威を特定し、ユーザーが承認、保留、または起票できる具体的な修正案を提示します。

このスキルは /harden の中核となる仕組みです。保留中の差分をスキャンする Claude Code 組み込みの /security-review を補完し、進行中のコードを行単位でレビューするのではなく、引用元を示したチェック項目に基づいてリポジトリ全体をくまなく調査します。

使用する場面

  • 四半期ごとのセキュリティ態勢監査。
  • 機密性の高いコードパスに関わるリリースにタグを付ける前。
  • 公開されたアドバイザリが言語エコシステムに影響する場合。
  • 新しいリポジトリのオンボーディング時にベースラインを確立する場合。
  • 新しい依存関係やアップストリームサービスを統合した後。

使用しない場面

  • 単一の PR の保留中の差分レビューには使用しません。/security-review を使用してください。
  • アーキテクチャレベルの脅威モデリングには使用しません。セキュリティに重点を置いたパネルとともに attune:war-room を使用してください。
  • 暗号プロトコルのレビューには使用しません。このスキルは疑わしい暗号処理にフラグを立てますが、プロトコルの修正案は提示しません(専門家の作業です)。
  • 単発のバグ探しには使用しません。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 を使って、提案を1件ずつ提示します。デフォルト の選択肢は、適用、issue として登録、バックログに保留、 却下です。自動適用は --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セキュリティ関連のスタイルやドキュメントの不足issue として登録
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 の検出結果は常に確認を求めます。
  • 1つの検出結果につき1つのコミットにします。 取り消しはバッチ単位ではなく、 検出結果ごとに行います。
  • 適用のたびにゲートを再実行します。 ゲートが失敗した場合は、 コミットを取り消し、検出結果を格下げします。
  • 引用は必須です。 NIST/CWE/RustSec の参照がない検出結果は助言のみとし、 適用フェーズをスキップします。
  • 初回実行は読み取り専用です。 初回の実行では、ユーザーが少なくとも1件の レポートを確認し、提案を明示的に許可するまで、デフォルトで --report-only が指定されます。

統合

このスキルは、以下を再実装するのではなく、組み合わせて使用します。

  • pensive:rust-review:Rust がある場合の完全な Rust 監査
  • pensive:bug-review:バグ探しの基盤
  • pensive:safety-critical-patterns:NASA の Power-of-10 を適用
  • pensive:tiered-audit:3段階の規律(--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が存在し、処置(applied / filed / deferred / rejected / advisory)を記載したすべての指摘が含まれています。
  • 報告された各指摘に、citation_verifier.py(終了コード0)で確認済みのLocationと逐語的なAnchorが含まれています。確認できていない指摘は削除するか、UNVERIFIEDとラベル付けされています。

コメント