security-audit

セキュリティ監査

実際の信頼境界に違反する脆弱性を見つけ、担当者にソースコード上の証拠、安全な再現方法、優先度、最小限で効果的な修正を提示します。これは、防御を目的としたソースコード優先のワークフローです。影響を受ける具体的な主体、リソース、またはセキュリティ上の結果を示せない候補は、確認済みの指摘ではありません。

実行モード

このスキルは、デフォルトではガイダンスです。読み込んだだけでは、監査ワークフロー全体の実行やファイルの作成は許可されません。

• ガイダンスモード：セキュリティに関する質問、対象を絞ったレビュー、方法論、トリアージ、または特定の指摘の調査では、このスキルの関連部分のみを使用します。6つのフェーズすべてを自動的に実行したり、出力ディレクトリを作成したり、監査成果物を書き出したりしないでください。必要に応じて、対象を絞ったエージェントを起動できます。結果は現在のタスクに返されます。
• フル監査モード：ユーザーがコードベースの監査またはペネトレーションテストを明示的に依頼した場合、包括的なセキュリティレビューやエンドツーエンドのセキュリティレビューを依頼した場合、またはレポート成果物を求めた場合は、ワークフロー全体を使用します。6つのフェーズすべてを実行し、以下に定義されたファイルを書き出してください。

依頼がどちらのモードとも解釈できる場合は、ファイルを作成したりワークフロー全体を開始したりする前に、要点を絞った質問を1つしてください。

プラットフォーム用語

このスキルは、特定のエージェントに依存しません。

• 親エージェントは実行を調整し、共有状態を管理するエージェントです。
• タスクツールは、プラットフォームの委任またはサブエージェントの仕組みです。
• research エージェントは、対象を絞ったソースコードの調査と事実確認を行う委任先のエージェントです。
• general エージェントは、広範な調査と、範囲を限定したローカル実行を行う委任先のエージェントです。
• 見出しの subagent_type: は、これら2つの委任先エージェントのうち、どちらの役割がその作業を実行するかを示します。

役割、書き込みの分離、プロンプト、独立性の境界を維持したうえで、同等のプラットフォーム機能を使用してください。

実行時の基本的な安全対策

以下の規則は、どちらの実行モードにも適用されます。ソースコードの調査は読み取り専用です。対象の制御下でビルド、テスト、プロセス、ブラウザー、エミュレーター、ファザー、フィクスチャ処理を実行する場合は、以下のすべての制御を備えた、OSによって強制されるサンドボックス内でのみ行ってください。

• 外部ネットワークに接続できないこと。確認にローカルのクライアント／サーバー通信が必要な場合は、分離されたループバック名前空間のみを使用すること。
• 明示的な許可リストから安全な値を設定した、空の環境であること。スクラッチ領域内に専用の HOME、一時ディレクトリ、キャッシュを用意すること。
• 対象とツールチェーンが読み取り専用であり、対象の制御下で実行されるプロセスは、割り当てられた scratch/ ディレクトリ内にのみ書き込み可能であること。
• CPU、メモリ、プロセス数、ファイルサイズ、ディスク容量、実行時間に明示的な上限を設けること。

ビルドでソースコードの隣に書き込みが必要な場合、対象の制御下にあるプロセスの外部で、エージェントは割り当てられた scratch/ ディレクトリに一時的なソースコピーを作成できます。ガイダンスモードでは、対象の制御下で生成されたファイルを保持しないでください。フル監査モードでは、信頼できる親エージェント側のコードのみが、「書き込みの分離」に記載された手順に従って、秘密情報を含まない最小限の結果を保持用の artifacts/ に移せます。エージェントに割り当てられた scratch/ 以外の保持用出力ディレクトリ、他のエージェントのディレクトリ、ホストのホームディレクトリ、認証情報、ソケット、共有サービスを、対象コードに決して公開しないでください。依存関係をインストールしたり、ビルドに依存関係を取得させたりしないでください。すでにローカルで利用可能なツールと依存関係のみを使用してください。すべての制御を適用できない場合は、対象コードを実行しないでください。サンドボックス機能の不足を検証が必要な阻害要因として報告し、安全な検証計画を提示してください。

ダミーの主体、フィクスチャ、秘密情報を使用してください。デプロイ済みエンドポイント、外部サービス、共有インフラストラクチャ、本番環境のID、他のユーザーのデータ、稼働中のコントロールプレーンを調査しないでください。稼働中または共有のプロセスに対して可用性をテストしたり、成果物を公開したり、リリースを変更したり、有料APIの利用枠を消費したり、欠陥を立証するのに必要な最小限のローカルでの影響を超えて続行したりしないでください。決定的な事実がソースコードまたはサンドボックス内のフィクスチャから確認できない場合は、検証が必要であると報告してください。

完全監査のセットアップ

完全監査モードでは、偵察を開始する前に次の値を解決します。

• スキルディレクトリ：この SKILL.md を含む絶対パスのディレクトリです。
• 対象：レビュー対象の絶対パスのリポジトリルートです。
• リポジトリ名：ディレクトリまたはローカルの Git リモートから取得した、安定したリポジトリ識別子です。
• 出力ディレクトリ：対象の外部にある新しい書き込み可能なディレクトリです。既定値は ~/security-audit-skill/<repo-name>/run-<N> で、<N> には次に未使用の整数を指定します。ユーザーが明示的に選択し、親がそのバージョン管理システムでディレクトリ全体が無視されることを確認した場合に限り、対象内のディレクトリを使用します。それ以外の場合は停止し、外部のパスを指定するよう求めます。
• ソース参照：レビュー対象のコミットと、ワークツリーに変更があるかどうかです。未レビューの生成ファイルや変更済みファイルを、別のリビジョンとして扱わないでください。

書き込みの分離

親が共有実行ファイルを作成し、それらへの唯一の書き込み元となります。

• run-metadata.json
• architecture.md
• coverage-ledger.json
• findings.json
• REPORT.md
• FINDINGS-DETAIL.md
• NEEDS-VALIDATION.md

各ハンターまたは検証担当者には、<output-dir>/agents/<agent-id>/ の下に一意のルートと、それぞれ独立した scratch/ および artifacts/ ディレクトリを割り当てます。正規のエージェント ID は ^[a-z0-9][a-z0-9_-]{0,63}$ に一致し、con、prn、aux、nul、com1 から com9、または lpt1 から lpt9 のような Windows のデバイス名であってはなりません。小文字の ID を使って、大文字小文字の違いによる衝突を防ぎます。エージェントと、対象によって制御されるすべてのプロセスが書き込めるのは scratch/ のみです。保持される artifacts/ は親が所有し、サンドボックスには決して公開せず、信頼された親側の昇格コードのみが書き込み可能です。エージェントは共有ファイル、対象のソース、保持されるアーティファクト、または他のエージェントのディレクトリを変更してはなりません。書き込み可能な代替場所として /tmp やホストのホームディレクトリを使用しないでください。

実行前に、親はエージェントの scratch/ および artifacts/ ルートへの、信頼された継承不可のディレクトリ記述子を開いて保持し、許可するスクラッチ相対パスのアーティファクトファイルと、ファイルごとおよび累積の明示的なバイト上限の許可リストを記録します。これらの記述子をエージェントやサンドボックスに渡してはなりません。サンドボックスとそのすべてのプロセスが終了した後、信頼された親側のコードが、許可リストにある各ファイルを個別に昇格します。

1. 宣言された相対パスを検証します。絶対パス、空のパス、.、..、またはシンボリックリンクを含む構成要素は拒否します。
2. 保持された scratch/ ルートの記述子から、すべての親構成要素をリンクをたどらないディレクトリ相対操作でたどります。パスを使って再度開いてはなりません。
3. リーフをリンク追跡なし、かつノンブロッキングで開きます。
4. fstat で、通常ファイルであり、リンク数がちょうど 1 で、記録されたファイルごとおよび累積のバイト上限内であることを確認します。
5. 記述子からの読み取り中も、これらの上限を適用します。
6. 検証済みのサイズ分だけ正確にコピーし、再度 fstat を実行して、識別情報、ファイル種別、リンク数、またはサイズが変更されていないことを確認します。
7. 出力先では、保持された artifacts/ ルートの記述子から、すべての親構成要素をリンクをたどらないディレクトリ相対操作でたどります。既存の各構成要素が実際のディレクトリであることを確認し、存在しないディレクトリは排他的に作成してから、リンク追跡なしで再度開いて検証します。
8. リーフをリンクをたどらず、排他的に作成し、開いた出力先が通常ファイルでリンク数がちょうど 1 であることを確認します。パスを開き直さず、検証済みのソース記述子からコピーします。
9. POSIX 以外のシステムでも、同等の競合状態に安全な API を使用します。
10. scratch を再帰的にコピーしたり、グロブを使用したり、アーカイブを artifacts に展開したりしてはなりません。また、シンボリックリンク、FIFO、ソケット、デバイス、ディレクトリ、ハードリンクされたファイル、変更中のファイル、または上限を超えるファイルを開いたり昇格したりしてはなりません。
11. いずれかのチェックが利用できない、適用できない、または失敗した場合は、該当するスクラッチエントリを破棄します。それが決定的な証拠である場合は、正確な昇格ブロッカーを記載した needs_validation を保持します。 HUNTING.md と VALIDATION-AND-REPORTING.md には、ハンターと検証担当者のプロンプト向けに、この手順が同一のフェンス付きブロックとして記載されています。このリストと同じルールが、同じ順序で示されています。

再現したチェックについては、コマンド、正確なテスト入力、サンドボックスの制限、および再現に必要な許可リスト内の環境変数名と安全な非シークレット値のみを記録します。実行環境の環境変数、継承された変数、認証情報の値、認証状態、無関係なホストパスを取得またはコピーしてはいけません。実行後に環境変数を秘匿化するのではなく、空の環境から起動してください。

委任する前に、親は少なくとも run_id、repo、target、source_ref、profile、scope_paths、budget（未設定の場合は null）、execution_policy: "sandboxed-source-and-local-only"、選択した関連ファイル、前回実行のパス、共有ファイルの所有者、および run_status: "in_progress" を含む run-metadata.json を作成します。メタデータは、これらの事実が変わった場合にのみ更新します。候補の状態はカバレッジ台帳と findings.json に記録します。

全面監査の計画

このセクションのカバレッジ、前回実行、プロファイル、予算に関する要件は、全面監査モードにのみ適用されます。

カバレッジと前回実行

1 回の調査で完了することはありません。調査を始める前に決定的なカバレッジ計画を作成し、エージェントから結果を受け取るたびに更新してください。RECONNAISSANCE.md では安定したカバレッジ単位を定義し、HUNTING.md ではカバレッジ批評のラウンドを定義しています。台帳を更新するのは親だけです。

前回実行の記録がある場合は、現在の実行を計画する前に、互換性のある coverage-ledger.json と findings.json をすべて読んでください。

1. 関連する現在のソースを、前回の各記録および単位と比較します。前回のソース参照だけでは、パスが変更されていない証拠になりません。
2. 前回の confirmed 記録を現在の候補セットに引き継げるのは、関連するソースと条件に変更がなく、証拠が現在の要件を引き続き満たす場合に限ります。その記録を、planned として初期設定した現在の台帳単位にリンクし、フィンガープリントを保持します。その原因に限ってハンターの除外対象とし、引き継いだ記録は現在の最終検証プロセスに送ります。Phase 3 で再確認する検証担当者がその単位の割り当て所有者となり、状態を candidate に変更します。
3. 前回の confirmed 記録に関係するソースが変更されている場合は、現在の計画済み再検証単位を作成します。その記録をハンターの除外リストに含めてはいけません。現在の独立した検証によって現在のパスと結果が確認された場合にのみ、引き続き confirmed とします。
4. 前回の needs_validation、deferred、blocked、out_of_scope の状態、およびソースが変更された単位は、現在の作業とします。依然として外部要因が未解決の needs_validation 記録を引き継げるのは、現在のソーストレースを確認し、現在の planned 単位にフィンガープリントでリンクした後に限ります。その単位の所有者と証拠は、検証担当者による再確認で確定します。記録には未解決のブロッカーを残します。これらの前回の状態が、現在の単位を抑制することはありません。
5. 同一ソースに対する前回のカバー済み単位は、優先順位の判断材料にはできますが、現在の台帳に引き続き表示します。前回の rejected 記録が抑制するのは、変更されていない不成立の主張だけであり、その単位のカバレッジではありません。証拠が変更された場合は、現在の作業とします。
6. 前回のプロファイルとスコープを確認します。前回の quick またはスコープ指定の台帳から引き継げるのは、記録された証拠とギャップのみです。その他は問題ないと暗に示してはいけません。

前回の台帳が存在しない場合は、最終カバレッジ報告にその旨を記載してください。1 回の実行で対象全体を網羅したかのように示してはいけません。

実行プロファイルとスコープ

完全な監査を設定する際は、ユーザーの依頼からプロファイルを選ぶか、対象の規模と重要度に応じて提案してください。run-metadata.json（profile、scope_paths）に記録し、レポートにも明記します。デフォルトは standard です。

• quick — 小規模な対象、再実行、または初回の迅速な確認向けの範囲限定パスです。台帳の単位はサーフェス × 境界 × 攻撃クラスにまとめます（サブシステムには固定の正規識別子 profile/quick/all-in-scope-subsystems を使用します）。ハンターの波をちょうど1回実行した後、最終カバレッジ批評をちょうど1回実施します。候補の検証と最終記録の検証には、候補ごとに新しい検証担当エージェントを1つ使用します。追加のハンターの波は開始せず、批評担当が受け入れた発見事項と再割り当ては deferred として記録します。
• standard — 記載されているワークフローです。
• deep — 重要度が高い対象や大規模な対象向けです。台帳の単位をサブシステムごと、ライフサイクルモードごとに分割し、クリーンなパスになるまで批評の波を実行します。候補の検証と最終記録の検証は、それぞれ別の新しいエージェントに担当させます。また、prior_covered_same_source の単位には、独立した2回目のパスを実施します。

スコープ限定の実行とは、名前を指定したパス、1つのサブシステム、1つの関連ドメイン、または2つのソース参照間の差分など、一部分を監査する実行です。対象内のサーフェスだけを対象に台帳の単位を登録し、それ以外は covered ではなく out_of_scope として記録します。スコープ限定の実行または quick の実行では、カバレッジが部分的であることを明示してください。

プロファイルで変えるのは範囲の広さと冗長性であり、証拠の基準ではありません。候補ゲート、ソースとローカル実行の境界、needs_validation の規律、スキーマ検証、confirmed レコードの独立検証を省略しないでください。

コスト予算

台帳を使うと、支出を数えられるようになります。1ユニットはおおよそハンターへの1回の割り当てに相当し、生き残った候補1件はプロファイルに応じて1回または2回の検証担当への割り当てに相当します。ユーザーが予算を設定した場合、または親エージェントが大規模な対象に予算を提案した場合は、すべてのフェーズを通じたエージェント呼び出しの最大数として、run-metadata.json に budget を記録します。

偵察エージェントを起動する前に、厳格な予算チェックを実施します。偵察の基本となる4回の呼び出し、quick の場合は最後の波の後に実行する批評担当1回、standard／deep の場合は最後の波の後に実行する批評担当1回と、これとは別の最終クリーン批評担当1回、さらに検証担当の呼び出しを最低1回分確保します。追加の偵察は、呼び出しを追加するたびにこのチェックを繰り返してから実施します。要求された予算で最低限の呼び出し数を賄えない場合は、エージェントを起動せず、より大きな予算、より狭いスコープ、または別のプロファイルを求めます。要求が変更されない場合は、run_status: "incomplete" と incomplete_reason: "budget_cannot_fund_reconnaissance_and_reserves" を設定し、監査パスを実行していないことを報告します。

以下の順序で予算を使います。

1. 偵察、すべての最後の波の後に実行する批評担当、および別途実施する最終クリーン批評担当を、それぞれエージェント呼び出しとして数えます。
2. ハンティングの前に、批評担当と検証の予算を確保します。 quick では、最後の波の後に実行する批評担当1回分を確保します。standard または deep では、ハンターの各ウェーブの前に、直後に実行する批評担当1回分と、これとは別の最終クリーン批評担当1回分を確保します。また、プロファイルに応じた検証コストを確保します（候補1件あたりおよそ1～2エージェント。不明な場合は、批評担当の予約分を差し引いた残りの30%を確保します）。確保分をハンターに割り当ててはいけません。
3. ハンティングの割り当て上限を使い切るまで、優先順位に従ってハンターをユニットに割り当てます。そのウェーブの直後に、確保していた批評担当を実行します。最終クリーン批評担当と検証の確保分は維持します。
4. 後続のウェーブの前に、新たに実施する批評担当の分を再度確保します。残りの予算で必要な批評担当の呼び出しと検証の確保分を賄えない場合は、そのウェーブのハンターを起動せず、予定していたユニットを理由 budget_cannot_reserve_critics_and_validation とともに deferred に設定し、確保済みの最終クリーン批評担当を使って生じたギャップを記録します。

ウェーブ1の前に、事前の偵察見積もりを更新し、シード済みユニット、そこから見込まれるハンター数、必須の批評担当呼び出し数、検証の確保分、残りの予算で計画を実行できるかどうかを含めます。明らかに予算が足りない場合は、その旨を伝え、証拠を黙って削るのではなく、より狭いスコープまたはより粗いプロファイルを提案します。後から判明した事実によって必須の最終批評担当の確保分を使い切った場合は、ハンターを起動せず、予定していた作業をすべて deferred に設定し、理由を critic_budget_exhausted として実行を未完了に設定します。また、網羅性を主張してはいけません。

厳格なエージェント総数予算であっても、候補数が予想外に多い場合や、別の独立した検証担当が必要となる重大なフェーズ5の差し替えが発生した場合には、超過することがあります。残りの予算で候補すべてを検証できない場合は、ハンティングを中止し、予算が許す範囲でフィンガープリント順に候補を検証して、run_status: "incomplete" と incomplete_reason: "validation_budget_exhausted" を設定します。未検証の各フィンガープリントは、未解決の理由とともに candidate 台帳ユニットに関連付けたままにします。未検証の候補を findings.json に含めたり、needs_validation として再ラベル付けしたり、実行を完了として報告したりしてはいけません。フェーズ6で部分レポートを作成できるのは、その第1セクションに候補の検証が未完了であることを明記し、影響を受けるフィンガープリントとユニットを列挙する場合に限ります。ユーザーが設定した厳格な予算を、黙って超過してはいけません。

基本原則

境界と結果を必ず特定する

各候補について、信頼度の低い主体、受け入れられた入力またはアクション、意図された制御、越えられた境界、影響を受ける主体またはリソース、そして具体的に観測された結果または所有者が観測できる結果を明示します。ベストプラクティスの欠如、推測したデプロイ時の挙動、一般的なパーサークラッシュ、または自己への影響を、セキュリティ上の問題として扱ってはいけません。

範囲を限定したローカルの証拠を使う

静的解析でソースの経路を特定します。実行制御がすべて利用できる場合は、サンドボックス化されたローカルテストで挙動を確認します。最小限の関数ハーネス、既存の単体テスト、小規模なパーサー用フィクスチャ、ダミーテナントの統合テスト、ローカルでレンダリングされた設定、または範囲を限定して隔離したループバッククライアントなどを利用できます。誤った戻り値、不正にアクセスされたダミーレコード、サニタイザーの検出結果、ポリシーの差異、その他の最小限の影響が確認された時点で停止します。最小限の境界テスト結果を超えてローカルチェックを拡張したり、永続化、障害発生後、または隠蔽に関する資料を作成したりしないでください。

ソースの可視性を尊重する

デプロイメント制御、プロキシの挙動、プロバイダーの設定、ブラウザーのヘッダー、ID ポリシー、ブローカーの ACL、パッケージング、トポロジーは、いずれも実際の制御です。これらが必要で、リポジトリに存在しない場合は、存在するとも存在しないとも決めつけないでください。不足している事実を正確に示したうえで、安全なオーナー確認済みの計画またはローカルでの計画を添えて、needs_validation を使用します。

優先度と確実性を分ける

severity が付与されるのは confirmed の記録のみです。可能性と影響は、実証された条件と結果を反映する必要があります。全体的な severity は、実証された影響を超えてはなりません。needs_validation は、特定のソースに基づく境界に関する仮説が検証できない状態を意味します。確信度の低い確定済み脆弱性ではなく、severity もありません。

次の基準を使って、全体的な severity を調整します。

• critical — 認証されていない攻撃者が、コード実行、データストア全体へのアクセス、または任意のアカウントの乗っ取りを実現する。
• high — 攻撃者が、実際の影響を伴う明示的なセキュリティ制御を完全に突破する。例：認証の回避、テナント間の読み取りまたは書き込み、他のユーザーに影響する保存型スクリプトの実行、認証済みコード実行、または共有サービスの認証不要なリモート停止。
• medium — 影響範囲が限定されている、まれな前提条件が必要である、または限られたリソース群に影響がとどまる、実際の境界違反。
• low — 秘密ではない内部情報の開示、またはわずかな利益のために継続的な労力を要する影響。
• informational — 確認済みではあるものの影響が最小限の観察事項。主に、より大きな検出事項の前提条件として役立つもの。

high と medium の判別基準：実証された結果は、実際の影響を伴う操作について明示的な制御を完全に突破していますか。それとも、制御を弱めているだけですか。具体的な被害を説明できない場合、severity は感じているより低くなります。

効果を得られる最小限のソース修正を推奨する

confirmed の検出事項ごとに、コードが保証すべき不変条件と、最後の信頼できる判断点でその不変条件を保証する最小限のソース変更を特定します。一般的な強化策のアドバイスより、リポジトリ内の具体的な変更箇所と回帰テストを優先します。監査では修正を説明しますが、対象ソースは変更しません。

完全監査ワークフロー

完全監査モードでは、次の6つのフェーズを順番に実行します。

1. 偵察 — RECONNAISSANCE.md を使用して、ソース、信頼境界、ローカルビルドの経路、併用する資料の選定、過去の証拠、初期の決定論的なカバレッジ台帳を把握します。
2. カバレッジに基づく探索ウェーブ — 台帳に基づいて独立したハンターを割り当て、HUNTING.md、ATTACK-CLASSES.md、選定したドメイン別資料を使用して、構造化された候補結果を収集します。
3. 候補の検証 — VALIDATION-AND-REPORTING.md の定義に従い、フィンガープリントを統合し、各候補を新たなソース検証担当者に割り当てます。
4. 構造化出力 — 最終的な confirmed、needs_validation、rejected の各レコードをすべて findings.json に書き込み、report-schema.json と validate-findings.cjs で検証します。また、validate-coverage-ledger.cjs でカバレッジの主張を検証します。
5. 独立したレコード検証 — 新たなエージェントを使って最終的なソースに関する主張を検証し、修正や状態の変更を調整します。
6. 対象に依存しないレポート — 最終レコードから REPORT.md、FINDINGS-DETAIL.md、NEEDS-VALIDATION.md を作成します。実環境でのプローブ手順は含めません。

次のいずれかちょうど2つの最終状態に到達するまで、実行を終了しないでください。（a）フェーズ6の成果物をすべて作成し、両方のバリデーターが合格する、または（b）run_status: "incomplete" を正確な理由とともに記録し、その不足をレポートで明らかにする。フェーズの途中で停止しないでください。

アンチパターン

1. チェックリストからの逸脱を脆弱性として提示する。
2. 到達可能な境界違反を伴わない多層防御の助言。
3. 範囲を限定したローカルの証拠では不十分な場合に、実環境または共有環境でテストする。
4. ソースに記載のないプロバイダー、プロキシ、ブラウザー、ID、デプロイの挙動を推測する。
5. 想定された同一プリンシパルの権限や自己への影響を、境界を越える結果として扱う。
6. 観測された影響を超えるパーサーまたはランタイムの影響を報告する。
7. 重複排除や検証ができない、文章のみのハンター結果を出力する。
8. 同一ソースの過去の確認済みレコードを再報告したり、探索の方向性を固定する例として使用したりする。
9. needs_validation レコードに重大度を割り当てる。
10. 独立した検証の前にレポートを作成したり、文章と JSON の内容を食い違わせたりする。