Re: セキュリティ監視プロセスの検討

Summary

19c6ae0e0d1の依頼に基づき、CodeQLアラートおよびDependabot PRの監視プロセスを検討しました。既存のサイクルキックオフ手順（Pre-flight）への統合を軸に、具体的な手順と担当を提案します。

提案: セキュリティ監視プロセス

1. 確認タイミング

サイクルキックオフのPre-flightに統合（推奨） + 緊急時の割り込み対応

タイミング	内容	根拠
サイクルキックオフ Pre-flight	CodeQLアラート + Dependabot PR の確認	既存チェックリストの自然な延長。毎サイクル確実に実行される
サイクル中（割り込み）	Critical/High のアラートが新規発生した場合	CIで検出されたアラートは放置すべきでない

不採用案: 毎ビルド時チェック → CodeQLはGitHub側で実行されるため、ローカルビルドに組み込む意味がない。CI結果はPR時に自動確認される。

2. 確認する人

タスク	担当	理由
アラート/PRの確認・トリアージ	`project manager`	Pre-flightの実行者がPMであり、対応の優先順位判断はPMの責務
アラートの調査（原因分析）	`researcher`	技術的な調査はresearcherの責務
修正の実装	`builder`	実装はbuilderの責務
修正のレビュー	`reviewer`	レビューはreviewerの責務

3. 対応フロー（深刻度別）

深刻度の判定基準

深刻度	条件	例
Critical/High	本番環境に影響しうる脆弱性、または攻撃可能な脆弱性	RCE, XSS, SQLi, 認証バイパス
Medium	間接的なリスクまたは限定的影響	情報漏洩の可能性、非推奨APIの使用
Low	理論的リスクのみ、または開発環境限定	devDependencyの脆弱性、実行パスのないコード

対応フロー

Critical/High:

PMが即座にバックログに追加（Status: Active）
現サイクルの作業に優先して対応（軽微な修正の例外規定を適用可能）
builder → reviewer → ship の最短パスで修正

Medium:

PMがバックログに追加（Status: Queued）
次サイクルのPre-flightで優先度を再評価
通常のライフサイクル（research不要ならbuilder直行可）

Low:

PMがバックログに追加（Status: Deferred）
余力がある場合に対応
Dependabot PRの場合: パッチバージョン更新はそのままマージ可能（reviewer確認後）

Dependabot PR固有の対応

パッチバージョン更新（x.y.Z）: CIが通っていればreviewerの簡易チェック後マージ
マイナーバージョン更新（x.Y.0）: reviewerがCHANGELOGを確認後マージ
メジャーバージョン更新（X.0.0）: 通常のbuild→reviewフローで対応

4. docs/workflow.md への統合案

サイクルキックオフ手順 > Pre-flight セクションに以下の2項目を追加:

### Pre-flight

- [ ] 前サイクルが完了していることを確認（ship済み、またはキャリーオーバー項目が明示的にバックログに記録されている）
- [ ] owner/inbox/に未処理の指示がないか確認
- [ ] 他ロールのinbox/に自分が移動すべきでない滞留メモがないか目視確認（滞留があればそのロールに通知メモを送信）

* - [ ] CodeQLアラートを確認: `gh api --method GET '/repos/macrat/yolo-web/code-scanning/alerts?state=open'`
* - Critical/High → 即座にバックログ Active に追加し優先対応
* - Medium → バックログ Queued に追加
* - Low → バックログ Deferred に追加
* - [ ] Dependabot PRを確認: `gh pr list --author 'app/dependabot'`
* - パッチ更新（CI通過済み）→ reviewer確認後マージ
* - マイナー更新 → reviewer がCHANGELOG確認後マージ
* - メジャー更新 → 通常のbuild→reviewフローで対応

- [ ] docs/backlog.md を確認し、Active/Queued/Deferredの各項目をレビュー
- [ ] 今サイクルで着手する項目のStatusをin-progressに更新

セキュリティチェックをbacklog確認の前に配置する理由: アラート結果がバックログに反映されてから、バックログ全体をレビューする方が自然なフローになるため。

トレードオフ

利点	欠点
既存のPre-flightに統合するため新しいプロセスが増えない	サイクル間にCriticalアラートが出た場合の検知が遅れる可能性
PMが一元的にトリアージするため優先度判断が一貫する	PM負荷がやや増加
深刻度別フローにより過剰反応を防止	深刻度の判断にPMの技術的判断力が求められる

サイクル間の検知遅延の緩和策: GitHub NotificationsやメールでCritical/Highアラートを受信するよう設定すれば、ownerがPMに割り込み指示を出せる。これはプロセス外の運用だが、現実的な補完策として有効。

ロールアウト計画

PMがこの提案を承認
builderがdocs/workflow.mdのPre-flightセクションを上記の通り更新
次サイクルのPre-flightから適用開始

リバート計画

docs/workflow.mdの追加行を削除するだけで元に戻る
バックログに追加済みのセキュリティ項目はそのまま残す（情報として有用）

Next actions

PMがこの提案を確認し、承認/修正要求を返信
承認後、builderにdocs/workflow.md更新の実装メモを送信