fable-security

Fable Security

攻撃者が制御できるパスと信頼境界をたどり、すべてのセキュリティ上の指摘について、具体的なソース、シンク、前提条件、影響を特定します。

ミッション

セキュリティレビューは、シークレットスキャンと一般的なチェックリストを組み合わせたものではありません。攻撃者が何を制御できるのか、その入力がどの権限境界やデータ境界を越え得るのか、どのような強制が必要なのか、そして障害や並行処理が発生しても変更後のコードでその性質が保たれるのかを確認します。

スキャナーで問題が検出されなかったことは、スキャン範囲を示す証拠であって、設計が安全であることの証明ではありません。

有効化する場合

• 認証、認可、セッション、トークン、権限、テナント、または特権操作が変更される場合。
• 信頼できない入力がパーサー、クエリー、テンプレート、ファイル、URL、シェル、Webhook、またはデシリアライザーに渡される場合。
• シークレット、認証情報、または暗号鍵を扱う場合。
• 差分によって信頼境界、ネットワークへの公開範囲、ストレージアクセス、パッケージのインストール処理、またはサンドボックス化が変更される場合。
• 報告された脆弱性や指摘の検証、または重大度の調整が必要な場合。
• リポジトリやパッケージのサプライチェーンに関する動作のセキュリティレビューが必要な場合。

有効化しない場合

• セキュリティ上の確認事項がなく、機能検証のみを行うタスクの場合（fable-verify）。
• 一般的な保守性レビューで、信頼境界への影響がない場合（fable-review）。
• 脆弱性の検証がすでに完了しており、ユーザーが範囲を限定した修正のみを求めている場合（セキュリティ上の受け入れ条件を維持したうえで、fable-execute）。

セキュリティ作業の分類

モード	主な問い
脅威モデル	どのような資産、アクター、境界、悪用経路が存在するか。
セキュリティ差分レビュー	この差分でどのようなセキュリティ特性が変わったか。
指摘の検証	攻撃者が制御するデータは、実際に機密性の高いシンクに到達し得るか。
リポジトリ監査	どの公開範囲を詳しく調査すべきか。
シークレットの衛生管理	機密値がソース、ログ、成果物に入り込む可能性はあるか。
サプライチェーン／パッケージ	依存関係、インストール、ビルドの境界を悪用できるか。

プロトコル

ステージ 1 — 資産、アクター、信頼境界を定義する

以下を特定します。

• 保護対象の資産、データ、操作。
• 認証済み、未認証、特権を持つアクター。
• テナントやユーザーの所有権境界。
• 外部システム、Webhook、プラグイン。
• プロセス、ファイルシステム、ネットワークにおける権限の移行。

境界を明示しないセキュリティ上の結論は、たいてい曖昧すぎます。

ステージ 2 — 攻撃者が制御する入力から影響までをたどる

該当するエントリーポイントごとに、次の流れをたどります。 source → parsing/normalization → validation → authorization → transformation → sensitive sink/side effect

各セキュリティ特性がどこで強制されるのか、また後続の変換で以前の検証が無効になり得るかを記録します。

ステージ 3 — 境界に応じた特性を確認する

関連する項目として、以下を検討します。

• 認証と認可の分離。
• オブジェクト／テナントの所有権（IDOR／BOLA）。
• CSRF／状態のバインドとリダイレクトの検証。
• インジェクション、クエリー、テンプレート、シェルの境界。
• パストラバーサル、シンボリックリンク、アーカイブの展開。
• SSRF、URL、DNS、リダイレクトの処理。
• ファイルアップロードにおけるコンテンツ、サイズ、保存、実行の境界。
• デシリアライズやパーサーに対するリソースの悪用。
• セッション／トークンの有効期限、リプレイ、ローテーション、オーディエンス／発行者。
• ログ、エラー、成果物におけるシークレット。
• フェイルオープンするエラー処理。
• 競合状態／TOCTOU、認可におけるチェックと実行の間の問題。
• 設定、プラグイン、フックを介した権限昇格。
• 依存関係、インストールスクリプト、サプライチェーンに関する前提。

ステージ 4 — 障害時と代替経路をモデル化する

以下を確認します。

• 検証サービスが失敗した場合、どうなるか。
• 拒否がデフォルトか、それともコードが処理を続行するか。
• リトライによって特権操作が重複し得るか。
• 攻撃者がチェックと使用の間に状態を変更できるか。
• バックグラウンドジョブは認可を再確認するか、それとも呼び出し元の古いクレームを信頼するか。
• リダイレクト、プロキシ、パーサーが検証後に値を変換するか。

ステージ 5 — 調査結果を批判的に検証する

候補となる調査結果ごとに、以下を明らかにします。

• 攻撃者に必要な前提条件／制御権
• 到達可能なソース
• 正確なシンク／特権的な影響
• 欠落している、または回避されている制御
• 現実的な悪用経路
• 影響／対象範囲
• 深刻度を無効化または軽減する可能性のある既存の緩和策

危険な API が存在するという理由だけで、脆弱性を報告してはいけません。

ステージ 6 — 深刻度を適切に評価する

深刻度は、スキャナーのラベルだけでなく、悪用可能性、得られる権限、データ／テナントの対象範囲、必要な条件によって決まります。

必須のセキュリティ特性に違反する、現実的に悪用可能な問題には blocking を使用します。不確かな候補は、深刻度を誇張せず、検証が必要としてマークします。

ステージ 7 — 範囲を限定した修正の根拠を示す

修正の推奨事項では、回復すべき特性と、それを証明する方法を明記します。例：変更前にテナントの所有権をアトミックに強制する、シンボリックリンク解決後にパスが正規化された範囲内にあることを確認する、正規化された宛先にリダイレクトの許可リストを適用する。

ステージ 8 — セキュリティと機能を分けて扱う

セキュリティ上の根拠はリリースをブロックできますが、機能テスト、ビルド、実行時の根拠の代わりにはなりません。修正後は、セキュリティ固有の検証と機能検証の両方が必要になる場合があります。

判断ルール

• 認証で証明されるのは本人確認です。リソース／アクションに対する認可が証明されるわけではありません。
• 特に非同期／バックグラウンド処理との境界では、可能な限り機微な副作用の直前で検証／認可を行います。
• 変換によって意味が変わる可能性がある場合は、範囲内判定／許可リスト判定の前に正規化／正準化します。
• 宛先／アクションが限定されている場合は、ブロックリストより許可リスト／ケイパビリティチェックを優先します。
• 現在のソースから削除されたシークレットも、Git の履歴／ログ／成果物に残っている可能性があります。漏えいが現実的に疑われる場合は、公開された認証情報をローテーションします。
• 攻撃者が制御できる到達可能な経路がないスキャナーの検出結果は、自動的に悪用可能とはみなされません。ソースからシンクまでを検証します。
• スキャナーで問題が検出されなくても、設計レベルの認可／ロジック上の脅威が解消されたとは限りません。
• 実システムに対して破壊的なエクスプロイトペイロードを実行してはいけません。安全なローカル環境／フィクスチャでの実証、またはコードパスの推論を使用します。
• 修正によって製品の動作が変わる場合は、TDD／実装に引き継ぎ、その後に機能検証を必須とします。

不変条件

• 生のシークレットを証拠やログに再現しません。
• 報告するすべての脆弱性には、具体的な失敗特性と到達可能な経路が必要です。そうでない場合は、未検証であることを明確に示します。
• テナント／リソースの認可は、ログイン状態とは独立して評価します。
• 明示的に修正作業へ移行しない限り、セキュリティレビューは読み取り専用です。
• 機能の正しさとセキュリティの正しさは、別個の証拠クラスとして扱います。

失敗の分類

誤検知

危険なプリミティブは存在するものの、攻撃者がソースを制御できない、シンクに到達できない、または緩和策によって阻止されます。根拠を示して、重要度を下げるか報告対象から除外します。

隠れた信頼境界の移行

コードがキュー／プラグイン／プロキシ／バックグラウンド処理／ストレージの境界を越え、上流で検証済みだと想定しています。必要な特性を追跡し、再検証します。

フェイルオープン経路

制御のエラー／タイムアウト時に、特権的な動作へフォールスルーします。優先度の高い境界障害として扱います。

TOCTOU／競合状態

認可／範囲内判定のチェックと副作用が分離されており、状態が変化する可能性があります。アトミックなプリミティブまたは再検証を検討します。

サニタイズの不一致

デコード／正規化／リダイレクト／シンボリックリンク解決の前に検証が行われています。シンク境界で正準化された値を確認します。

シークレットの漏えい

認証情報がソース／ログ／成果物／履歴に入りました。該当する場合は、漏えい経路を取り除き、ローテーション／封じ込めを必須とします。

アンチパターン

• 「重大な CVE がないため、安全である」と判断すること。
• 変更されたパスを追跡せず、一般的な OWASP チェックリストを適用すること。
• 認証済みユーザーと認可済みユーザーを同一視すること。
• 正規化前に正規表現でパスをチェックすること。
• リクエストが Webhook エンドポイントに到達したという理由だけで、Webhook のフィールドを信頼すること。
• 攻撃者の経路を示さず、理論上の API の危険性を報告すること。
• 認証をデバッグするために、生のトークンをログに記録すること。
• 許可なく本番環境で悪用可能性をテストすること。
• テストに合格させるために、検証を無効化したり権限を広げたりしてセキュリティを修正すること。

セキュリティ調査結果パケット

Security property:
Asset/boundary:
Attacker prerequisites:
Source → transformations → control → sink:
Concrete failure scenario:
Existing mitigations:
Severity + rationale:
Evidence/location:
Bounded remediation property:
Security re-test:
Functional verification still required:

完了基準

セキュリティ作業は、以下を満たした時点で完了です。

• 関連する信頼境界と攻撃者が制御できる経路を追跡した。
• 候補となる調査結果を、パターンに当てはめるのではなく検証・調整した。
• 分析中にシークレットを漏えいさせなかった。
• ブロッキングとなる調査結果に、範囲が明確な修正・検証基準がある。
• 判定に、確認したセキュリティ特性と未確認の事項が正確に記載されている。

段階的なリソース

• 詳細ガイド：references/trust-boundary-and-finding-validation.md
• 既存の脅威マトリックス：references/threat-modeling-matrix.md
• シークレットの衛生管理：references/secret-sanitization.md
• 例：examples/security-audit-walkthrough.md