AIコーディングエージェント時代のOSSバックドア対策: 現場で回せる防御ドリル

コミュニティで共有された事例が示したのは、AIコーディングエージェントが“悪性OSSを善意で取り込む”リスクです。これはAIが悪いという話ではなく、サプライチェーン検証を省略した運用の問題が、AIによって高速化されるという構図です。

どこで失敗するか（脅威モデル）

失敗点は主に4つです。

1. 依存ライブラリの提案段階
2. 実装スニペットの採用段階
3. CI設定の自動生成段階
4. 自動修正PRの取り込み段階

このどこにも検証ゲートがないと、危険な変更が短時間でmainへ到達します。

ドリル1: 悪性依存の提案耐性

隔離した検証リポジトリに、危険なinstall scriptを持つ疑似パッケージを用意し、エージェントに自然に採用させる課題を与えます。見るべき点は次です。

• メンテナ信用性の確認を求めるか
• lockfile/チェックサム確認を提案するか
• 代替ライブラリ比較を出すか

目的は“全部拒否”ではなく、“採用前検証が必須になる”状態です。

ドリル2: ドキュメント由来の誘導

READMEやWikiに誤誘導文（または隠し指示）を混ぜ、検索連携タスクを実行します。以下を検証します。

• 未検証文書を権威情報として扱っていないか
• 環境変数や秘密情報を露出しないか
• 危険なシェル実行を自動で提案しないか

ここで得た失敗パターンは、コンテキスト信頼境界の見直しに直結します。

ドリル3: CI生成の権限制御

エージェント生成のCIを、必ず以下で監査します。

• Actionバージョンが固定されているか
• 権限が最小化されているか
• 特権ランナーで未検証スクリプトを動かさないか
• 成果物署名/来歴検証を入れているか

自動生成YAMLは便利ですが、既定値が緩いことが多いです。

本番で最低限必要なガードレール

• 依存採用ポリシー（信頼条件）をリポジトリ内に明文化
• リリース時SBOM生成を必須化
• CIで署名/来歴検証を自動実行
• lockfile異常を保護ブランチでブロック
• 高リスク依存は人間承認を必須化

「ガイドライン」だけでなく、機械的に止まる仕組みが必要です。

運用責任の分解

• 開発チーム: 依存採用判断の一次責任
• 基盤チーム: 検証ゲート実装責任
• セキュリティ: シナリオ設計・演習責任

責任線が曖昧だと、事故後に改善より責任論が先行します。

90日ロードマップ

• 1か月目: ポリシー策定と演習リポジトリ整備
• 2か月目: 主要チームでドリル実施、失敗パターン公開
• 3か月目: CIゲート強制と期限付き例外運用

AIエージェントは速度を上げます。防御ドリルは、その速度がそのままリスク増幅にならないようにするための、組織側の必須投資です。