OSSとして公開する、小規模組織向け「調べなくても基本のセキュリティ診断を回せる」統合キットの構想。
*一言で：ツールやフレームワークの選定・つなぎ込みを済ませた状態で配り、scope → setup → 実行（リリース前/月次）→ triage を誰でもルーティンで回せるようにするOSS。
- AIエージェントで攻撃も診断も安価に自動化できる時代になった。守りを仕組みとして持つ必要がある。
- 一方で、**AIペンテスト（Strix/CAI/PentestGPT）・SAST（CodeQL/Semgrep）・標準（OWASP）・国内ガイド（IPA）は"部品"としては揃っている*が、どれがどの役割かを毎回調べ、つなぎ込むコストが高い。
- 特に小規模の非営利・自治体・シビックテックには、その調査・設計の余力がない。結果、診断が属人化するか、やらないまま放置される。
- 足りないのは新しいエンジンではなく、部品を束ねて"明日から回せる"状態にした接着剤。
部品選定を済ませたオピニオネイテッドな統合ルーティン。利用者は「どのツールを使うか」を考えず、テンプレを展開して回すだけ。
- *デフォルトの役割マッピング（役割→推奨OSS）を内蔵し、調査を不要にする。
- テンプレ＋最小CLI/Makefileで、
init一発で一式が入る。 - **日本語ドキュメント＋OWASP/IPAマッピング*で、国内実務にそのまま接続できる。
- *一次対象：CfJ自身、および近い組織まで（同規模の非営利・自治体・シビックテック）。広く一般には広げない。
- *価値：セキュリティ専門家がいなくても、基本レベルの診断を定常運用できる。
- *差別化：エンジンではなく「接着剤＋日本語＋文脈」。世界的OSS（下記）は部品で強いが、国内小規模組織向けに束ねた統合キットは空白。
やる
- 役割ごとのデフォルトツール選定とつなぎ込み
- スコーピング・実行・トリアージのテンプレと標準フロー
- 日本語の導入ガイド＋OWASP/IPAマッピング
やらない（既存に委譲）
- 診断エンジンの再実装 → Strix / CAI / CodeQL / Semgrep に委譲
- 商用SaaS化、専門家向けの高度なレッドチーム機能
- *役割マッピング表：SAST=CodeQL/Semgrep、依存=Dependabot/OSV-Scanner、シークレット=Gitleaks、AIエージェント診断=Strix（必要に応じCAI）、標準=OWASP ASVS/WSTG。
- *スコーピングテンプレ：
instructions.md生成＋脅威モデル雛形（in-scope/out-of-scope・資産・認証・除外）。OWASP ASVSを参照にFocusAreasを定型化。 - *CI/実行テンプレ：GitHub Actions（リリース前の手動＋月次schedule）。
--max-budget・scope制御込み。 - *トリアージ/起票フロー：結果→Slack通知→Notion台帳、重大度トリアージの手順。
- 最小CLI/Makefile：
initで上記一式を対象リポに展開。 - *日本語導入ガイド：IPA（ウェブ健康診断・安全なウェブサイトの作り方）とOWASPへのマッピングで実務接続。
- Scope — テンプレから
instructions.mdを作成（対象・認証・Focus・除外）。 - Setup — テスト環境（ステージング/クローン）＋キー登録＋CIテンプレ配置。
- Run — リリース前（手動）／月次（schedule）で実行。
- Triage — PoC付きを優先、誤検知を仕分け、起票→修正→再スキャン。 人間に残るのは「安全な環境用意」「スコープ決定」「結果の検証」「修正」。それ以外はテンプレとエージェントが担う。
- *AIエージェント：CAI（モジュール型・役割パターン・human oversight）、PentestGPT、Strix。→ エンジンはここに乗る。
- *方法論/標準：OWASP WSTG・ASVS・SAMM/DSOMM・pytm。→ スコープと成熟度の下敷きに使う。
- *国内：IPAのガイド/ツール群（啓発・診断手引き）、BEAR.Security（日本発OSS、思想が近い）。→ マッピング・参照先にする。
本キットの立ち位置＝これらの"上に乗る統合レイヤー"。独自エンジンは持たない。
- *ライセンス：MIT または Apache-2.0。
- *リポ構成：テンプレ／CLI／docs（日本語＋英語）。
- *既存OSSへの敬意：委譲するエンジンへは Drips 等でのOSS寄付も検討（別構想と接続）。
- *コントリビュート：自治体/シビックテック事例をテンプレとして取り込める設計。
- **v0（ドッグフーディング）*：CfJ内の1プロジェクトに手動適用し、ルーティンとテンプレを実地検証。
- v0.1：テンプレ＋最小CLI化。2〜3プロジェクトへ横展開。
- **v1（OSS公開）*：テンプレ＋日本語ガイドを作りながら公開。*CLIは実装せず、設計をADRで固める（将来実装の判断材料にする）。
- *その後：コミュニティ事例の取り込み、英語化。
保守を「人がゼロから調べ続ける」から「エージェントが監視・ドラフトし、人間は判断だけする」に変える。このキット自身のルーティン（agentが作業・人間がdecision）をドッグフーディングする構図にもなる。
- エージェントが担う（toil）*：委譲先（Strix/CAI/CodeQL/Semgrep）のリリース・changelog・CVEを監視し、カナリアリポでテンプレを実行して壊れを検知。「flagが変わった」「新ツールが出た」をPRドラフト化*。
- **人間が担う（opinion）*：推奨そのものの変更（ツール差し替え・推奨モデル変更・マッピング追加削除）はレビュー必須。ここがキットの価値＝「調べる責任の引き受け」なので自動化しない。
2段のautonomy
- *自動マージ可：カナリアを通ったバージョン上げ、flagリネーム、リンク修正などの機械的変更。
- *人間レビュー必須：推奨の変更。無レビューの自動採用は、利用者が自分で調べるより悪く（検証されない権威を配ることになる）、かつ推奨ツール/モデルの自動採用自体がサプライチェーンの侵入面になるため禁止。 結果、担当者の仕事は「ゼロから調べる」から「エージェントのPRを定期的にレビューする」に縮小。保守コストは激減するが、責任者は消えない。
- *保守コスト：委譲先（Strix/CAI等）の変化に追随し続ける必要。デフォルト選定が陳腐化しうる。
- *非決定性・コスト：エージェント型の宿命。budget/scope制御を標準に含める。
- *運用負荷：誤検知のトリアージが溜まると形骸化。起票ルールとローテを最初から組み込む。
- *"オピニオン"の責任：デフォルト選定を推す以上、推奨が外れたときの更新責任を持つ。
決定済み
- *プロジェクト名：Code for Security。
- *対象：CfJ＋近い組織まで（広く一般には広げない）。
- *v1スコープ：テンプレ＋ガイドを作り、CLIは実装せず設計をADRで固める。
- *自動化のしきい値／人間ゲートの担当：v1を作りながら決める（第10節）。
残論点
- **診断エンジンの採用方針（Strix / CAI）*：既定エンジンをStrixにして包むか、CAIを土台に独自エージェントを組むか、両対応できる薄いアダプタを挟むか。CLIの初回ADRとして扱う。