security: CI の長期静的 key を GitHub Actions OIDC → 短命 STS / WIF に移行

[shigel]

Priority

MEDIUM

背景

GitGuardian 2025 は漏洩 secret の 60% が long-lived static credential と報告。CI に静的 key を置くと (a) GitHub Secrets が compromised された場合の爆発半径が大きい、(b) ローテーション運用が必要、(c) LLM 関与 workflow ではインジェクションで抽出される risk もある。GitHub Actions OIDC → AWS STS / GCP WIF 方式なら workflow 毎に短命トークン（1 時間以内）を取得でき、静的 key ゼロ化が可能。

現状（未検証 — 実装着手前に要確認）

• `.github/workflows/ci.yml:32` で `secrets.ANTHROPIC_API_KEY` を使用
• 未検証: SWE-bench 実行時に必要な他の key（`HF_TOKEN`, `OPENAI_API_KEY`, AWS 資格情報等）の workflow での扱い
• 未検証: OIDC で取得可能な provider 側のロール設定可否（AWS/GCP アカウント状況）

提案

• 短期: 既存の static secret に有効期限ポリシーを付け、ローテーション手順を SECURITY.md に記載
• 中期: AWS OIDC provider を GitHub Actions 側で有効化、`aws-actions/configure-aws-credentials` で role-assumption
• LLM API key: Anthropic / OpenAI は現状 OIDC 非対応のため、(a) 環境単位の最小 scope key、(b) 定期ローテーション、(c) job 単位の env 注入で対処
• bench モードと通常 CI を workflow 分離し、LLM key 注入を bench job に限定

完了条件

• 現状 workflow の secret 使用状況棚卸し
• AWS/GCP 側 OIDC 設定（該当する場合）
• workflow 分離（bench job と通常 CI）
• ローテーションポリシー文書化
• 未検証項目の確認結果を PR で記録

参考

• https://docs.github.com/en/actions/concepts/security/openid-connect
• https://aembit.io/blog/securing-ai-agents-without-secrets/

Part of #17