security-audit-methodology

セキュリティ監査の方法論

認可と安全上の境界

評価を始める前に、対象、範囲、許可された手法、データの取り扱い規則、エスカレーション先を確認してください。明示的な許可なしに、システムを調査したり、アカウントにアクセスしたり、発見事項を悪用したり、本番環境の状態を変更したりしないでください。発見事項は、責任者が確認できる証拠として記録してください。このスキルは、コンプライアンスを認定するものでも、資格を持つセキュリティレビューの代わりになるものでもありません。

セキュリティはチェックリストではなく、姿勢です。この方法論では、コード、アーキテクチャ、依存関係、運用方法を体系的に評価し、セキュリティ上の弱点を特定します。

セキュリティエンジニアの担当領域

担当すること	担当しないこと
脅威モデリング — STRIDE、攻撃ツリー、信頼境界	一般的なコードレビュー — これは qa-methodology の担当です
脆弱性評価 — 分類、深刻度、再現	パフォーマンス分析 — これは systematic-debugging の担当です
セキュリティアーキテクチャレビュー — 認証、認可、データフロー、シークレット管理	運用の信頼性 — これは SRE の担当です
依存関係分析 — サプライチェーン、既知の脆弱性、ライセンスリスク	コンプライアンス認定 — これは法務の担当です
セキュリティテストのガイダンス — ファジング、SAST/DAST の統合	インシデント対応の実行 — これは SRE／オンコールの担当です

参考ファイル

参考資料	読み込むタイミング
references/threat-modeling.md	システムの攻撃対象領域を評価するとき — コンポーネントごとの STRIDE、信頼境界、データフロー分析
references/vulnerability-classification.md	発見事項を評価するとき — CVSS スコアリング、CWE マッピング、深刻度のトリアージ、悪用可能性の評価
references/security-architecture-dependency-audit.md	認証（OAuth 2.0、OIDC、SAML、mTLS）、認可（RBAC/ABAC/ReBAC）、セッション管理、シークレット管理、依存関係／サプライチェーンのセキュリティ（SBOM、CVE 照合、ライセンス分析、SLSA フレームワーク）をレビューするとき

基本原則

何も信頼せず、すべてを検証する — すべての入力、すべての境界、すべての前提が攻撃対象領域になり得ます。デフォルトで拒否し、明示的に許可してください。

多層防御 — 単一の制御では不十分です。レート制限のない認証、鍵管理のない暗号化、出力エンコーディングのない入力検証は、いずれも脆弱性が連鎖するのを待っている状態です。

最小権限 — すべてのコンポーネント、すべてのユーザー、すべてのプロセスには、必要な権限だけを付与し、それ以上は与えないでください。過剰な権限は、最もよくあるセキュリティ上の負債です。

攻撃者の視点を理解する — 問うべきなのは「これを悪用できるか？」ではありません。「攻撃者ならこのシステムをどう考えるか？」です。攻撃者の動機、制約、能力をモデル化してください。

個別の事例ではなく、脆弱性の種類を修正する — SQL インジェクションが一度見つかったなら、そのエンドポイントだけでなく、あらゆる箇所でパラメーター化クエリを使う必要があります。XSS が1件見つかったなら、レンダリングパイプライン全体をレビューしてください。

移植性

このスキルは、特定のホストに依存しないよう意図的に設計されています。ここに記載された参考資料、テンプレート、スクリプトの読み込みには、エージェントの通常の仕組みを使用してください。特定のプロファイルシステム、タスクオーケストレーター、メモリーサービス、応答引き継ぎ形式を前提としないでください。