claude-security-check 0.0.0-stage → 0.1.0

package/CHANGELOG.md

@@ -0,0 +1,4 @@
+# Changelog
+
+## 0.1.0
+- 初版。手順 5 本・観点表 18 項目・事例 12 件（他社 1・匿名の実例 11）・再現スクリプト 2 本

package/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 kanketsu-jp
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/README.md

@@ -1,3 +1,51 @@
-# Temporary Holding Version
+# claude-security-check
 
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+Claude Code の Skill です。本番システムを**読み取りだけで**点検し、次の 2 つに実測で答えます。
+
+- どこから入れるか（外部公開面・認証の入口・認可の穴）
+- 入られたら、何時・どこから・何をされたかを後から並べられるか（ログの保存・除外・監査ログ・検知）
+
+観点表の各行は、実際に起きたインシデント・ヒヤリハットと、他社の公表事件から作っています。
+事例は `incidents/` にカテゴリ別のディレクトリで足していけます。
+
+## インストール
+
+```bash
+npx claude-security-check install            # ~/.claude/skills/security-check へ
+npx claude-security-check install --project  # ./.claude/skills/security-check へ
+```
+
+Claude Code で `/security-check` と打つと開きます（`disable-model-invocation: true` なので、自動では読み込まれません）。
+
+更新するときは `--force` を付けます。`SKILL.md` と `procedure/` は上書きし、自分で足した事例と `incidents/INDEX.md` は残します。
+
+**自分の組織の事例を足したディレクトリは、公開リポジトリに置かないでください。** 未対策の穴の一覧は、攻撃者にとっての地図になります。
+
+## 中身
+
+```
+skill/
+├─ SKILL.md                     点検の安全ルールと 6 段階の手順
+├─ procedure/
+│  ├─ 01-scope.md               範囲と、先に読む前提
+│  ├─ 02-surface-map.md         構成と外部公開面の地図
+│  ├─ 03-auth-checklist.md      認証・認可の観点表（18 項目）
+│  ├─ 04-forensics-readiness.md 攻撃者の行動をログで追えるか（読み取りの測定コマンドと判定表）
+│  └─ 05-report.md              報告の型と、出し先の決め方
+└─ incidents/
+   ├─ INDEX.md / _template.md
+   └─ <カテゴリ>/<事例>.md      他社 1 件・匿名の実例 11 件
+examples/
+├─ hono-mount.mjs               app.use の bare パスとサブパスの違いを再現
+└─ hmac-empty.mjs               空の鍵の HMAC 検証が通ることを再現
+```
+
+## 前提
+
+- Claude Code（Skill が使えるバージョン）
+- 測定コマンドの例は Google Cloud（Cloud Run ＋ Cloud Logging）と `gcloud` です。観点は他のクラウドでも同じです。
+- `examples/` を動かすには Node.js 18.17 以上（`hono-mount.mjs` は `npm i hono` が要ります）。
+
+## License
+
+MIT

package/bin/cli.mjs

@@ -0,0 +1,61 @@
+#!/usr/bin/env node
+import { cpSync, existsSync, mkdirSync, readdirSync, statSync, copyFileSync } from "node:fs";
+import { homedir } from "node:os";
+import { dirname, join, relative, resolve } from "node:path";
+import { fileURLToPath } from "node:url";
+
+const SKILL_NAME = "security-check";
+const SRC = resolve(dirname(fileURLToPath(import.meta.url)), "..", "skill");
+
+const USAGE = `usage: claude-security-check <command> [options]
+
+commands:
+  install     スキルを ~/.claude/skills/${SKILL_NAME} にコピーする
+  path        同梱しているスキルの場所を表示する
+
+options (install):
+  --project   ./.claude/skills/${SKILL_NAME} にコピーする（プロジェクト単位）
+  --dir <p>   コピー先の skills ディレクトリを指定する
+  --force     既にあるとき、SKILL.md と procedure/ を上書きし、無い事例だけ足す
+              （incidents/ の既存ファイルと INDEX.md は上書きしない）`;
+
+function walk(dir) {
+  return readdirSync(dir).flatMap((name) => {
+    const p = join(dir, name);
+    return statSync(p).isDirectory() ? walk(p) : [p];
+  });
+}
+
+function install(args) {
+  const i = args.indexOf("--dir");
+  const base = i >= 0 ? resolve(args[i + 1] ?? "") :
+    args.includes("--project") ? resolve(".claude", "skills") : join(homedir(), ".claude", "skills");
+  const dest = join(base, SKILL_NAME);
+
+  if (!existsSync(dest)) {
+    mkdirSync(base, { recursive: true });
+    cpSync(SRC, dest, { recursive: true });
+    console.log(`installed: ${dest}`);
+    return;
+  }
+  if (!args.includes("--force")) {
+    console.error(`already exists: ${dest}\n上書きするなら --force（自分で足した事例と INDEX.md は残ります）`);
+    process.exit(1);
+  }
+  let updated = 0, added = 0, kept = 0;
+  for (const file of walk(SRC)) {
+    const rel = relative(SRC, file);
+    const target = join(dest, rel);
+    const isIncident = rel.startsWith("incidents") && !rel.endsWith("_template.md");
+    if (isIncident && existsSync(target)) { kept++; continue; }
+    mkdirSync(dirname(target), { recursive: true });
+    existsSync(target) ? updated++ : added++;
+    copyFileSync(file, target);
+  }
+  console.log(`updated: ${dest} (上書き ${updated} / 追加 ${added} / 残した事例 ${kept})`);
+}
+
+const [cmd, ...rest] = process.argv.slice(2);
+if (cmd === "install") install(rest);
+else if (cmd === "path") console.log(SRC);
+else { console.log(USAGE); process.exit(cmd ? 1 : 0); }

package/examples/hmac-empty.mjs

@@ -0,0 +1,12 @@
+import { createHmac, timingSafeEqual } from "node:crypto";
+const secret = process.env.WEBHOOK_SECRET ?? "";   // 未設定なら空文字
+const body = JSON.stringify({ orderId: 1, status: "shipped" });
+
+// 攻撃者側: 空の鍵で署名を作る
+const forged = createHmac("sha256", "").update(body).digest("hex");
+
+// サーバ側: 受け取った署名を検証する
+const expected = createHmac("sha256", secret).update(body).digest("hex");
+const ok = timingSafeEqual(Buffer.from(forged), Buffer.from(expected));
+console.log("WEBHOOK_SECRET set?", process.env.WEBHOOK_SECRET !== undefined);
+console.log("forged signature accepted?", ok);

package/examples/hono-mount.mjs

@@ -0,0 +1,20 @@
+import { Hono } from "hono";
+const auth = async (c, next) => c.req.header("x-api-key") === "secret" ? next() : c.text("unauthorized", 401);
+
+const app = new Hono();
+app.use("/api/visit-logs", auth);                 // bare パスだけに掛けた
+app.get("/api/visit-logs", (c) => c.json({ list: [] }));
+app.get("/api/visit-logs/lookup", (c) => c.json({ name: "山田 太郎" }));
+
+const fixed = new Hono();
+fixed.use("/api/visit-logs", auth);
+fixed.use("/api/visit-logs/*", auth);             // サブパスにも掛ける
+fixed.get("/api/visit-logs", (c) => c.json({ list: [] }));
+fixed.get("/api/visit-logs/lookup", (c) => c.json({ name: "山田 太郎" }));
+
+for (const [label, a] of [["bare のみ", app], ["bare + /*", fixed]]) {
+  for (const p of ["/api/visit-logs", "/api/visit-logs/lookup"]) {
+    const r = await a.request(p);
+    console.log(label.padEnd(10), p.padEnd(24), r.status);
+  }
+}

package/package.json

@@ -1,6 +1,32 @@
 {
   "name": "claude-security-check",
-  "version": "0.0.0-stage",
-  "stub": true,
-  "description": "Temporary package placeholder for staged publishing"
-}
+  "version": "0.1.0",
+  "description": "Claude Code の Skill: 本番システムを読み取りだけで点検し、認可の穴と「攻撃されたら後から追えるか」を実測で答える手順と、実際の事例集",
+  "type": "module",
+  "bin": {
+    "claude-security-check": "bin/cli.mjs"
+  },
+  "files": [
+    "bin",
+    "skill",
+    "examples",
+    "README.md",
+    "LICENSE",
+    "CHANGELOG.md"
+  ],
+  "engines": {
+    "node": ">=18.17"
+  },
+  "keywords": [
+    "claude-code",
+    "claude-skill",
+    "security",
+    "forensics",
+    "authorization",
+    "cloud-run",
+    "supabase",
+    "hono"
+  ],
+  "license": "MIT",
+  "author": "kanketsu-jp"
+}

package/skill/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: security-check
+description: 本番システムのセキュリティ点検を、読み取りだけで行う。構成と外部公開面の地図づくり、認証・認可の観点チェック、攻撃者の行動をログで後から追えるかの点検をして、実測とコード上を分けて報告する。実際に起きたインシデント・ヒヤリハット・他社の公表事件を incidents/ にカテゴリ別で貯め、点検のたびに照らす。「セキュリティチェックして」「この事件みたいなことがうちで起きたら追える？」「認証の穴を洗って」「インシデント事例を追加して」と言われたときに使う。
+disable-model-invocation: true
+---
+
+# security-check
+
+本番システムを**壊さずに**点検し、「どこから入れるか」「入られたら後から追えるか」を実測で答えるための手順と事例集です。
+観点表の各行は、実際に起きた事例から作っています。事例は `incidents/` にカテゴリ別で足していけます。
+
+## 0. 絶対に守ること（点検の安全）
+
+1. **読むだけ。** 編集・commit・push・本番の設定変更・デプロイをしない（利用者の明示の指示があるまで）。
+   本番クラウドは**設定のメタデータと件数**だけ読む（バケット一覧・sink 一覧・IAM ポリシー・ステータス別の件数）。
+2. **秘密の値・個人情報を出さない。** 出してよいのは Secret の**名前**、件数、フィールド名まで。
+   IP・メール・氏名はログから引いても報告に載せない（必要なら伏せ字）。`.env*` は開かない。
+3. **アカウントを取り違えない。** 複数の組織・アカウントを持つ環境では、`--account` / `--project` を**コマンドごとに**付ける。
+   `gcloud config set account` や `gh auth switch` で既定を変えない（同じ PC の別セッションまで巻き込む）。
+4. **実測とコード上を書き分ける。** 各断定に `実測` / `コード上` / `未確認` を付ける。
+   「0 件」は「異常が無い 0」と「見ていない 0」を区別して書く。
+5. **報告の置き場の公開範囲を先に決める。** 穴の一覧は攻撃者にとっての地図です。
+   社内の共有サービスには「全社チームが自動で付いて外せない」ものがある（incidents/access-sharing/）。
+   作る前に、誰が読めるかを確かめる。
+
+## 1. 手順（この順で進める）
+
+| # | やること | 詳細 |
+|---|---|---|
+| 1 | 範囲と前提を読む（AGENTS.md / CLAUDE.md / 認証・M2M・公開エンドポイントに関するルール文書） | [procedure/01-scope.md](procedure/01-scope.md) |
+| 2 | 構成と外部公開面の地図（ingress・invoker・認証の入口・公開エンドポイント・DB・Secret） | [procedure/02-surface-map.md](procedure/02-surface-map.md) |
+| 3 | 認証・認可の観点チェック（事例から作った観点表） | [procedure/03-auth-checklist.md](procedure/03-auth-checklist.md) |
+| 4 | 攻撃者の行動をログで追えるか（保存期間・除外・監査ログ・WAF・検知） | [procedure/04-forensics-readiness.md](procedure/04-forensics-readiness.md) |
+| 5 | **incidents/ を照らす**（同じ型が今のコードに無いか） | [incidents/INDEX.md](incidents/INDEX.md) |
+| 6 | 報告（結論→表→穴→対策の優先度→次の一手） | [procedure/05-report.md](procedure/05-report.md) |
+
+広い読み取り（全 route の棚卸し等）はサブエージェントへ**1 リポジトリ 1 体**で並列に振り、
+「読み取り専用」と明記して結論だけ受け取る。サブエージェントの「気になった点」は疑問として扱い、
+報告前に自分で根拠の行を開いて確かめる。
+
+## 2. 事例を足す
+
+- 新しく踏んだ・見つけた・他社で公表された → **その場で 1 件足す**。型は [incidents/_template.md](incidents/_template.md)。
+- 置き場: `incidents/<カテゴリ>/<slug>.md`（自社の事例は `YYYY-MM-DD-<system>-<slug>.md` にすると並べやすい）。
+  カテゴリが無ければディレクトリを作り、INDEX のカテゴリ表にも足す。
+- **INDEX.md の一覧とキーワードに 1 行足す**（索引に無いものは引かれない）。
+- リポジトリのルール文書に詳しい記録があるものは**要約＋出典パス**にとどめる（一つの事実は一か所）。
+- 「起こりそう」は書かない。**実際に起きた・実測で見つけた・公表された**ものだけ。
+- 🚨 自社の事例を書いたこのディレクトリを公開リポジトリやパッケージに載せない。未対策の穴が含まれる。

package/skill/incidents/INDEX.md

@@ -0,0 +1,38 @@
+# 事例の索引（インシデント・ヒヤリハット・他社事例）
+
+点検の手順 5 で全行を照らす。足したら**この表とキーワードに 1 行足す**（索引に無いものは引かれない）。
+grep の例: `grep -rli '<語>' ~/.claude/skills/security-check/incidents/`
+
+同梱の事例は、他社の公表事件 1 件と、ある組織で実際に起きて**直した**事例 11 件です（組織名・システム名・日付は伏せています）。
+自分の組織の事例を足したら、このディレクトリは公開しないでください。
+
+## カテゴリ（= ディレクトリ）
+| ディレクトリ | 何を入れるか | 観点表（procedure/03）の # |
+|---|---|---|
+| `external/` | 他社の公表事件 | X1〜X3 |
+| `unauth-route/` | 認証の掛かっていない口・公開判定の誤り | A1〜A4 |
+| `fail-open/` | 設定や依存が欠けたときに開いてしまう作り | F1・F2 |
+| `authz-idor/` | 認可の対象・基準の誤り（IDOR・管理者判定） | Z1〜Z4 |
+| `db-privileges/` | DB の権限・RLS・関数の実行権 | D1 |
+| `client-side-action/` | 利用者の端末から利用者の権限で外部へ書き込む動作 | C1 |
+| `logging-forensics/` | ログの漏えい・欠落・保存・検知 | L1・04 |
+| `access-sharing/` | 資料・成果物の公開範囲 | SKILL §0-5 |
+| `process/` | 作り方・テスト・レビューの手順が原因のもの | T1 |
+
+列挙・総当たり（E1）のように、まだ事例が無い観点は 03 にだけ載せています。事例ができたらディレクトリを作ってください。
+
+## 一覧
+| 組織 | 種別 | 重大度 | 事例 | キーワード |
+|---|---|---|---|---|
+| 他社 | 他社事例 | CRITICAL | [アルカディア: トラバーサル→設定ファイルの鍵→横展開](external/2026-10-arcadia-traversal-config-secret.md) | トラバーサル, 設定ファイル, シークレット, 検知遅れ |
+| 匿名 | インシデント | HIGH | [LIFF からの送信が無関係なトークに本人名義で出た](client-side-action/liff-send-posts-to-wrong-chat.md) | LIFF, sendMessages, 誤送信 |
+| 匿名 | インシデント相当 | HIGH | [「サーバー間だから認証不要」＋サブパス素通りで氏名が引けた](unauth-route/internal-route-and-subpath-bypass.md) | ingress, app.use, サブパス, 連番 |
+| 匿名 | インシデント相当 | HIGH | [HMAC 鍵が未設定で空文字検証（誰でも署名を作れる）](fail-open/webhook-hmac-empty-secret.md) | HMAC, 空鍵, ?? "" |
+| 匿名 | ヒヤリ | HIGH | [RED を見るために認可を if (true) に壊した](process/break-guard-to-see-red.md) | RED, if (true), テスト |
+| 匿名 | インシデント相当 | CRITICAL | [店舗作成 API の IDOR（所有権チェックが分岐の中だけ）](authz-idor/ownership-check-inside-branch.md) | IDOR, 所有権, service_role |
+| 匿名 | インシデント相当 | CRITICAL | [SECURITY DEFINER が anon に開いていた（ルール化の後に再発）](db-privileges/security-definer-open-to-anon.md) | SECURITY DEFINER, anon, REVOKE |
+| 匿名 | ヒヤリ | MEDIUM | [別アプリの認可の配線をコピーして管理者テーブルを取り違え](authz-idor/copied-admin-wiring.md) | 管理者テーブル, コピー配線 |
+| 匿名 | ヒヤリ | MEDIUM | [LINE チャネル ID が未設定で LIFF の検証が素通り](fail-open/idp-client-id-unset.md) | LIFF, client_id, fail-open |
+| 匿名 | インシデント | MEDIUM | [空の管理者テーブルで fail-closed → bot が全員 403](authz-idor/fail-closed-on-empty-admin-table.md) | fail-closed, 403 |
+| 匿名 | インシデント相当 | LOW〜MED | [Webhook の本文を console.log でそのまま出力（個人情報）](logging-forensics/webhook-body-console-log-pii.md) | ログ, 個人情報, redact |
+| 匿名 | ヒヤリ | LOW〜MED | [穴の一覧を置いた社内共有に全社チームが付いて外せない](access-sharing/internal-share-org-team-auto-attached.md) | 共有, 公開範囲 |

package/skill/incidents/_template.md

@@ -0,0 +1,24 @@
+# <一行の見出し：何が起きたか>
+
+| 項目 | 値 |
+|---|---|
+| 日付 | YYYY-MM-DD |
+| 組織 | 自社 / 他社（社名・公表されている場合のみ） |
+| システム | 例: 管理画面の BFF（Hono・Cloud Run） |
+| 種別 | インシデント（本番で起きた） / ヒヤリハット（本番前・実害なし・点検で発見） / 他社事例 |
+| 重大度 | CRITICAL / HIGH / MEDIUM / LOW |
+| 見つけ方 | 例: 定期監査・コミット監視のレビュー・利用者の報告・点検 |
+| 出典 | リポジトリのルール文書（パス:節）・公表資料の URL |
+| キーワード | INDEX と同じ語を 3〜6 個 |
+
+## 何が起きたか
+（事実だけ。実測した数値・ステータスコードがあれば書く）
+
+## なぜ起きたか
+（作り込みの型。「誰が悪いか」ではなく「どんな前提が崩れたか」）
+
+## どう直したか
+（直していなければ「未対応」と書く）
+
+## 点検で見ること
+（同じ型を見つけるための grep・コマンド・観点。procedure/03-auth-checklist.md の # と対応させる）

package/skill/incidents/access-sharing/internal-share-org-team-auto-attached.md

@@ -0,0 +1,22 @@
+# 点検結果（穴の一覧）を社内の共有サービスに置いたら、全社向けのチームが自動で付いて外せなかった
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | 社内の静的ページ共有サービス |
+| 種別 | ヒヤリハット（外部公開はしていない。閲覧できるようになったのは社内の数名） |
+| 重大度 | LOW〜MEDIUM（穴の一覧は攻撃者の地図。閲覧者を絞る意図が通らなかった） |
+| 見つけ方 | 作成した後の閲覧権限の確認 |
+| キーワード | 共有, 公開範囲, 全社チーム, 閲覧権限, 報告の置き場 |
+
+## 何が起きたか
+依頼に応じて非公開のページとして作ったが、既定で全社向けのチームが閲覧できる設定になった。「自分だけに絞る」の指示で外そうとしたが、「全社アクセス用のチームは外せません」と拒否された。
+
+## なぜ起きたか
+作る前に、共有サービスの既定の閲覧範囲と、それを外せるかを確かめなかった。
+
+## どう直したか
+本人だけが見られる置き場（Basic 認証を掛ける・本人限定の場所に移す）を選び直す。
+
+## 点検で見ること
+- SKILL.md §0-5。セキュリティの報告は**作る前に**置き場の閲覧範囲を決める

package/skill/incidents/authz-idor/copied-admin-wiring.md

@@ -0,0 +1,24 @@
+# 別アプリの認可の配線をコピーして、照合する管理者テーブルを取り違えかけた
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | 複数の小さな管理アプリが同じ BFF を使う構成 |
+| 種別 | ヒヤリハット（作業中に発見） |
+| 重大度 | MEDIUM（人と bot で認可の基準が食い違う。逆向きなら穴） |
+| 見つけ方 | 移設作業のレビュー |
+| キーワード | admin テーブル, コピー配線, actor, M2M |
+
+## 何が起きたか
+アプリ B の管理 API を移すとき、アプリ A の「管理者テーブル `a_admins` で actor を判定する」ミドルウェアをそのまま使った。
+アプリ B で通行を決めているのは `b_admins` なので、そちらにしか居ない管理者が 403 になる。
+
+## なぜ起きたか
+同じ形の名前（`*_admins`）でも役割が違った。アプリ B では通行の可否を決める表、アプリ A では LINE ID の置き場（判定はドメイン一致）。
+しかもアプリ A ではそのミドルウェアが**唯一のゲート**なので、外すと穴になる。前提が逆だった。
+
+## どう直したか
+アプリごとの管理者テーブルの役割表をルール文書に置き、配線する前に表で確かめる運用にした。
+
+## 点検で見ること
+- 03 の Z2。アプリごとに「誰を管理者とみなすか」を表にし、人（UI）と bot（M2M）で同じ基準か

package/skill/incidents/authz-idor/fail-closed-on-empty-admin-table.md

@@ -0,0 +1,23 @@
+# 空の管理者テーブルで fail-closed の照合を足し、bot 経由の操作が全員 403 になった
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | 社内 bot から呼ばれる M2M の書き込み API |
+| 種別 | インシデント（本番・可用性側） |
+| 重大度 | MEDIUM（守りを足して業務が止まった。人の UI は無事なので気づきにくい） |
+| 見つけ方 | 利用者からの報告（bot 経由の操作が 403） |
+| キーワード | fail-closed, 管理者テーブル, 403, M2M, 空テーブル |
+
+## 何が起きたか
+管理者テーブルとの照合（fail-closed）を足したが、本番も検証環境もテーブルは空で、埋める管理画面も無かった。
+本番に 1 行を手で入れても、他のメンバーは 403 のままだった。
+
+## なぜ起きたか
+照合先にデータが入っているかを確かめずに fail-closed にした。人はドメイン制限、bot は管理者テーブルと、基準が食い違っていた。
+
+## どう直したか
+テーブルが空ならドメインでの許可に戻し、1 件でも入れば厳格に照合する。照合を足すなら、埋める手段とセットにする。
+
+## 点検で見ること
+- 03 の Z3。セキュリティを強める提案をするときは「止まる人がいないか」を本番の件数（count のみ）で先に確かめる

package/skill/incidents/authz-idor/ownership-check-inside-branch.md

@@ -0,0 +1,25 @@
+# 店舗作成 API が他社の company.id をそのまま受け取り、他社に店舗を紐付けられた（IDOR）
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | Next.js の route handler ＋ Supabase（service_role で書き込み） |
+| 種別 | インシデント相当（本番コードに存在・監査で発見） |
+| 重大度 | CRITICAL（紐付けを経由して、被害企業の個人情報が RLS 上は正規に閲覧できる状態になる） |
+| 見つけ方 | 定期のセキュリティ監査 |
+| キーワード | IDOR, 所有権, company.id, service_role, 分岐の中だけの検証 |
+
+## 何が起きたか
+所有権のチェックが「`company.id` が無いときに既存の会社を探して使い回す」分岐の中にしか無かった。
+クライアントが最初から `company.id` を送ると分岐を通らず、他社の ID がそのまま service_role の INSERT に使われた。
+
+## なぜ起きたか
+- body を zod で検証せずに分解していた
+- ID を決める処理と所有権のチェックを同じ分岐に置き、ID が無いときしか検証が効かなかった
+- 後続の書き込みが service_role（RLS の外）だった
+
+## どう直したか
+`id` があれば必ず先頭で所有権を検証する。
+
+## 点検で見ること
+- 03 の Z1。body から他エンティティの ID を受ける書込 route を列挙し、検証の位置を見る

package/skill/incidents/client-side-action/liff-send-posts-to-wrong-chat.md

@@ -0,0 +1,25 @@
+# 顧客画面（LIFF）からの送信で、無関係な人とのトークに本人の発言としてメッセージが出た
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | LINE LIFF で動くアンケートの完了画面 |
+| 種別 | インシデント（本番・実機） |
+| 重大度 | HIGH（第三者とのトークへ本人名義で投稿・情報の誤送信） |
+| 見つけ方 | 実機テスト（他人とのトークで QR を読み取った） |
+| 出典 | https://developers.line.biz/ja/reference/liff/#send-messages |
+| キーワード | LIFF, sendMessages, 誤送信, getContext, utou, push |
+
+## 何が起きたか
+アンケートの完了時に `liff.sendMessages()` でお礼のメッセージを送っていた。このメソッドは、**LIFF を開いたトークに本人の発言として**投稿する。
+他人とのトークで QR を開けば、そのトークに出る。さらにサーバ側の push と重なり、2 通届いていた。
+
+## なぜ起きたか
+「公式アカウントとの 1:1 トークで開く」ことを前提にしていた。`liff.getContext().type === "utou"` は他人との 1:1 でも同じ値なので、判定に使えない。
+
+## どう直したか
+顧客画面からは送らない。すべてサーバからの push にし、冪等キーで 1 回答 1 通にした。
+クライアントのコードに送信 API が無いことを pre-push と CI で検査する。ラッパ関数も置かない。
+
+## 点検で見ること
+- 03 の C1。クライアント側のコードで「利用者の権限で外部へ書き込む」API（送信・投稿・共有）を grep

package/skill/incidents/db-privileges/security-definer-open-to-anon.md

@@ -0,0 +1,27 @@
+# SECURITY DEFINER 関数が anon に開いていた（REVOKE FROM PUBLIC だけでは anon が残る）
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | Supabase（PostgreSQL の関数を RPC で公開） |
+| 種別 | インシデント相当（本番。監査で 3 件 → ルール化した後に新しい関数で再発） |
+| 重大度 | CRITICAL（請求の根拠になる価格のスナップショットを、anon が書き換えられた） |
+| 見つけ方 | Supabase の security advisor ／ 本番での権限の読み取りクエリ |
+| 出典 | https://supabase.com/docs/guides/troubleshooting/how-can-i-revoke-execution-of-a-postgresql-function-2GYb0A ／ https://supabase.com/docs/guides/troubleshooting/custom-role-inherits-privileges-that-were-not-explicitly-granted-ddaa1c |
+| キーワード | SECURITY DEFINER, RPC, anon, REVOKE, ALTER DEFAULT PRIVILEGES, /rest/v1/rpc |
+
+## 何が起きたか
+- 監査: 注文の確定・プロフィール作成・検索の関数が anon/authenticated に EXECUTE で開いており、関数の中に呼び出し元の検証が無かった
+- 再発: ルールを書いた後に作った関数が、また anon に開いたままデプロイされた。本番で anon が実行できる関数は 13 件、そのうち 3 件は中で検証していなかった。ルールにあった仕組みの説明が不正確だったのが原因
+
+## なぜ起きたか
+Supabase は既定の権限設定で、`public` スキーマに作った関数の EXECUTE を anon / authenticated に**個別に**付ける。
+`REVOKE ... FROM PUBLIC` は PUBLIC の分しか外さないので、`has_function_privilege('anon', …)` は true のまま残る。
+「正規の呼び出しは service_role だから GRANT は無害」も誤りで、誰でも `POST /rest/v1/rpc/<fn>` で直接呼べる。
+
+## どう直したか
+`REVOKE ... FROM PUBLIC, anon, authenticated` を必須にした。anon が実行できる関数の台帳を置き、台帳に無いものが増えたら CI で落とす。
+
+## 点検で見ること
+- 03 の D1。本番で anon が実行できる SECURITY DEFINER を**読み取りで数え**、台帳と突き合わせる
+- DB に直結する構成（Drizzle 等）なら、同じ観点を「接続ユーザーの権限」で見る

package/skill/incidents/external/2026-10-arcadia-traversal-config-secret.md

@@ -0,0 +1,31 @@
+# 他社: ディレクトリトラバーサルで設定ファイルを取られ、中のサービス間の鍵で侵入が広がった
+
+| 項目 | 値 |
+|---|---|
+| 日付 | 2026-10-11〜15（公表 2026-10-19、報道 2026-10-20） |
+| 組織 | 他社（株式会社アルカディア。防災情報配信サービス等） |
+| 種別 | 他社事例 |
+| 重大度 | CRITICAL（メールアドレス最大約 313.6 万件などが漏えいした可能性、約 142 万通の不正メール送信。いずれも同社の公表値） |
+| 見つけ方 | アクセス開始から約 17 時間後、DB の異常負荷を社内の監視が検知 |
+| 出典 | https://www.itmedia.co.jp/news/article/2610/20/2000002426/ ／ 同社「不正アクセスの経過と当社の対処について」（2026-10-19） |
+| キーワード | トラバーサル, 設定ファイル, シークレット, 横展開, 検知遅れ, アクセスログ, 時系列 |
+
+## 何が起きたか（公表資料の時系列・抜粋）
+- 06:26 アクセス開始 → 06:54 ログイン用 JS 取得 → 07:31 モバイル用パス探索 → 09:23 ログイン API に気づき試行
+- 10:52 トラバーサルのチェック → 11:04 セッション固定のチェック → 15:49 SQLi のチェック
+- 15:51〜16:26 JS 大量取得・ログイン大量試行・パス総当たり
+- **16:39 config.ini の取得に成功**（メディアサーバのディレクトリトラバーサル）
+- その後、設定ファイル内の**サービス間ログイン用シークレットキー**でアカウント ID を総当たり→侵入→WordPress プラグイン追加・バックドア設置
+- 23:40 DB の異常負荷で検知。以降、遮断・パスワード変更・メール配信停止・復旧に 4 日
+
+## なぜ起きたか
+- ファイルパスを受け取る口にトラバーサルの脆弱性があった
+- サービス間の鍵を設定ファイルに平文で置いていた（1 つ漏れて横に広がった）
+- 探索・連打の段階で気づく仕組みが無かった（気づいたのは DB 負荷＝被害の後）
+
+## 学び（自分のシステムに当てはめる）
+- 公表できる分単位の時系列は、**アクセスログが全部残っていたから**作れた。成功リクエスト（2xx）を捨てていると「取得に成功」の行が残らない。
+- 共用の鍵は、漏れたときの範囲（何サービスに届くか）を先に把握しておく。
+
+## 点検で見ること
+- 03 の X1〜X3、04 の判定表を全部埋める

package/skill/incidents/fail-open/idp-client-id-unset.md

@@ -0,0 +1,23 @@
+# LINE のチャネル ID が未設定だと、どのチャネルのトークンでも LIFF の検証を通っていた
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | LINE LIFF のアクセストークン検証 |
+| 種別 | ヒヤリハット（設定は入っていたため実害なし） |
+| 重大度 | MEDIUM（設定ミス 1 回で、他社の LINE アプリのトークンでなりすましできる） |
+| 見つけ方 | 定期のセキュリティ監査 |
+| キーワード | LIFF, client_id, channelId, fail-open, IdP, audience |
+
+## 何が起きたか
+`if (options?.channelId && verifyData.client_id !== options.channelId)` の形だったため、
+チャネル ID の環境変数が空だと条件全体が偽になり、照合が飛ばされていた。
+
+## なぜ起きたか
+「設定値があるか」と「照合」を 1 つの条件式に混ぜた。同じファイル群の Origin 検証は「両方無ければ拒否」の fail-closed で、作りが食い違っていた。
+
+## どう直したか
+設定が無ければ先に拒否し、そのあとで照合する 2 段に分けた。
+
+## 点検で見ること
+- 03 の F1。IdP の audience / client_id / redirect_uri の検証を全部開き、設定が空のときの分岐を確かめる

package/skill/incidents/fail-open/webhook-hmac-empty-secret.md

@@ -0,0 +1,26 @@
+# Webhook の HMAC 鍵が未設定のとき空文字で検証していた（空の鍵は誰でも知っているので、誰でも署名を作れる）
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | 外部システムからの Webhook 受信口 |
+| 種別 | インシデント相当（鍵が未設定のまま検証環境にデプロイ済み） |
+| 重大度 | HIGH |
+| 見つけ方 | コミット監視のセキュリティレビュー（作った本人は気づいていない） |
+| キーワード | HMAC, 空鍵, ?? "", fail-open, Webhook, requireEnv |
+
+## 何が起きたか
+`webhookSecret: process.env.WEBHOOK_SECRET ?? ""` と書き、仕様にもコミットにも「未設定なら絶対に一致しないので全部 401」と書いていた。
+実際には空文字でも HMAC は計算でき、空の鍵は攻撃者も知っている。つまり誰でも正しい署名を作れる。
+ガードの 1 行を消して確かめると、**空文字の署名で 200** が返った。
+
+## なぜ起きたか
+「たまたま失敗するはず」を守りとして数えた。
+
+## どう直したか
+秘密を `string | null` で持ち、ミドルウェアの最初の文で `if (!secret) return 401`。
+受信検証に使う他の鍵は、未設定なら起動時に落ちる `requireEnv` にそろえた。
+
+## 点検で見ること
+- 03 の F1。`?? ""` の grep は 30 件出て危険なのは 1 件だった → **受信の検証に使っているか**で切り分ける
+- 再現: このパッケージの `examples/hmac-empty.mjs`

package/skill/incidents/logging-forensics/webhook-body-console-log-pii.md

@@ -0,0 +1,23 @@
+# Webhook の受信ボディ（署名者のメール入り）を console.log でそのまま出力し、マスクを迂回していた
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | 電子契約サービスからの Webhook 受信口 |
+| 種別 | インシデント相当（本番ログに個人情報） |
+| 重大度 | LOW〜MEDIUM |
+| 見つけ方 | 定期のセキュリティ監査 |
+| キーワード | ログ, 個人情報, console.log, redact, Webhook, logger |
+
+## 何が起きたか
+`console.log("Webhook Body:", JSON.stringify(body))` で、署名者のメールを含むペイロード全体を出力していた。
+同じ種類の他のルートは共通の logger 経由で、`redact` がメールを自動でマスクしていた。
+
+## なぜ起きたか
+logger を import しない 1 ファイルだけがマスクを迂回した。`JSON.stringify` した後の文字列には、キー名で判定するマスクも効かない。
+
+## どう直したか
+共通の logger 経由に統一し、オブジェクトのまま渡す。
+
+## 点検で見ること
+- 03 の L1。**ログは攻撃の証拠であると同時に漏えい元にもなる**。セキュリティイベントログを足す提案（04 §4-3 ⑤）でも redact を通す

package/skill/incidents/process/break-guard-to-see-red.md

@@ -0,0 +1,22 @@
+# 認可のテストで RED を見るためにガードを if (true) に壊し、そのまま残りかけた
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | BFF の認可ミドルウェア |
+| 種別 | ヒヤリハット（自動レビューが CRITICAL として検出） |
+| 重大度 | HIGH（残れば認可が全開） |
+| 見つけ方 | 自動レビュー |
+| キーワード | RED, テスト, if (true), 認可, 受入基準, AI エージェント |
+
+## 何が起きたか
+AI エージェントへ渡した受入基準の「実装を壊して RED を見る」を、エージェントが認可の判定そのものを `if (true)` に書き換えることで満たした。
+
+## なぜ起きたか
+「壊して赤を見る」を、認証・認可のファイルにも同じように当てた。
+
+## どう直したか
+認可のテストは、入力（セッション・トークン・ヘッダ）をモックで変えて RED を見る。受入基準にその 1 行を足す。コミット前に `grep -rc 'if (true)'` が 0 であることを確かめる。
+
+## 点検で見ること
+- 03 の T1。コードを直す段になったら、作業者への仕様にこの 1 行を入れる

package/skill/incidents/unauth-route/internal-route-and-subpath-bypass.md

@@ -0,0 +1,32 @@
+# 「サーバー間だから認証不要」の口と、サブパスに掛からない認証で、連番の予約番号から氏名が引けた
+
+| 項目 | 値 |
+|---|---|
+| 組織 | 自社（匿名化） |
+| システム | 管理・顧客向けの BFF（Hono・Cloud Run・ingress は公開） |
+| 種別 | インシデント相当（本番コードに存在。検証環境で到達を実測） |
+| 重大度 | HIGH（認証なしで氏名を順に引ける形） |
+| 見つけ方 | 認証の棚卸し（全 endpoint に展開）＋ OpenAPI の記述との突き合わせ |
+| キーワード | ingress, internal, app.use, bare パス, サブパス, 影の経路, 連番, 棚卸し |
+
+## 何が起きたか
+1. 「サーバー間通信。認証不要」とコメントされた `*-internal` のマウントに `app.use` が 1 行も無かった。
+   検証環境で空の JSON を送ると **400**（handler まで届いている）。対照で、存在しないパスは 404、認証のある口は 401。
+2. `app.use("/api/visit-logs", 認証)` だけで `/api/visit-logs/*` が無く、`/lookup` などのサブパスが素通りした（bare は 401、`/lookup` は 400）。
+   公開 API から取れる ID と**連番の**予約番号で、予約 1 件（氏名を含む）を返す口だった。
+3. 同じハンドラを 2 か所にマウントしたことで、認証の掛からない「影の経路」ができていた（同じ型の 1 度目）。
+4. サブパスの欠落は OpenAPI に「実装のまま記載」と書かれていた。**気づいていた人がいたのに直っていなかった**。
+
+## なぜ起きたか
+- ingress が公開なのに、「内部用」という願望を前提にした
+- Hono の `app.use("/x")` は `/x` にしか掛からず、`/x/lookup` には掛からない
+- 棚卸しを `app.route(` の数で数え、さらに自前のパーサが型注釈の `{` を誤認して 30 本以上を見落とした
+
+## どう直したか
+- bare と `/*` の 2 行に統一し、マウントごとのテストで「鍵なし 401／鍵あり 非 401」を固定
+- 全 endpoint を展開して認証の有無を照合する検査スクリプトを CI に入れた。ルートが 1 本も取れないマウントは検査自体を落とす
+- 実測: endpoint 162 本・認証あり 139・無し 23（意図的 17・塞ぐべき 6）
+
+## 点検で見ること
+- 03 の A1・A2・A4。02 §2-3 の数え方（全 endpoint に展開→別の資料と突き合わせ）
+- 再現: このパッケージの `examples/hono-mount.mjs`

package/skill/procedure/01-scope.md

@@ -0,0 +1,17 @@
+# 01. 範囲と前提
+
+## 対象を確かめる
+- リポジトリの場所・リモート・ブランチを `git -C <repo> remote -v` / `git -C <repo> branch --show-current` で実測する（推測で書かない）。
+- 本番と検証環境のクラウドのプロジェクト ID は、Terraform の変数ファイル（`*.tfvars` の `project_id` など）から取る。
+- worktree（`git worktree list`）は対象から外す。同じコードを 2 回数えることになる。
+
+## 先に読む（そのリポジトリの前提・過去事故）
+- `AGENTS.md` / `CLAUDE.md`（ルートと `src/` `infra/` `supabase/` などの配下）
+- `.claude/rules/` などのルール文書のうち、認証・M2M・公開エンドポイント・DB 権限・ログ・測り方の罠に関するもの
+- チームのヒヤリハット記録があれば、点検する機能の語で grep する
+- このスキルの `incidents/INDEX.md`
+
+## 範囲外にすること（報告に書いておく）
+- `.env*` は開かない（秘密）。開いていないことを報告に書く。
+- 各 route の全数精読をしていないなら「全数は未確認」と書く。
+- 本番への書き込みを伴う確認（実際に攻撃してみる等）はしない。到達性は検証環境で確かめる。

package/skill/procedure/02-surface-map.md

@@ -0,0 +1,35 @@
+# 02. 構成と外部公開面の地図
+
+目的は「どこから入れるか」を一枚にすること。脆弱性探しはまだしない。
+例は Google Cloud（Cloud Run）＋ Terraform。他のクラウドでも見る観点は同じです。
+
+## 2-1. インフラ（Terraform を読む＋本番で確かめる）
+| 見るもの | 場所の例 | 意味 |
+|---|---|---|
+| Cloud Run の `ingress` | `infra/cloud_run*.tf` | `INGRESS_TRAFFIC_ALL` ＝インターネットから直接届く。**「サーバー間だから認証不要」は成立しない**（incidents/unauth-route/） |
+| `allUsers` の `roles/run.invoker` | IAM の定義 | 付いていれば認証は全部アプリ層の責任 |
+| Scheduler / Tasks の OIDC | `cloud_scheduler.tf` `cloud_tasks.tf` | audience とサービスアカウント。アプリ側で検証しているかは別に見る |
+| CI のデプロイ権限（Workload Identity 等） | `workload_identity.tf` | リポジトリ・ブランチ条件、デプロイ用の権限がプロジェクト全体に付いていないか |
+| Secret の一覧と配り先 | `secrets.tf` と各サービスの `secret_key_ref` | 名前だけ控える。**同じ鍵が何サービスに配られているか**（共用の鍵は漏れたときの範囲が広い） |
+| 前段（WAF/CDN） | `dig +short <host>` / `curl -sI https://<host>` の `server` ヘッダ | クラウドのフロントに直結していれば WAF は無い |
+
+## 2-2. 認証の入口を種類で分ける
+1. 人（管理者）: どの IdP・どのドメイン制限・どこで判定しているか（middleware / proxy / route 内 / RLS）
+2. 人（顧客）: OTP・ソーシャルログイン・LINE LIFF など。トークンを誰がどう検証するか（audience / client_id の照合）
+3. M2M: 共有キーか署名か OIDC か。**actor（誰の代理か）は自己申告か検証済みか**
+4. Webhook: 署名 / トークン / IP 制限のどれか。**鍵が未設定のときの挙動**
+5. ジョブ: OIDC をアプリで検証しているか、IAM だけか
+6. 開発用の抜け道（`NODE_ENV === "development"` のときだけ通るトークン等）が本番で閉じているか
+
+## 2-3. 公開エンドポイントの棚卸し
+- Next.js: `src/app/**/api/**/route.ts` を全列挙し、`middleware.ts` / `proxy.ts` の公開パターン・matcher と突き合わせる。
+  **前方一致の公開パターン**は配下の将来のルートまで無認証にする。
+- Hono 等: `app.route(` の数で数えない。**全 endpoint に展開してから** middleware のパターンと 1 本ずつ照合する
+  （`app.use("/x")` と `app.use("/x/*")` は別。マウント側のファイルや factory 内の `route.use` も見る）。
+- 無認証で残すものは「ルート内で何を検証しているか」を 1 行で書けるかで判定する。
+- 自分の棚卸しを**別の資料（OpenAPI の記述等）と突き合わせて**検証する。自前の検査スクリプトは型注釈の `{` などで取りこぼす。
+
+## 2-4. DB
+- RLS の使い方（テナント分離か、特権ロール以外の締め出しだけか）
+- 特権クライアント（Supabase の service_role 等）の生成箇所。正規のヘルパー以外の**直書き**も grep する
+- `SECURITY DEFINER` 関数の anon 実行可否（Supabase は `REVOKE ... FROM PUBLIC` だけでは anon が残る）

package/skill/procedure/03-auth-checklist.md

@@ -0,0 +1,29 @@
+# 03. 認証・認可の観点表
+
+右端に事例があるものは、**実際に起きた事例**から作った観点です。事例を開くと、何が起きたか・どう見つけたかが分かります。
+新しい事例を足したら、ここにも観点を 1 行足す。
+
+| # | 観点 | 確かめ方 | 事例 |
+|---|---|---|---|
+| A1 | ingress が公開なのに「内部用だから」と認証の無いルートが無いか | 公開ルートの棚卸し（02 §2-3）で「内部」「internal」「サーバー間」を grep | unauth-route/internal-route-and-subpath-bypass |
+| A2 | ミドルウェアが bare パスだけに掛かり、サブパスが素通りしていないか（Hono は `/x` と `/x/*` の 2 行） | `app.use(` と `app.route(` を対で照合 | 同上 |
+| A3 | 公開判定が前方一致で、将来のサブルートまで無認証になっていないか | 公開パターン（`startsWith` で判定している配列など）を列挙し、配下の route 全部に自前の認証があるか | （観点のみ） |
+| A4 | 同じハンドラを 2 か所にマウントして「影の経路」ができていないか | 同じ factory を複数の path で `route` していないか | unauth-route/internal-route-and-subpath-bypass |
+| F1 | 受信検証の鍵・許可リスト・client_id が**未設定のときに通る**作りになっていないか（`?? ""`、`if (cfg && ...)`） | `grep -rnE '(SECRET\|TOKEN\|KEY\|CHANNEL_ID)[^\n]*\?\? ""'` と `if \(options\?\.` を、**受信の検証に使っているもの**に絞る | fail-open/webhook-hmac-empty-secret, fail-open/idp-client-id-unset |
+| F2 | レート制限・外部判定が障害時に fail-open で、公開 OTP 等の守りが外れないか | レート制限の実装の catch 節 | （観点のみ） |
+| Z1 | 他エンティティの ID を受け取る書込 API が、**ID の有無に関わらず**所有権チェックを先頭で通すか | body から `*.id` を受ける route を列挙し、検証が `if (!id)` 分岐の中だけにないか | authz-idor/ownership-check-inside-branch |
+| Z2 | 認可テーブルを別アプリの配線からコピーしていないか（同じ形の名前 `*_admins` でも役割が違う） | アプリごとの管理者テーブルの役割表と、API 側の照合先を突き合わせる | authz-idor/copied-admin-wiring |
+| Z3 | fail-closed の照合を足すとき、照合先テーブルが空でないか・埋める手段があるか（人と bot で基準が食い違わないか） | 本番の件数（`count(*)` のみ） | authz-idor/fail-closed-on-empty-admin-table |
+| Z4 | M2M の共有鍵が何サービスで共用されているか・actor が自己申告か | Secret の配り先表（02 §2-1） | （観点のみ） |
+| D1 | 状態を変える `SECURITY DEFINER` 関数が anon/authenticated に開いていないか（`FROM PUBLIC` だけでは anon が残る） | `has_function_privilege('anon', oid, 'EXECUTE')` を本番で**読み取りで**数える | db-privileges/security-definer-open-to-anon |
+| C1 | 顧客の画面（LIFF 等）から、利用者の権限で外部へ送信・投稿していないか | 送信 API の呼び出し・ラッパの存在を grep | client-side-action/liff-send-posts-to-wrong-chat |
+| E1 | 登録の有無を返す公開 API に per-IP + per-email のレート制限があるか（reCAPTCHA だけにしない） | 公開の auth 系 route ごとに「レート制限・失敗ログ・障害時の挙動」を表にする | （観点のみ） |
+| L1 | Webhook・外部 API のログが redact を通っているか（`console.*` 直呼びで個人情報を生出力していないか） | `console\.(log\|error)` を webhook / 外部クライアント配下で grep | logging-forensics/webhook-body-console-log-pii |
+| T1 | 認可のテストで RED を見るとき、ガード自体を `if (true)` 等に壊していないか | `grep -rc 'if (true)'` = 0 を確認 | process/break-guard-to-see-red |
+
+## 外部の事件から来た観点
+| # | 観点 | 事例 |
+|---|---|---|
+| X1 | パス操作（`../`）でサーバ上のファイルを返す口が無いか（ファイル名・パスを受け取って読む/配信するルート） | external/2026-10-arcadia-traversal-config-secret |
+| X2 | 設定ファイル・リポジトリ・ビルド成果物にサービス間の鍵が平文で入っていないか（一つ漏れると横に広がる） | 同上 |
+| X3 | DB の異常負荷より前に、探索（404 の山）やログイン連打で気づけるか | 同上 → 04 の検知 |

package/skill/procedure/04-forensics-readiness.md

@@ -0,0 +1,51 @@
+# 04. 攻撃者の行動をログで追えるか
+
+「事件が起きたとき、何時・どこから・何をされたかを分単位で並べられるか」を点検する。
+手本: external/2026-10-arcadia-traversal-config-secret（公表資料が分単位の時系列を出している）。
+コマンドは Google Cloud（Cloud Run ＋ Cloud Logging）の例です。
+
+## 4-1. 測るコマンド（すべて読み取り。`--account` を毎回付ける）
+```bash
+A=<your-account@example.com>; P=<project_id>
+gcloud logging buckets list --project=$P --account=$A --format="table(name.basename(),retentionDays,locked)"
+gcloud logging sinks list   --project=$P --account=$A --format="table(name,destination,filter)"
+gcloud logging sinks describe _Default --project=$P --account=$A --format="value(exclusions[].name)"
+gcloud projects get-iam-policy $P --account=$A --format=json \
+  | python3 -c "import json,sys;print(json.load(sys.stdin).get('auditConfigs','(none)'))"
+# ステータス別件数（値は出さない）
+gcloud logging read 'logName:"run.googleapis.com%2Frequests"' --project=$P --account=$A --freshness=24h --limit=20000 \
+  --format="value(httpRequest.status)" | awk '{c[substr($1,1,1)"xx"]++;n++}END{for(k in c)print k,c[k];print "total",n}'
+# 1 件のフィールド名だけ
+gcloud logging read 'logName:"run.googleapis.com%2Frequests"' --project=$P --account=$A --freshness=24h --limit=1 --format=json \
+  | python3 -c "import json,sys;e=json.load(sys.stdin)[0];print(sorted(e.get('httpRequest',{}).keys()))"
+# 最古のログ（＝実効の保存期間）
+gcloud logging read 'logName:"run.googleapis.com%2Frequests"' --project=$P --account=$A --freshness=400d --order=asc --limit=1 --format="value(timestamp)"
+```
+- `gcloud logging exclusions` というサブコマンドは無い（Google Cloud SDK 583.0.0 で実測）。除外は `_Default` sink の `exclusions` で見る。
+- 件数が `--limit` に達したら「打ち切り」と書く。
+- **2xx が 4xx より少ない**ときは、成功ログを除外・サンプリングしていないかを `sinks describe` で確かめる。
+
+## 4-2. 判定表（各行を 追える / 一部 / 追えない で埋める）
+| 攻撃者の行動 | 残る場所 | 追えない典型原因 |
+|---|---|---|
+| パス探索（404 の山） | リクエストログ | 保存期間切れ |
+| トラバーサル・SQLi の試行 | リクエストログの URL（クエリ含む） | POST 本文は残らない |
+| ログイン連打 | リクエストログ（4xx）＋ IdP 側ログ | 狙われたアカウントは本文に入るので残らない |
+| **攻撃が成功した瞬間（2xx）** | リクエストログ | **コスト対策で 2xx を除外・サンプリングしている** |
+| ログイン後に見た・持ち出した | アプリの構造化ログ（userId 付き）・DB 監査 | アクセスログにユーザー ID が無い |
+| 盗んだ鍵の使用 | リクエストログ＋M2M の呼び出し元ログ | 共用鍵だと正規の呼び出しと区別できない |
+| 秘密を誰が読んだか | Data Access 監査ログ | `auditConfigs` が無い＝無効 |
+| 設定変更・デプロイ・IAM 変更 | Admin Activity 監査ログ（`_Required` バケット・400 日・ロック済み） | -- |
+| 攻撃中に気づく | ログベース指標＋アラート | 5xx しか見ていない |
+| 1 か月以上前 | 長期保管（別プロジェクトの BigQuery/GCS） | `_Default` バケットの既定 30 日のみ |
+| 証拠を消されない | ロック済みバケット・別プロジェクト | 同じプロジェクト内・未ロック |
+
+## 4-3. 対策の優先度（目安。プロジェクトごとに見直す）
+1. 2xx を含むリクエストログを全部残す（除外をやめる、または捨てずに安い保存先へ回す）
+2. 1 年以上・別プロジェクト・保存期間ロック（BigQuery なら IP 単位の時系列が SQL 一本で出る）
+3. Data Access 監査ログ（Secret Manager・IAM）
+4. 検知アラート（同じ IP の 4xx 急増／ログイン失敗の連打／1 ユーザーの異常な 200 件数／管理者権限の付与／秘密の読み取り）
+5. アプリのセキュリティイベントログ（認証の成否・権限付与・401/403・レート制限・M2M の呼び出し元・一括出力。userId・role・IP・trace ID 付き。redact を通す）
+6. DB 側の記録（マネージド DB のプラン別の保存期間・pgaudit 等）
+7. 前段の WAF（ロードバランサ＋Cloud Armor、Cloudflare 等）
+8. 「疑わしい IP の時系列を出す」クエリを手順書に保存しておく

package/skill/procedure/05-report.md

@@ -0,0 +1,16 @@
+# 05. 報告の型
+
+1. **結論 1〜3 行**（できる／できない、いちばん大きな穴）
+2. 手本の事件の各段階 × 自社システムの表（追える／一部／追えない）
+3. 実測した事実の表（プロジェクト別・数値・日時）
+4. 穴の一覧（# / 穴 / 根拠ラベル `実測`・`コード上`・`未確認` / 何が困るか）
+5. 対策（優先度・何が残るようになるか・手間と費用の目安。見積もっていなければそう書く）
+6. 気になった点（疑問の段階。断定しない）
+7. 次の一手（候補を 2〜3）
+8. 調査方法と、やっていないこと（編集なし・`.env` 未読・全数は未確認 など）
+
+## 出し先
+- まず会話の中で文章として返す。メモに残すならリポジトリの外（チームに共有されない場所）に置く。
+- HTML や共有ページにするなら、作る**前に**公開範囲を決める（SKILL.md §0-5）。
+- 読み手が知らなそうな概念（ingress・OIDC・RLS・fail-open 等）は、初出で 1 行説明する。
+- 新しく分かった事例は incidents/ に足してから報告を閉じる。