AI時代のソフトウェア供給網防衛, OIDC認証とコードスキャン是正フローの実装ガイド
GitHubの4月更新では、DependabotとCode scanningが組織レベル私設レジストリへのOIDC認証に対応し、code scanning alertのIssue連携、SBOM出力の非同期化も進みました。国内でも「npm installは任意コード実行に近い」という議論が再燃し、サプライチェーン対策は“理想論”ではなく運用課題になっています。
参考: https://github.blog/changelog/month/04-2026/, https://www.publickey1.jp/blog/26/npm_install_trivyaxios.html, https://zenn.dev/feed。
前提転換, 侵入ゼロは目標ではなく幻想
現代のCI/CDでは、依存解決やビルド時点で外部コードを恒常的に実行します。重要なのは「侵入をゼロにする」より「侵入後の検知と封じ込めを何分で回せるか」です。
OIDCで長期シークレット依存を断つ
まだ多くの現場で、レジストリアクセスに長期トークンを使っています。これが漏れると横展開されやすく、痕跡も不鮮明です。
OIDC運用の基本:
- CIジョブが短命トークンを要求
- レジストリはワークロードIDを検証
- パッケージ範囲と操作権限を最小化
- 数分で失効
結果として、秘密情報管理より「信頼できる実行主体管理」に重心を移せます。
検知を「アラート箱」から「是正フロー」に変える
コードスキャンアラートが放置される最大要因は、開発計画と分離されていることです。Issue連携を前提化し、SLAを埋め込みます。
推奨項目:
alert_idexploitabilityservice_criticalitytarget_fix_dateowner_team
これでセキュリティ対応が、属人タスクではなく追跡可能な開発作業になります。
依存関係を信頼ゾーンで分離する
- ゾーン1: 社内監査済み依存
- ゾーン2: 外部許可リスト依存
- ゾーン3: 原則禁止（例外申請のみ）
新規依存がゾーン境界を越える場合は、CIで失敗させる設計にします。人手レビューだけに頼ると、リリース圧に負けます。
SBOMを「出す」から「比較して止める」へ
非同期SBOMは、レポート用途だけでは価値が小さいです。
- リリース候補生成時にSBOM作成
- アーティファクトハッシュを紐付け
- 前回との差分判定
- 高リスク未知成分があればデプロイ停止
この流れで、証跡が実際のリリース判定に効きます。
侵入後封じ込めの実装
- build/runtimeの外向き通信許可先を分離
- 一時的filesystemを使うビルド実行基盤
- build/test/deployで資格情報を分割
- 異常外向き通信の監視
検知だけ強くても封じ込めが弱いと、実害コストは下がりません。
45日実装ロードマップ
- 1〜15日: 認証棚卸し, 未使用トークン廃止, OIDC信頼ポリシー整備
- 16〜30日: 高優先アラートのIssue化必須化, 依存ゾーン定義, SBOM差分開始
- 31〜45日: ゾーン越境ブロックをCI強制, 悪性依存を想定した演習, MTTD/MTTC可視化
まとめ
サプライチェーン防衛は、道具を増やすことではなく、ID・検知・是正・証跡を一本の運用線にすることです。OIDC, Issue連携, SBOM差分を接続できれば、AI時代でも現実的な防御力を作れます。
