security-audit

!bash "${CLAUDE_SKILL_DIR}/../../hooks/yaml-helper.sh" resolve_config --keys automation,workflow

自動化モード: modes.automation を解決します（project.local.yaml → project.yaml → デフォルト collaborative）。すべての AskUserQuestion 呼び出しと すべてのファイル書き込みは .claude/docs/automation-modes.md に従います （collaborative は常に確認 · guided は主要なもののみ · autonomous はログを記録して続行、 automation_always_ask カテゴリは常にプロンプトを表示）。

workflow（上記で解決済み）は、Phase 7 がリリースゲートについて何を伝えるかのみを決定します。standard と full ではこのレポートが必須であり、minimal では必須ではありません。監査自体はすべてのティアで同じように実行されます。

セキュリティ監査

セキュリティは、出荷されるあらゆるゲームにとって省略できません。シングルプレイヤーゲームであっても、セーブデータ改ざんの経路が存在します。マルチプレイヤーゲームには、チートの余地、データ露出のリスク、サービス妨害の可能性があります。このスキルは、コードベースに対して最も一般的なゲームセキュリティの不備を体系的に監査し、優先順位付けされた修正計画を作成します。

このスキルを実行するタイミング:

• 公開リリースの前（workflow: standard および full では Polish → Release ゲートに必須）
• オンライン/マルチプレイヤー機能を有効にする前
• ディスクまたはネットワークから読み取るシステムを実装した後
• セキュリティ関連のバグが報告されたとき

出力: production/security/security-audit-[date]-[scope].md — 名前にスコープを含めることで、同じ日に実行した quick または save が、リリースゲートが参照する full レポートを上書きするのを防ぎます。

---

フェーズ 1：引数とスコープの解析

モード：

• full — すべてのカテゴリ（リリース前に推奨）
• network — ネットワーク／マルチプレイヤーのみ
• save — セーブファイルとシリアライズのみ
• input — 入力の検証とインジェクションのみ
• quick — 高深刻度のチェックのみ（最速。反復的な使用向け）
• 引数なし — full を実行

project.yaml を読み込み、以下を確認します。キーがない場合、または空の場合は、エンジン／言語／プラットフォームについて .claude/docs/technical-preferences.md をフォールバックとして使用します。

• engine.name と engine.language — 重要な要素です。フェーズ 3 のパターンセットを選択します。カテゴリについて出典のあるセットがないエンジンでは、そのカテゴリは NOT ASSESSED になります。 engine.name がない場合、または空の場合は、レポートにその旨を記載し、すべての grep カテゴリを NOT ASSESSED とします。Godot のリストはすべて記載されているため、そちらにフォールバックしてはいけません。

• platform.targets（適用される攻撃対象領域に影響します）

• マルチプレイヤー／ネットワークが対象範囲かどうかを示す platform.multiplayer と platform.online。technical-preferences.md に相当するフィールドはないため、従来のフォールバックでは補えません。

  キーがないことは false を意味しません。 これらのキーには読み取り側（このスキル）がありますが、セットアップフローには書き込み側がありません。/setup-engine も /start も platform: ブロックを出力せず、実行時に /settings だけが設定するため、ほとんどの CCGS プロジェクトでは両方のキーがありません。これらを false として扱うと、本当にマルチプレイヤー機能があるプロジェクトも含め、すべてのプロジェクトでカテゴリ 2（ネットワークとマルチプレイヤーのセキュリティ）がスキップされます。値を何も設定しないまま、セキュリティカテゴリがフェイルオープンになることを意味します。

  いずれかのキーがない場合、または空の場合：シングルプレイヤーだと決めつけず、カテゴリ 2 をスキップしないでください。 ゲームにマルチプレイヤー機能またはオンライン機能があるか、ユーザーに確認してください。確認できない場合でもカテゴリ 2 を実行し、NOT ASSESSED — multiplayer scope unconfirmed (platform.multiplayer unset — set it with /settings) と記録します。この場合、フェーズ 5 により CLEAR TO SHIP には到達できません。スコープが未確認の間は、マルチプレイヤーゲームとして深刻度を評価してください。未解決の HIGH があれば DO NOT SHIP となります。また、security-engineer が行うように、マルチプレイヤーを想定した評価であることをレポートに記載してください。 シングルプレイヤーゲームを余分にスキャンしても数分かかるだけですが、マルチプレイヤーゲームのスキャンが不足すると、カテゴリを未実行のままリリースすることになります。

  /settings platform.multiplayer=true で明示的に設定してください（プロジェクト全体に適用されるため、--local は拒否されます）。project.yaml に記録することが解決策です。誰かが設定するまで、このルールがガードとなります。

---

フェーズ 2：セキュリティエンジニアの起動

Agent 経由で security-engineer を起動します。監査はこのエージェントの担当なので、代わりにこのセッションで各カテゴリを実行しないでください。起動できない場合は、その理由を伝え、ここでスキャンを実行し、レポートの Audited by 行にその旨を記載します。

以下の固定ブリーフテンプレートを送信してください。 {…} の箇所だけを、project.yaml（ない場合は technical preferences）、.claude/docs/code-root-resolution.md に従って解決したコードルート、およびフェーズ 3 の記載どおりにコピーしたテキストで埋めます。ほかには何も追加しないでください。ゲームの種類に関する見解、予想される深刻度、検出結果への意見はいずれも加えないでください。独自の文を加えると、事前評価が入り込むことになります。

Run a security audit of this project for /security-audit.

Scope: {full | network | save | input | quick}
Engine: {engine.name} {engine.version}, language {engine.language}
platform.multiplayer: {true | false | unset}    platform.online: {true | false | unset}    Phase 1 answer: {multiplayer | single-player | not asked}
Code root: {the resolved code root, or "unresolved"}
Also scan: {assets/data/ and the config files that exist, or "none"}
Categories to run, with their checks and grep patterns for this engine:
{each Phase 3 category this scope runs, copied as written, with the table's row for this engine}
NOT SOURCEABLE on this engine: {categories, or "none"} — report each NOT ASSESSED; never call it reviewed, verified safe or passed
Skipped, with reason: {e.g. "Category 2 — platform.multiplayer and platform.online are false", or "none"}
Report: production/security/security-audit-{date}-{scope}.md — return the report as text; /security-audit writes the file after asking

Severity (rate every finding yourself, against this table only):
- CRITICAL: Remote code execution, data breach, or trivially-exploitable cheat that breaks multiplayer integrity
- HIGH: Save tampering that bypasses progression, credential exposure, or server-side authority bypass
- MEDIUM: Client-side cheat enablement, information disclosure, or input validation gap with limited impact
- LOW: Defence-in-depth improvement — hardening that reduces attack surface but no direct exploit exists
Nothing in this brief sets or suggests a severity. The game's type never lowers a rating: a single-player game is rated on the same table. The one adjustment is upward — when the game is multiplayer, or its scope is unconfirmed (unset and not answered), a HIGH counts as CRITICAL; say so where it applies.
Report each finding as SEC-NNN with category, file:line, description, attack scenario, remediation and effort, grouped by severity.

評価ルールはテンプレートに含まれているため、改めて説明する必要はありません。表では、進行を回避するセーブデータの改ざんをすでに HIGH と評価しており、エージェントが各検出結果をその基準に照らして評価し、フェーズ 5 でマルチプレイヤーのルールを推奨事項に適用します。

コードルートを解決できない場合は、推測した値を渡さないでください。コードをスキャンするすべてのカテゴリは NOT ASSESSED — code root unresolved となり、レポートにもその旨を記載します。コードルートが空の場合、フェーズ 5 では実装不足のケースとなり、コードをスキャンする各カテゴリは検出数ゼロではなく、NOT ASSESSED — no source under <root> となります。どちらの場合も、クリーンとは報告されません。

security-engineer が 6 つのカテゴリ（フェーズ 3 参照）を監査します。先に進む前に、すべての検出結果を収集してください。

---

フェーズ 3：監査カテゴリ

セキュリティエンジニアは、以下の各項目を評価します。プロジェクトの範囲に該当しないカテゴリは省略し、省略した各カテゴリとその理由をエグゼクティブサマリーに記載してください（Category 2 — skipped: platform.multiplayer and platform.online are false）。

エンジン別パターンセット — 以下のカテゴリに進む前に必ずお読みください

カテゴリ 1～3 のパターンリストはすべて Godot 向けです。 Unity または Unreal のプロジェクトでは何も一致せず、スキャンでヒットがゼロの場合、レポートがクリーンと判定されます。 これは「セキュリティ監査で起こり得る最も危険な失敗」です。フェーズ 1 で特定した engine.name に応じて、次の表を使用してください。

カテゴリ	Godot	Unity	Unreal
1 — セーブ／シリアル化	以下の Godot リスト	ソースを確認できません	ソースを確認できません
2 — ネットワーク／マルチプレイヤー	以下の Godot リスト	ServerRpc、ClientRpc、NetworkVariable、NetworkObject、NetworkManager、NetworkBehaviour、IsServer、IsOwner	UFUNCTION、Server、Client、NetMulticast、Replicated、DOREPLIFETIME、GetLifetimeReplicatedProps、HasAuthority
3 — 入力	以下の Godot リスト	InputSystem、PlayerInput、ReadValue、InputValue	EnhancedInput、UInputAction、InputMappingContext、BindAction、FInputActionValue
4 — データ露出	エンジンに依存しません — 以下のリストは3つすべてに適用されます
5、6	判定とマニフェストが対象です。grep 用のエンジン別セットは不要です

上記の Unity と Unreal の名称は、記憶に基づくものではなく、このリポジトリに固定された リファレンス（docs/engine-reference/unity/modules/{networking,input}.md、 docs/engine-reference/unreal/modules/{networking,input}.md）を出典としています。 使用前に固定バージョンのリファレンスと照合し、表に記載されていない内容でリファレンスに 記載されているものを追加してください。この表は最低限の一覧であり、完全な一覧ではありません。

NOT SOURCEABLE は判定結果であり、記憶で補うべき欠落ではありません。 どちらの リファレンスツリーにもシリアル化／セーブのモジュールがないため、Unity と Unreal の セーブ API 名はここでは確認できません。トレーニングデータをもとに記述しないでください。 このスキルでは、自信を持って誤ったパターンリストを作成することが他のどのケースよりも危険です。 何も検出せず、スキャンを網羅的に見せ、問題なしと受け取られるレポートを生み出すためです。 表に「NOT SOURCEABLE」とある場合、このエンジンではそのカテゴリは**「評価対象外」**です — フェーズ 5 を参照してください。適切に対応するには、他のモジュールと同様に出典を明記した セーブ／シリアル化モジュールを docs/engine-reference/<engine>/modules/ に追加してください。 モジュールが追加されたら、そこからカテゴリのパターン名を取得してレポートで引用し、 カテゴリを実行してください。

カテゴリ 1：セーブファイルとシリアライズのセキュリティ

• セーブファイルは読み込み前に検証されていますか？（無検証のデシリアライズをしない）
• セーブファイルのパスはユーザー入力から構築されていますか？（パストラバーサルのリスク）
• セーブファイルにはチェックサムまたは署名が付与されていますか？（改ざんの検出）
• ゲームは、セーブファイル内の数値を範囲チェックせずに信頼していますか？
• セーブファイルの読み込み付近に、eval() や動的コード実行の呼び出しはありますか？

Grep パターン — このリストを信頼する前に、固定されたエンジンリファレンスを確認してください （下記の API 名に関する警告を参照）：FileAccess、File.open、open(、load、 deserialize、parse、parse_string、from_json、read_file、get_var、 bytes_to_var — それぞれについて検証の有無を確認してください。

API 名はバージョンによって異なります。このリストは出発点であり、完全な一覧ではありません。 File.open は Godot 3.x の API です。Godot 4 ではクラス名が FileAccess に変更されています （docs/engine-reference/godot/breaking-changes.md）。これらのパターンを使う前に、プロジェクトが固定しているバージョンの docs/engine-reference/<engine>/ を読み、ドキュメントに記載されている名前を追加してください。すでに存在しないクラスを Grep してもヒット数はゼロになり、このカテゴリでヒット数がゼロだと、レポートは問題なしと判定します — セキュリティ監査で起こりうる最も危険な失敗です。 Godot 4 のプロジェクトに対して File.open だけを検索すると何も見つからず、誰も確認していないコードベースに対して「リリース可能」と報告されてしまいます。固定バージョンで正しい名前を確認できない場合は、ヒット数ゼロのスキャンを合格として提示するのではなく、その旨をレポートに記載してください。

カテゴリ 2：ネットワークとマルチプレイヤーのセキュリティ（シングルプレイヤー専用の場合はスキップ）

• ゲームの状態はサーバーが決定していますか。それともクライアントが結果を決めていますか？
• 受信ネットワークパケットは、サイズ、型、値の範囲について検証されていますか？
• プレイヤーの位置と状態の変更は、サーバー側で検証されていますか？
• ネットワーク呼び出しにレート制限はありますか？
• 認証トークンは適切に扱われていますか？（決して平文で送信しない）
• ゲームはリリースビルドでデバッグ用エンドポイントを公開していますか？

次の文字列を Grep してください：recv、receive、PacketPeer、socket、MultiplayerPeer、 ENetMultiplayerPeer、NetworkedMultiplayerPeer、rpc、rpc_id、 @rpc — それぞれの呼び出し箇所で検証の有無を確認してください。

カテゴリ 1 と同じバージョンに関する注意点があります。NetworkedMultiplayerPeer は Godot 3.x の API です。 Godot 4 では ENetMultiplayerPeer を使います （docs/engine-reference/godot/modules/networking.md）。単独の部分文字列 MultiplayerPeer は両方に一致するため、より安全な検索語です。

カテゴリ 3：入力の検証

• プレイヤーが指定した文字列がファイルパスに使用されていますか？（パストラバーサル）
• プレイヤーが指定した文字列がサニタイズされずにログへ記録されていますか？（ログインジェクション）
• 数値入力（例：アイテムの数量、キャラクターのステータス）は、使用前に範囲チェックされていますか？
• 実績や統計の値は、バックエンドに書き込む前に検証されていますか？

次の文字列を Grep してください：get_input、Input.get_、input_map、ユーザー向けのテキストフィールド — 検証の有無を確認してください。

カテゴリ 4：データの露出

• API キー、認証情報、シークレットが、コードのルートまたは assets/ にハードコードされていますか？
• デバッグシンボルや詳細なエラーメッセージがリリースビルドに含まれていますか？
• ゲームは機微なプレイヤーデータをディスクまたはコンソールに記録していますか？
• 内部ファイルパスやシステム情報がプレイヤーに露出していますか？

リリース向けコードを対象に、大文字と小文字を区別せず、次の文字列を検索してください：api[_-]?key、secret、 password、token、private[_-]?key、sk_live、BEGIN PRIVATE KEY、DEBUG、 およびエンジンの print 呼び出し（Godot では print(、Unity では Debug.Log、Unreal では UE_LOG）。

カテゴリ 5：チートと改ざん対策の攻撃ベクトル

• ゲームプレイに重要な値は、簡単に編集できるファイルには保存せず、メモリ内にのみ保存されていますか？
• 重要なゲーム進行フラグ（例：「DLC の支払い済み」）はサーバー側で検証されていますか？
• マルチプレイヤー向けに、メモリ編集ツール（Cheat Engine など）への対策はありますか？
• リーダーボードやスコアの送信内容は、受理前に検証されていますか？

注：クライアント側のアンチチートは、ほとんど強制できません。競争要素または収益化に関わるものについては、サーバー側での検証に重点を置いてください。

カテゴリ 6：依存関係とサプライチェーン

• サードパーティ製のプラグインやライブラリを使用していますか？一覧にしてください。
• 使用中のバージョンに既知の CVE があるプラグインはありますか？
• プラグインのソースは検証されていますか（公式マーケットプレイス、レビュー済みのリポジトリなど）？

addons/、plugins/、third_party/、vendor/ を glob し、外部依存関係をすべて列挙してください。

---

フェーズ 4：調査結果を分類する

各調査結果に、次の項目を割り当ててください。

重大度：

レベル	定義
CRITICAL	リモートコード実行、データ侵害、またはマルチプレイヤーの整合性を損なう、容易に悪用可能なチート
HIGH	進行を回避するセーブデータの改ざん、認証情報の漏えい、またはサーバー側の権限回避
MEDIUM	クライアント側でのチート有効化、情報漏えい、または影響が限定的な入力検証の不備
LOW	多層防御の改善 — 攻撃対象領域を縮小する強化策ですが、直接悪用できる脆弱性はありません

ステータス： 未対応 / 受容済みリスク / 対象外

---

フェーズ 5：レポートを生成する

# Security Audit Report

**Date**: [date]
**Scope**: [full | network | save | input | quick]
**Engine**: [engine + version]
**Audited by**: [security-engineer via /security-audit | this session — security-engineer not spawned: reason]
**Files scanned**: [N source files, N config files]

---

## Executive Summary

| Severity | Count | Must Fix Before Release |
|----------|-------|------------------------|
| CRITICAL | [N] | Yes — all |
| HIGH | [N] | Yes — all |
| MEDIUM | [N] | Recommended |
| LOW | [N] | Optional |

**Release recommendation**: [NOT ASSESSED — INSUFFICIENT IMPLEMENTATION / CLEAR TO SHIP / FIX BEFORE SHIPPING / DO NOT SHIP]

Choose it by the open findings, first match wins:
- **DO NOT SHIP** — any open CRITICAL finding (in a multiplayer game, any open HIGH
  counts as CRITICAL)
- **FIX BEFORE SHIPPING** — open HIGH findings and no CRITICAL; the Polish → Release
  gate needs zero open HIGH (at `standard` and `full`)
- **NOT ASSESSED** — per the rule below, when the scan could not cover the surface.
  It ranks below both failure values — a known finding is more actionable than an
  unscanned category, and still has to be fixed — and above CLEAR TO SHIP
- **CLEAR TO SHIP** — no open CRITICAL or HIGH (MEDIUM and LOW may remain)

> **`NOT ASSESSED` is required when there was not enough implemented surface to
> audit**, or when the API names for the pinned engine version could not be
> confirmed — **in place of CLEAR TO SHIP, never of a failure value.** An open
> CRITICAL or HIGH still decides the recommendation (first match above): a run
> with an unscanned category and an open HIGH is FIX BEFORE SHIPPING, and names
> the unscanned category beside it. A zero-finding scan over two files of source is not a clean bill of
> health, and `CLEAR TO SHIP` must never be reachable by having nothing to look
> at. Name what was missing and which skill produces it.
>
> **The engine axis is part of that rule, not a separate one.** If
> the Phase 3 table marks a category `NOT SOURCEABLE` for this project's
> `engine.name`, that category is `NOT ASSESSED` — state it by name in the
> Executive Summary, and **`CLEAR TO SHIP` is unreachable for the run**. The
> category reads `NOT ASSESSED — <category> has no sourced pattern set for
> <engine>`; the release recommendation is still the first match above, so it is
> NOT ASSESSED only where the run would otherwise have been CLEAR TO SHIP. Never
> report the category as reviewed by other means: files it covers may still be
> read for another category, and a finding that read turns up is reported, but
> the category stays NOT ASSESSED — never "reviewed", "verified safe" or passed.
> A scan that could not look is not a scan that found nothing, and only the
> report can tell the reader which of the two happened.

---

## CRITICAL Findings

### SEC-001: [Title]
**Category**: [Save / Network / Input / Data / Cheat / Dependency]
**File**: `[path]` line [N]
**Description**: [What the vulnerability is]
**Attack scenario**: [How a malicious user would exploit it]
**Remediation**: [Specific code change or pattern to apply]
**Effort**: [Low / Medium / High]

[repeat per finding]

---

## HIGH Findings

[same format]

---

## MEDIUM Findings

[same format]

---

## LOW Findings

[same format]

---

## Accepted Risk

[Any findings explicitly accepted by the team with rationale]

---

## Dependency Inventory

| Plugin / Library | Version | Source | Known CVEs |
|-----------------|---------|--------|------------|
| [name] | [version] | [source] | [none / CVE-XXXX-NNNN] |

---

## Remediation Priority Order

1. [SEC-NNN] — [1-line description] — Est. effort: [Low/Medium/High]
2. ...

---

## Re-Audit Trigger

Run `/security-audit` again after remediating any CRITICAL or HIGH findings.
At `workflow: standard` and `full`, the Polish → Release gate requires this report with no open CRITICAL or HIGH items.

---

フェーズ 6：レポートを作成する

レポートの要約（エグゼクティブサマリー + CRITICAL/HIGH の調査結果のみ）を会話内に提示してください。

「セキュリティ監査の完全なレポートを production/security/security-audit-[date]-[scope].md に書き込んでもよろしいですか？」と尋ねてください。

承認を得てから書き込んでください。

---

フェーズ 7：ゲート統合

このレポートは、workflow: standard と full の Polish → Release ゲートで必須の成果物です。minimal ゲートでは、smoke と S1 バグ以外のすべてとともに除外されます。上で解決した workflow に基づき、このプロジェクトに適用されるものを明示してください。

調査結果を修正した後、/gate-check release を実行する前に /security-audit quick を再実行して、CRITICAL/HIGH の項目が解決されていることを確認してください。

調査結果の件数だけで判断せず、リリースの推奨に基づいて分岐してください。

DO NOT SHIP（未対応の CRITICAL がある場合、またはマルチプレイヤーゲームで未対応の HIGH がある場合）の場合：

「⛔ CRITICAL のセキュリティ調査結果は、公開リリースの前に解決する必要があります。これらに対処するまで /launch-checklist に進まないでください。」

FIX BEFORE SHIPPING（未対応の HIGH があり、CRITICAL はなく、シングルプレイヤーの場合）の場合：

workflow: standard/full の場合：「⚠️ HIGH の調査結果が [N] 件未対応です。Polish → Release ゲートのセキュリティ監査項目では、未対応の項目がないことが必要です。修正してから、/gate-check release の前に /security-audit quick を再実行してください。」

minimal の場合：「⚠️ HIGH の調査結果が [N] 件未対応です。出荷前に修正して /security-audit quick を再実行してください。minimal リリースゲートはこのレポートを読み込みませんが、未対応の HIGH があるため、推奨は FIX BEFORE SHIPPING のままです。」

NOT ASSESSED の場合：

「セキュリティ監査は未評価です — [未評価の各カテゴリとその理由]。レポートは 作成済みです。[workflow: standard/full の場合：] 不足している入力が提供され、 監査が再実行されるまで、/gate-check release ではセキュリティ項目が未評価と 報告されます。[minimal の場合：] minimal リリースゲートはこのレポートを 読み込みませんが、不足している入力が提供されるまでは、これらのカテゴリは 未スキャンのままです。」

各カテゴリについて不足している入力を明示してください。engine.name、コードルート、 マルチプレイヤーの対象範囲（/settings platform.multiplayer=…）、または、 Phase 3 の表でこのエンジンでは NOT SOURCEABLE とされるカテゴリ（Unity と Unreal ではこれが通常の原因）の場合は、docs/engine-reference/<engine>/modules/ にあるセーブ／シリアライズモジュールです。また、そのカテゴリ名も明示してください。

CLEAR TO SHIP の場合：

「✅ リリースを妨げるセキュリティ調査結果はありません。レポートは production/security/ に作成済みです。/gate-check release の実行時に、このパスを含めてください。」

---

協調プロトコル

• パターンが安全だと決めつけないでください — 指摘し、判断はユーザーに委ねてください
• リスクを受け入れることも有効な判断です — ソロチームでは、LOW の指摘を許容可能なトレードオフとする場合があります。判断を記録してください
• マルチプレイヤーゲームにはより高い基準が求められます — マルチプレイヤーの状況で HIGH の指摘があれば、CRITICAL として扱ってください
• これは侵入テストではありません — この監査では一般的なパターンを対象としています。競技性のある、または収益化を伴うマルチプレイヤーゲームを公開する前に、人間のセキュリティ専門家による実際の侵入テストを受けることを推奨します