コードを変更する前のセキュリティ検出結果のトリアージ

検出結果は、特定の入力と設定についての指摘です。修正を決める前に、リポジトリ、ブランチやコミット、解析設定、対象外のコードを記録してください。古いリビジョンの結果は既に変更された問題を示すことがあります。部分的な解析では、関連する防御や依存関係が含まれない場合もあります。

概要だけでなく、指摘箇所と周辺の文脈を読みます。ツールが観測したことと、推測したことを分けて確認してください。判断する根拠が足りない場合は、不足を記録して必要な文脈を集めます。作業一覧を片付けるためだけに、不確かな結果をインシデントや誤検知と断定しないでください。

静的解析は、実行時のすべての動作を知らなくても、疑わしいパターンを示せます。周辺のロジックとアプリケーションの要件をレビューしてください。問題の成立は、権限、データの所有者、設定、解析で十分に解決できなかった呼び出し経路に依存することがあります。これらは許可されたコード・設定レビューで確認する事項です。

• 根拠：どのコードや設定が指摘を支えていますか。
• 適用範囲：公開するリビジョンに、該当する動作が存在しますか。
• 到達性：想定する権限で、関連するアプリケーションの処理へ到達できますか。
• 影響：どの利用者、資産、信頼境界が影響を受けますか。
• 既存の制御：防御があると仮定するだけでなく、実際の経路で一貫して適用されていますか。
• 不明点：何が分からず、誰が回答し、いつ確認しますか。

公開Hi AUDIT WebMCPデモには、「Invoice lookup misses tenant boundary」というサンプル検出結果HA-103があります。認証済みテナントの所有権ルールを、レコード操作が守る必要があるという認可レビューの例です。説明用のサンプルデータであり、顧客のリポジトリの解析結果や、実際のインシデントの証拠ではありません。

レビューでは、テナント識別情報の取得元、所有権を確認する箇所、関連するすべてのレコード操作が同じ方針を守るかを調べます。その境界を担当するチームに変更を割り当ててください。修正では信頼できるテナント情報を使って認可を適用し、チームのテスト環境で拒否すべき操作の認可テストを含めます。ツールが示した一行だけでなく、周辺の操作も確認します。

重大度と作業の優先順位は分けて扱います。重大度は想定される結果の深刻さをまとめますが、優先順位には露出、影響する資産、代替の防御、対応を遅らせるコストも関係します。すべての課題に一般的な期限を当てはめず、チームの対応方針を使ってください。

修正案が意図した要件を守り、正当な利用を壊さないことを確認します。変更をレビューし、関連するテストを実行し、必要に応じて再解析してください。警告が消えただけでは、セキュリティ境界が正しいことの証明にはなりません。後のレビューで、修正した問題と抑制したルールを区別できるように、判断と根拠を残します。