security-risk-audit

サービス特性セキュリティ監査仕様 v1.1 に基づく監査手順。 同じディレクトリの classification.yaml（特性カタログ・チェック項目・重大度基準）と report-template.md（報告フォーマット）を正本として使う。

行動規約（最優先）

1. 読み取り専用。コード・設定を変更しない。本番環境へ書き込まない。破壊的コマンドを実行しない。クラウド CLI が使える場合も describe / list / get 系に限る。
2. 証拠主義。指摘ごとにファイルパス・行・設定キーを示す。推定は「推定」と明記する。
3. 秘密情報を出力しない。発見したシークレットは種類と場所のみ報告する。値・部分値・ハッシュを出力しない。
4. 外部へ送らない。コードや設定を外部サービスへ送信しない。レポートはリポジトリ内に保存する。
5. 捏造しない。確認できないことは「確認不能」とする。チェック項目を省略しない。
6. 重大度順に報告する。該当しない特性のチェックは実施しない。一般論で埋めない。

手順

Step 0. 準備

• classification.yaml を読む。
• 対象リポジトリのルートで、コミットハッシュとブランチを記録する（git rev-parse HEAD, git branch --show-current）。
• 調査範囲を決める: コードベース、IaC（terraform / CDK / CloudFormation / Pulumi / Kubernetes マニフェスト）、CI 定義、Dockerfile、ドキュメント。クラウド CLI へのアクセスが与えられている場合は読み取り系コマンドのみ追加する。

Step 1. サービス特性の宣言を読む

• .security/service-profile.yaml を探す。見つかれば characteristics を読む。
• 見つからない場合は、Step 2 の検出結果だけで判定し、「宣言なし。推定による判定」とレポートに書く。
• 各特性が true / false / unknown のどれかを控える。
• components があれば、各コンポーネントの実行基盤・ネットワーク・権限の宣言を控える（Step 5 の脆弱性評価で使う）。

Step 2. 検出シグナルで特性を検出する

classification.yaml の各特性の signals.code と signals.infra を手がかりに、リポジトリを探索する。 代表的な探索対象:

• スキーマ・マイグレーション（テーブル名・カラム名）
• 依存関係ファイル（package.json, Gemfile, go.mod, requirements.txt, pubspec.yaml 等）のライブラリ名
• ルーティング・コントローラ・API 定義
• IaC（リソース種別、暗号化、公開設定、冗長構成）
• CI 定義（.github/workflows, .gitlab-ci.yml 等）
• README・設計ドキュメント

特性ごとに「該当 / 非該当 / 疑い」を判定し、根拠のパスを記録する。 宣言（Step 1）と食い違う場合は差分として報告する。宣言が unknown の特性は検出結果で補う。

Step 3. 優先順位を合成する

該当する特性（宣言 true、または検出で該当・疑い）について、classification.yaml の priority を軸ごとに重ね合わせ、最も小さい順位（= 最優先）を採用する。

• FOUNDATION が該当する場合、順位 2 の軸も順位 1 として扱う。
• SAFETY が該当する場合、安全性を最上位に置く。
• 複数特性が該当するのが普通である。合成結果を表にする。

Step 4. チェックを実施する

実施順:

1. 横断チェック cross_checks（X-01 〜 X-08）。特性に関係なく全件。
2. 該当する特性の checks。該当しない特性は実施しない（レポートでは「対象外」と記す）。

各チェックについて look_at に書かれた確認箇所を調べ、結果を次のいずれかで記録する:

• OK: 問題なし。根拠を 1 行で残す。
• 要対応: 指摘として Step 5 で重大度を付ける。
• 確認不能: リポジトリ内の情報では判断できない。人間への質問にする。
• 対象外: 該当しない特性のチェック。

同じ原因が複数チェックにまたがる場合は、指摘を 1 件にまとめ、関連チェック ID を列挙する。

Step 5. 重大度を決める

classification.yaml の severity に従う。

• 到達性を判定する: 外部（未認証 / インターネット到達可能 / 公開設定）、内部（認証後 / 社内 NW / 権限者）、潜在（到達経路未確認）。
• 影響する軸の合成順位（Step 3）と到達性の組み合わせで Critical / High / Medium / Low を決める。
• overrides を適用する（認証情報の露出は常に Critical、など）。
• 確認不能は Info とし、質問として報告する。

ミドルウェア・ライブラリの脆弱性

X-06・PUB-06 で既知脆弱性を見つけたら、CVE 番号と CVSS の値だけで重大度を付けない。同じ脆弱性でも、EC2 上のプロセスか Fargate のタスクか、インターネットから届くか private ネットワーク内だけか、どの権限で動いているかで、起こりうる被害が変わる。classification.yaml の component_vulnerability に従って次の順に調べる。

1. 因子を記録する。脆弱性の種類と攻撃の前提（V-KIND）、実行基盤（V-RUNTIME）、ネットワーク上の位置（V-NETWORK）、実行権限（V-PRIVILEGE）、侵害されたときに届く資産（V-ASSETS）。それぞれ根拠のパスを残す。
2. blast_radius で、その実行基盤では侵害がどこまで広がるかを確かめる。
3. derivation で到達性と軸を決め、severity.matrix に入れ、escalation を適用する。private ネットワーク内のコンポーネントでも、公開アプリが攻撃者の入力をそのまま渡すなら到達性は外部とする。脆弱な機能を使っていないと設定で確認できた場合は、根拠を書いて Low とする。
4. 「想定される被害」を、侵入口 → 得られる権限 → 届く資産 → 影響の流れで 1〜3 文で書く。

実行基盤・ネットワーク・権限が IaC にない（別リポジトリ、手動構築など）場合は、推定で埋めない。脆弱なバージョンの存在を確認できていれば Info にはせず、確認できた因子だけで重大度を導き、読み取れない因子は質問にする。service-profile.yaml の components に宣言があれば使い、IaC と食い違えば差分として報告する。

Step 6. レポートを書く

report-template.md の構成に従い、Markdown で出力する。

• 保存先: docs/security/risk-report-YYYY-MM-DD.md（ディレクトリがなければ作成の可否を人間に確認する。作成できない場合は会話に出力する）。
• 指摘は重大度順。各指摘に ID（F-01, F-02 …）、チェック ID、軸、到達性、場所、内容、推奨対応、根拠を付ける。
• ミドルウェア・ライブラリの脆弱性の指摘には、セクション 3.1 の詳細（因子と想定される被害）を付ける。
• チェック結果の一覧（セクション 4）は全件列挙する。
• 確認不能の項目は質問（Q-01 …）としてまとめる。
• 最後に調査範囲と制約を書く。この報告は静的調査であり、ペネトレーションテストや運用実態の確認を代替しない。

Step 6.5. レポートを共有するとき

レポートは未修正の脆弱性の場所と到達経路を示す。コミット・push・PR 作成・外部ツールへの貼り付けを頼まれたら、その前に共有先の公開範囲を確かめる。

1. 共有先の公開範囲を調べる。git リモートなら git remote -v で共有先を特定し、gh repo view <owner/repo> --json visibility などで visibility を確認する。
2. 結果に応じて進める:
   • private / internal と確認できた: 作業ブランチにコミットしてよい。push と PR 作成は通常の手順どおり人間の確認を取る。
   • public、または確認できなかった: コミットも push もしない。レポートは未追跡のまま残し、公開範囲が判明していないことを伝え、非公開の共有先（private リポジトリ、非公開の Security Advisory、社内の限定共有など）を人間に選んでもらう。
3. 「急ぎ」「チームに共有」という依頼は、公開範囲の確認を省く理由にならない。公開リポジトリへ出すのは、人間が公開範囲を理解したうえで明示的に指示した場合に限る。

Step 7. 人間への引き継ぎ

会話では次の 4 点だけを短く伝える:

1. 合成した優先順位（どの軸が最優先か）
2. Critical / High の件数と、最も重い指摘 1〜3 件（脆弱性の指摘なら想定される被害も 1 文で）
3. 宣言と検出の差分（あれば）
4. 人間に確認が必要な質問の数と、レポートの保存先

補足

• 仕様のバージョン: レポートには classification.yaml の spec_version を記載する。対象リポジトリの service-profile.yaml の spec_version と食い違う場合は、その旨を書く。
• service-profile.yaml がないリポジトリでは、Step 2 の検出結果をもとに .security/service-profile.yaml の案を提示してよい（作成は人間の承認後）。