AI コーディング支援が提案したパッケージを承認するとき、名前と用途の確認だけでは足りません。
導入するファイルの確認に加え、そのファイルを実行するプロセスが、どの認証情報と社内資産にアクセスできるかも点検する必要があります。
Mandiant の「AI risk and resilience」（2026 年 9 月版）には、AI 支援セッションの悪用を起点として、開発端末から社内へ侵害が広がった事例が掲載されています。
この記事では Case study 1 をもとに、開発環境を点検する項目を整理します。
報告された侵害の流れ
Mandiant は、SaaS 事業者への侵入を調査する中で、開発端末上の稼働中の AI コーディング支援セッションが乗っ取られた事例を確認したと報告しています。
支援ツールは攻撃者が汚染した外部パッケージの導入を勧め、その提案が受け入れられました。
報告によると、攻撃者は汚染した PyPI パッケージを通じて情報窃取用のマルウェアを導入し、GitHub の OAuth トークンを窃取しました。
続いて、約 100 の社内コードリポジトリに自己増殖型の Shai-Hulud ワームを展開し、リポジトリ内の秘密情報や製品ソースコードを窃取したとされています。
さらに、組織の公式名前空間内のパッケージも汚染され、別の従業員がその版を取得して二次感染したと記載されています。
これは報告内容を整理した概念図で、再現実験の結果ではありません。
Case study 1 の記述からは、セッションを乗っ取った具体的手法、被害組織名、侵入日時は確認できません。
特定製品の脆弱性や、プロンプトインジェクションが初期侵入の手法だったと断定できる事例でもありません。
導入前に確認する対象
Mandiant は対策として、AI が推奨する依存関係を承認済みリストと暗号学的チェックサムで照合すること、ローカル認証情報を隔離すること、依存関係の取得経路を管理された内部リポジトリへ集約することを挙げています。
これを開発環境の運用へ落とし込むなら、次の情報を承認対象に含められます。
| 対象 | 記録する内容 | 確認したことにならない例 |
|---|---|---|
| パッケージの識別 | レジストリ、名前空間、パッケージ名、版、配布ファイル | AI が説明した用途だけを読む |
| 配布元の確認 | 公式文書からたどった配布先、保守元、承認記録 | 検索順位やダウンロード数だけで判断する |
| ファイルの照合 | 承認済み成果物のハッシュと、実際に取得するファイルのハッシュ | 取得したファイルのハッシュを初めて計算し、それだけで安全とする |
| 依存関係の変更 | 直接依存だけでなく、追加や更新される間接依存 | 最上位のパッケージ名だけを承認する |
| 実行する処理 | インストール、ビルド、初回起動で動く処理とその権限 | インストールが終わるまでコードは動かないと仮定する |
ハッシュ照合で確認できるのは、ファイルが照合元と一致することです。
一致していても、照合元のファイル自体が悪意ある内容なら、安全性の証明にはなりません。
信頼できる経路で取得し、承認した成果物のハッシュを管理することと、その値を照合することを分けて考えます。
内部リポジトリも、置くだけで安全になるわけではありません。
外部から取得したものを無審査で中継すれば、未承認のパッケージも同じ経路を通ります。
利用側の取得先を制限するとともに、内部へ取り込む際の審査、公開権限、版の変更履歴を管理する設計が必要です。
今回の事例でも組織名義のパッケージが汚染されており、「社内の名前空間だから安全」とは判断できません。
実行環境へ渡す認証情報
パッケージが実行された後の被害範囲は、実行環境から利用できる権限にも左右されます。
依存関係の調査用環境へ、本番操作やパッケージ公開に使う認証情報まで渡す必要があるかを見直します。
| 点検する対象 | 確認する問い | 制限の例 |
|---|---|---|
| 環境変数と認証情報ファイル | 子プロセスや拡張機能から読めるか | 検証に不要な秘密情報を注入、配置、マウントしない |
| 認証エージェントや資格情報ヘルパー | 秘密値を読めなくても、認証機能を呼び出せるか | 検証環境へ不要な認証ソケットやホスト機能を渡さない |
| リポジトリへの権限 | 読み取りだけで足りる作業に、書き込みや管理権限がないか | 対象リポジトリと操作を限定する |
| パッケージ公開権限 | 開発端末の認証情報で組織名義の版を公開できるか | 検証環境とリリース用の権限を分離する |
| 認証情報の有効期間 | 失効方法と利用記録を追えるか | 対応する認証方式では短命化し、失効手順も確認する |
秘密値をファイルから消しても、環境変数や認証ヘルパー経由で同じ権限を使えるなら、隔離は完了していません。
また、コンテナを使っていても、ホストの認証情報や強い権限を持つソケットを渡していれば、その経路を点検する必要があります。
短命なトークンも、有効期間中の不正利用を防ぐ保証にはなりません。
有効期間、対象資産、許可する操作、外向き通信を組み合わせて制限します。
必要な接続まで一律に遮断すると開発作業に影響するため、まず依存関係の取得先と業務上の通信先を棚卸しします。
秘密情報を使わない確認試験
隔離を確かめる試験では、本番トークンを置いて「読めるか」を試す必要はありません。
検証用環境に非機密のダミーファイルと専用のテスト用アカウントを用意し、意図した制限が働くかを確認します。
以下は試験案であり、実施済みの結果ではありません。
- 利用予定の実行経路から、許可していないダミーファイルを読めないことを確認する。
- テスト用アカウントで、許可した資産の読み取りは成功し、許可していない書き込みは拒否されることを確認する。
- 管理されたパッケージ取得先は使え、迂回先として用意した検証用エンドポイントへの通信は拒否されることを確認する。
- テスト用の認証情報を失効させ、再利用できないことと、操作記録を追えることを確認する。
試験結果には、実行主体、対象、期待結果、実際の結果を残します。
秘密値を含む環境変数の一覧や認証ファイルの中身を、ログや記事へ貼り付ける必要はありません。
導入の承認手順には、パッケージ名だけでなく「何を取得し、どの環境で、どの権限を使って実行するか」を含められます。
AI の提案を確認する人の注意力だけに依存せず、誤った承認があっても本番や配布基盤へ届きにくい構成を用意するためです。
参考資料
- Mandiant: AI risk and resilience, September 2026 の Case study 1 と Defensive controls