fable-heal

Fable Heal

fable-redteam が検出した脆弱性に対するセキュリティ修正を自動で合成、適用、検証します。

目的

能動的な脆弱性の発見から、検証済みのコード修正までの隔たりを埋めます。fable-heal は、攻撃的セキュリティ調査の結果（SQL インジェクション、BOLA/IDOR、CORS の設定ミス、セキュリティヘッダーの欠落、機密ファイルの漏えい、SSRF、JWT 署名のバイパス、LLM のプロンプトインジェクション）を、リグレッションを一切発生させない、具体的でテスト済みかつ検証済みのコードパッチに変換します。

使用する場面

• fable-redteam またはセキュリティ監査で、直ちにコードを修正する必要がある脆弱性が特定された場合。
• CI でセキュリティ上の欠陥が再発しないよう、TDD リグレッションテストスイートを自動生成する場合。
• ステージング環境またはローカルブランチで、アトミックなロールバック保護を備えた局所的なコードパッチを適用する場合。
• 候補となるセキュリティパッチが攻撃経路を適切に排除できるか検証する場合。

使用しない場面

• 脆弱性が特定または再現される前（fable-redteam または fable-security を使用してください）。
• セキュリティ以外の一般的なアプリケーションのリファクタリング（fable-simplify を使用してください）。
• 人によるレビューやステージング環境での検証を行わず、本番環境に直接パッチを適用する場合。

入力

• redteam_findings：fable-redteam による構造化された脆弱性の調査結果の配列、またはファイルパス。
• target：対象の HTTP/HTTPS エンドポイント、またはリポジトリのワークスペース。
• dryRun：true の場合、ファイルを変更せずに生成されたパッチと統合差分をプレビューします。
• autoApply：true の場合、一致するコードベースのソースファイルにパッチを書き込みます。
• verify：true の場合、対象に対して攻撃経路を再実行し、脆弱性が解消されたことを確認します。

期待される出力

• security_patches：統合差分を含む具体的なコード置換。
• test/security/redteam-healed.test.ts：脆弱性が解消されたことを検証する実行可能な Bun テストスイート。
• .fable/heal-attestation.json：改ざんを検知できる暗号学的 SHA-256 証明記録。
• .fable/LEDGER.md：修正済みとしてマークされた作業カードの更新。

手順

1. 調査結果の取り込み： fable-redteam、SARIF レポート、または .fable/redteam-findings.json から調査結果を読み込みます。
2. 戦略の選択： 各調査結果のカテゴリと CWE を、局所的な修正パターンに対応付けます。
   • SQL インジェクション（CWE-89）-> パラメーター化クエリ。
   • IDOR/BOLA（CWE-639）-> リソースの所有権を確認するガード。
   • CORS の設定ミス（CWE-942）-> 厳格なオリジン許可リスト。
   • セキュリティヘッダーの欠落（CWE-1021）-> Content-Security-Policy、HSTS、XFO ヘッダー。
   • 機密情報の露出（CWE-200）-> .env、.git、シークレットへのルートアクセスを拒否。
   • SSRF（CWE-918）-> ループバックとクラウドメタデータへのアクセスを遮断する、送信先 URL と IP の検証。
3. パッチの合成： コード変換を生成し、統合差分を計算します。
4. TDD テストの生成： 実行可能なテストアサーションを test/security/redteam-healed.test.ts に出力します。
5. アトミックな適用とガード： 適用する場合、自動バックアップを作成してパッチを書き込みます。構文エラーまたはコンパイルエラーが発生した場合は、サーキットブレーカーでロールバックします。
6. クローズドループ検証： 対象にアクセスできる場合は、検証プローブを実行して修正を確認します。
7. 証明と台帳の確定： 暗号学的 SHA-256 シールを記録し、作業カードをクローズ済みにします。

判断ルール

• 候補パッチの構文チェックまたは型チェックに失敗した場合は、サーキットブレーカーを介して直ちにロールバックします。
• 修正を確定する前に、実行可能な TDD リグレッションテストスイートを必ず生成します。
• dryRun モードではファイルを変更せず、統合差分とプレビューのみを出力します。
• 対象エンドポイントが稼働中で検証が要求されている場合は、完了前に対象をプローブして脆弱性が解消されたことを確認します。
• 適用したすべてのパッチについて、暗号学的な SHA-256 証明を .fable/heal-attestation.json に記録します。

制約

• 自動ロールバック用サーキットブレーカーが設定されていない状態でパッチを適用しないでください。
• アクティブなセキュリティ作業カードをクローズする際に、検証テストを省略しないでください。
• パッチは局所的な変更にとどめ、既存のアプリケーションのビジネスロジックとコメントを維持する必要があります。

ツールポリシー

• src/core/redteam/heal.ts のネイティブ AST パッチ適用機能と正規表現トランスフォーマーを使用します。
• Bun テストランナー（bun test）を実行し、生成された回帰テストスイートを実行します。
• 暗号学的アテステーションの生成には、ネイティブの SHA-256 暗号機能を使用します。

エビデンス要件

• 合成されたパッチには、正確なファイルパス、戦略名、統一差分を含める必要があります。
• 適用したパッチには、構文検証と、test/security/redteam-healed.test.ts での自動回帰テスト生成が必要です。
• .fable/heal-attestation.json に暗号学的修復アテステーションを記録し、適用したすべてのパッチの完全性を検証します。

失敗時の処理

• 候補パッチによって構文エラーまたは型エラーが発生した場合は、サーキットブレーカーを使用して直ちに変更をロールバックします。
• 回帰テストが失敗した場合は、適用したパッチを元に戻し、開発者による手動レビューが必要な問題としてフラグを立てます。
• クローズドループ検証中に対象サーバーが利用できない場合は、パッチの適用を妨げず、検証を保留として記録します。

完了条件

• 特定されたすべての脆弱性の検出結果が、修正戦略に対応付けられていること。
• 脆弱性のある対象に対する統一差分とパッチが合成されていること。
• TDD 回帰テストスイートが生成され、test/security/redteam-healed.test.ts で成功していること。
• 暗号学的アテステーションが .fable/heal-attestation.json に記録されていること。
• 修正状況が .fable/LEDGER.md に記録されていること。