AIコーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版）

「AIコーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術」から初心者向けに内容を調整したもの
https://qiita.com/SoySoySoyB/items/ff885e6de32c8e3e09c4

Transcript

1. AI コーディング時代における、 ソフトウェアサプライチェーン攻撃に 対する防衛術（簡易版） 2026 年4 月 / D （@SoySoySoyB ）
2. 押さえてほしい3 つのこと 便利そうなものでも、信頼できるか確認してから取り入れよう 外部に流出して困るものを保持したままにしないようにしよう 何か起きたときに気づける仕組みを作ろう（これは難しいけれど） 2
3. 目次 1. 本スライドの位置づけとまとめ 2. 前提知識 3. 直近のサプライチェーン攻撃の要点 4. 攻撃内容を踏まえた対策 5. まとめ 3
4. 本スライドの位置づけとまとめ 4
5. 本スライドの位置づけ 想定している聞き手 これからコーディングエージェント（Claude Code 等）を使おうとしている人 使うこと自体は止めないが、おさえるべきことをきちんとおさえてほしい 元記事の要点を初心者向けにまとめたもの 「AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防 衛術」 記事自体はボリュームがあり、前提知識も要求されるもの 可能なら本発表を地図にして、AI に質問しながら記事を読んでみてほしい AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 5
6. まとめ①：マルウェアガチャの時代と認識する コーディングエージェントが広まるにつれて、誰もが一定確率でインシデントを起こ しうる状況になっており、複数の層で守る（多層防御）必要がある 確率を下げる マルウェアの引き当て確率を下げる 影響を最小化する 万が一引いてしまった時の影響を最小化する 発生時に検知する 引いてしまった時に検知できるようにする AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 6
7. まとめ②：適切な対策を打つ 現状を正しく理解する ソフトウェアサプライチェーン攻撃の現状 自分の端末に存在するリスク コーディングエージェントの挙動 対策を打つ コーディングエージェントの挙動を踏まえて、インシデント確率を下げる 外に漏れて困る情報を可能な限り端末から減らし、影響を最小化する 自分で判断できない時は、調べつつ有識者に相談する AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 7
8. 前提知識 8
9. GUI とCLI コンピュータの操作方法は大きく2 つ GUI （Graphical User Interface ） 画面のボタンやアイコンをクリックして操作する 普段使っているスマホやPC の操作はこれ CLI （Command Line Interface ） 黒い画面に文字でコマンドを打って操作する コーディングエージェントは、ほとんどの作業をCLI 経由で実行する。つまり、画面越 しには見えない場所で、あなたの端末上でコマンドが実行されている AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 9
10. 標準コマンドとスクリプト CLI で実行されるものは2 種類ある 標準コマンド OS に最初から入っている決められた動作（ファイルの一覧表示など） スクリプト プログラミング言語で書かれたコードを実行するもの 中身次第で何でもできる スクリプトの実行 = 書かれたコードを自分の権限で動かすこと AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 10
11. スクリプトで使われるパッケージ スクリプトで実行するコードは、自分で書いたものだけでなく、他人が作ったコード （＝パッケージ）を取り入れて使うことが多く、以下のように使う 1. インストール: パッケージを自分の端末にダウンロードして使える状態にする 2. インポート: 取り込んだパッケージを、参照できるように読み込む 3. 実行: インポートを含むスクリプトを動かすことで、パッケージ内のコードも動く このとき、 コーディングエージェントは、作業中にこれらをユーザーへ提案してくる パッケージの中身を毎回確認するのは現実的ではなく、名前も知らない他人のコ ードが蓄積・活用されていく AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 11
12. なぜパッケージを使うのか／OSS の世界 ソフトウェアを作るとき、全ての機能を自前でゼロから書くのは現実的ではない 自分が作りたいコアな部分は自分で書く それ以外（通信、データ処理、画面表示など）は先人が作ったものを再利用する GitHub 等でソースコードが公開されていて誰でも使えるようにしたものが OSS （Open Source Software ） 。パッケージの多くは OSS として公開されており、多くの人がこれ に乗っかって開発している OSS には、コードに組み込んで使うもの（パッケージ）と、単体のツールとして使うも の（CLI ツール）がある。いずれもOSS 自体が各種OSS に依存しながらエコシステムが できている AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 12
13. 言語とパッケージマネージャ プログラミング言語ごとに、パッケージを配布・管理する仕組み（パッケージマネー ジャ）と配布サイトがあり、初心者でも使うことの多いPython とNode.js は以下の通り 言語 パッケージマネージャ 配布サイト Python pip 、uv 等 PyPI Node.js （JavaScript ） npm 、pnpm 等 npmjs.com コーディングエージェントは、作業中にこれらの仕組みを使ってパッケージのインス トールを提案してくる。ひとつ許可すると、そのパッケージが内部で使う別のパッケ ージ（＝間接依存）も連鎖的に入り、最終的に名前も知らない数十〜数百以上のパッ ケージが端末で動くことになる AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 13
14. 直近のサプライチェーン攻撃の概要 14
15. OSS が狙われる構造 サプライチェーン攻撃とOSS の特性 ソースコードが公開されているため、中身も侵入可能経路も分析しやすい AI により、コード解析やマルウェア開発が効率化され、攻撃者の練度も向上 1 つ侵害できると、そのOSS に依存しているコードへ指数関数的に攻撃可能 これによって、攻撃側と防御側は非対称な構図 攻撃側: 1 つのOSS を侵害するだけで、芋づる式に多数の環境に攻撃可能 防御側: 自分が使っているOSS が1 つ、1 度侵害されるだけで、端末を起点にそこか ら繋がる先（クラウド・サーバー・所属組織など）まで被害が広がりうる 2026 年2 〜4 月にインシデントが立て続けに発生しており、3 つの事例を見ていく AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 15
16. 事件①：Trivy を起点とする連鎖侵害 侵入経路 と 連鎖性 が特徴の事件 最初の侵入は Trivy のリリース基盤（OSS をビルド・公開する仕組み） そこから得た認証情報を使って、他のOSS のメンテナー権限を次々に窃取 LiteLLM 、Telnyx （いずれもPyPI パッケージ）と連鎖的に侵害が広がった 1 つの侵入が、関連するOSS を巻き込みながら広がっていく構図 AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 16
17. 事件②：axios メンテナーアカウント乗っ取り 影響規模の広さが特徴の事件（Trivy 連鎖とは別の事件） 2026/3/31 、週1 億ダウンロードのnpm パッケージ axios が侵害された 侵入経路はメンテナーアカウントの乗っ取り（ソーシャルエンジニアリング等が 疑われる） メンテナー権限で悪性バージョンが公開され、それに依存する世界中のプロジェ クトへ配布されうる状況になった 広く使われているOSS ほど、1 回のアカウント乗っ取りで影響範囲が一気に広がる。 「自分はaxios を使っていない」でも、間接依存経由で影響を受けうる（実はOpenAI も 侵害を受けた） AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 17
18. 事件③：Vercel OAuth サプライチェーン侵害（※ 参考） 信頼して連携許可したアプリが侵害の入口になった事件（2026/4/19 公表） Vercel 従業員が業務で連携許可していたOAuth アプリ（ 「〇〇と連携しますか？」 と聞かれて許可するもの）が侵害された そのアプリの権限を通じて、従業員のGoogle Workspace → 内部システムへ横展開 結果として顧客のシークレットが露出。潜伏期間は約22 か月 OAuth トークンはパスワード変更後も有効で、初回認可後に監査されるのもまれ 「便利そうだから連携を許可する」もパッケージの導入と同じリスクがある。事件 ①②とあわせて、2026 年3 〜4 月に3 件の発覚が相次いでおり、いずれも開発者のクレデ ンシャルが標的 AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 18
19. ポイント①：パッケージが悪性化する2 つのパターン パッケージが悪性化する経路は大きく2 パターン 新しいバージョンを出すパターン メンテナーアカウントを乗っ取り、悪性版を新しいバージョンとして公開 例: axios 1.14.1 / 0.30.4 の新リリース リリース済みのバージョンの中身を差し替えるパターン 同じバージョン番号のまま、中身のコードを差し替える いつも使っているバージョンが、ある日勝手に悪性化しているケース 後の対策が、それぞれに対応する 新バージョンの罠 → 検疫期間（新バージョンを一定期間寝かせる） 中身の差し替え → ハッシュ固定（インストール時に中身の同一性をチェック） AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 19
20. ポイント②：マルウェアの動作パターン マルウェアが動き出すタイミングは大きく3 パターン postinstall （インストール時の自動スクリプト）に含まれている パッケージを入れた瞬間に動く（ユーザーが何もしなくてもよい） パッケージ本体のコードに組み込まれている パッケージをインポートして使ったとき、悪性部分も一緒に動く 上の亜種として、外部から本体を取得する 上記のいずれかをきっかけに、外部サーバーからマルウェア本体を取得 公開されたパッケージだけ見ても悪性と判定しにくい（Telnyx で確認） 実行後に自身を削除し痕跡を消す（axios で確認） 「入れる前に確認すれば安全」も「入れた後に確認すれば安全」も成り立たない AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 20
21. ポイント③：マルウェアがやること 侵害の方法 マルウェアの目的は大きく2 つ 外部情報通信（盗む） 端末上の情報を攻撃者へ送る 送信先は、攻撃者の自前サーバー、またはGitHub など正規の公開サービス 正規サービス経由の場合、正規の通信もあるため遮断は難しい 端末乗っ取り（制御する） 攻撃者が端末を遠隔操作できる状態にする（RAT: Remote Access Trojan ） 情報を盗むだけでなく、それ以降のあらゆる操作が攻撃者の手に渡る 「情報が漏れる」だけでなく「端末そのものが乗っ取られる」レベルの被害がある前 提で考える必要がある AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 21
22. ポイント④：何が狙われるか 事例から見える対象 LiteLLM 侵害ではマルウェアのコードから「何を盗もうとしていたか」が具体的に判明 SSH 秘密鍵、クラウドの認証情報（AWS / Google Cloud / Azure ） .env ファイル、Git の認証情報、ブラウザの認証トークン Docker / Kubernetes の設定、シェル履歴、暗号通貨ウォレットなど 一方、Telnyx / axios 侵害ではマルウェア本体を外部サーバーから取得する方式だった ため、窃取対象の特定は困難だった 事例で列挙された範囲は、実際に狙われた＝自分の端末にあれば確実にリスクで あり、特定できなかった攻撃では、より広範囲が対象だった可能性がある コーディングエージェントの利用で、コマンド実行結果・DB 問い合わせ結果・一 時ファイルなど、意図せず端末に残るデータも増えていく AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 22
23. 攻撃内容を踏まえた対策 23
24. 対策の全体像 1 つの対策だけでは防ぎきれないため、複数の層で守る（多層防御） 。対策には大きく4 つの観点がある 次からそれぞれを見ていく AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 24
25. 対策①：環境隔離 目的: 動作環境と周辺環境の境界を設け、マルウェアが動いても境界内に被害を限定 専用端末: 可能であればこれが一番望ましい クラウド実行環境（Claude Code Web 等）: 自分の端末と完全に別のVM 。ローカ ルのファイル・クレデンシャルに一切アクセスしない コンテナ実行環境（Dev Container 、Docker 等）: ローカル上のコンテナ内で開 発。ホームディレクトリをマウントしなければ端末のファイルが見えない OS レベルのサンドボックス（Claude Code の /sandbox 等）: ホスト上で動かす が、ファイルアクセスや通信をOS の仕組みで制限する（Windows のClaude Code は未対応） AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 25
26. Claude Code （Mac ）でやるべきこと① Claude Code では、ツール呼び出しのたびにユーザーへ確認プロンプトを出す仕組み （権限レイヤー）がデフォルトで存在する サンドボックスを有効にすると、権限レイヤーに加えて、Bash コマンドとその子プロ セスに対してOS レベルの制限が追加される ファイル書き込み制限: 作業ディレクトリ等の許可された場所以外への書き込みを ブロック ネットワーク制限: 許可されたドメイン以外への通信をブロック サンドボックスが適用されるのは Bash コマンド（npm, curl, postinstall スクリプト等） のみ。Claude Code の組み込みツール（Read, Edit, WebFetch 等）には適用されない AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 26
27. Claude Code （Mac ）でやるべきこと② ~/.claude/settings.json に以下を設定する（全プロジェクトに適用される） { "sandbox": { "enabled": true, "allowUnsandboxedCommands": false, "filesystem": { "denyRead": ["**/.env*", "~/.ssh/**", "~/.aws/**", "~/.config/gcloud/**"] } } } Bash コマンドの書き込み・通信を制限し、機密ファイルの読み取りもブロックする。 denyRead の対象は一例であり、自分の端末に存在するクレデンシャルに応じて変更す ること AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 27
28. 対策②：リスクの最小化 認証やデータの扱いには「痕跡」が残る ブラウザでログイン → セッションクッキーがブラウザに残る CLI でログイン → 認証トークン・認証ファイルが端末に残る これらが窃取されると、攻撃者が「本人としてログインした状態」や「業務データへ のアクセス」を手にする可能性があるので、以下の対応をする 窃取されてもログインしにくくする: MFA 、IP や端末でのアクセス制限 ログインするときの権限を限定: 最小権限のロール、管理者権限で作業しない 使い終わったらログアウトして残さない: 利用したトークンを無効化 クレデンシャル以外も残さない: .env 、ダウンロードした機密データ、クエリ結 果、作業ログをローカルに溜め込まない AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 28
29. 対策③：予防措置 悪性パッケージを取り込まないために、パッケージ取り込みを統制する よくわからない／マイナーなパッケージをいれない レジストリプロキシを有効化する 検疫期間を設定する（新バージョン公開型への対策） 可能であればハッシュ固定を設定する（リリース済み差し替え型への対策） postinstall を既定で無効にする 次から以下を補足する 信頼できるかの判定基準、レジストリプロキシとは、バージョンタグとハッシュ の関係、設定手順 AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 29
30. 補足: 信頼できるかの判定基準 導入前に以下を目安として確認する 作成者が信頼できること（サービス提供元が公式に提供している、著名なOSS 製 作者であるなど） 利用者から十分に評価されていること（Star やダウンロード数が多いなど） 現在も活発にメンテナンスされていること（バージョン更新が頻繁、放置されて いるIssue が少ないなど） 依存関係が少ないこと（やや高度。間接依存が増えるほど攻撃面が広がる） コーディングエージェントにセキュリティリスクを聞くと、これらを確認できる ただし、これらを全て満たしていてもメンテナーが侵害されるリスクはある（axios の 事例がまさにこれ） 。判定基準だけに頼らず、後述の対策と組み合わせることが必要 AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 30
31. 補足: レジストリプロキシとは パッケージの配布サイト（PyPI 、npmjs.com 等）と端末の間に立つ中継サーバー 通常は端末から配布サイトへ直接パッケージを取りに行く プロキシを経由すると、悪性パッケージの検知・ブロックや検疫期間の適用がプ ロキシ側で行われる Flatt Security が無料で提供しているTakumi Guard を利用すること メールアドレスを登録するとインストール済パッケージが後から悪性と判明 した際に通知される（事後検知／HP の手順に沿って設定が必要です） AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 31
32. 補足: バージョンタグとハッシュ パッケージはバージョン番号で指定するのが一般的だが、以下のリスクがある バージョン範囲指定（ ^1.14.1 等）だと、別バージョンが入りうる npm ・PyPI は同一バージョンの再公開を禁止しているが、レジストリ侵害による 迂回リスクはある GitHub Actions のタグ（ @v4 等）は同一タグで中身を差し替え可能 ハッシュはパッケージの中身から計算される値で、中身が変われば必ず変わる lockfile にハッシュが記録され、インストール時に同一性を自動検証 npm: package-lock.json の integrity uv: uv.lock の hashes GitHub Actions はコミットSHA で固定（例: actions/checkout@a5ac7e... ） AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 32
33. Node.js （npm ）でやるべきこと 不要ならそもそもインストールしない前提で、必要な場合は事前に以下のファイルを 指定のディレクトリに配置する #.npmrc registry=https://npm.flatt.tech # レジストリプロキシを設定 min-release-age=7 # 検疫期間を7日間に設定 audit=true # インストール時に既知の脆弱性がないか自動チェック save-exact=true # バージョンを範囲指定ではなく完全固定 ignore-scripts=true # postinstallをデフォルトで無効化する Windows: %USERPROFILE%/.npmrc （ %USERPROFILE% は C:/Users/ユーザー名/ ） Mac: ~/.npmrc （ ~ は /Users/ユーザー名/ ） 共有リポジトリからパッケージをインストールするときは、 npm ci で行う AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 33
34. Python （PyPI ）でやるべきこと① 不要ならそもそもインストールしない前提で、必要な場合は事前に以下のファイルを 指定のディレクトリに配置する #pip.ini (Windows) / pip.conf (Mac) [global] index-url=https://pypi.flatt.tech/simple/ # レジストリプロキシを設定 Windows: %APPDATA%/pip/pip.ini （ %APPDATA% は C:/Users/ユーザー 名/AppData/Roaming/ ） Mac: ~/.config/pip/pip.conf （ ~ は /Users/ユーザー名/ ） なお、素のpip では検疫期間の設定ができないので、パッケージマネージャーはuv を使 用する方がよい AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 34
35. Python （PyPI ）でやるべきこと② uv の場合は以下 exclude-newer = "7 days" # 検疫期間を7日間に設定 add-bounds = "exact" # バージョンを範囲指定ではなく完全固定 [[index]] url = "https://pypi.flatt.tech/simple/" # レジストリプロキシを設定 default = true Windows: %APPDATA%/uv/uv.toml （ %APPDATA% は C:/Users/ユーザー 名/AppData/Roaming/ ） Mac: ~/.config/uv/uv.toml （ ~ は /Users/ユーザー名/ ） 共有リポジトリからパッケージをインストールするときは、 uv sync で行う AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 35
36. とにかく 不要ならプログラミング言語を入れないでください 入れるならちゃんと設定をしてください わからなかったら有識者に相談してください AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 36
37. 対策④：エージェントの制御 コーディングエージェントが端末で何をできるかを、ユーザー側で制御する AI ツールの許可設定で、実行できるコマンドや触れるファイルの範囲を絞る 例: Claude Code の permissions 設定で、特定のコマンドだけ許可・拒否する 何でも「許可」を通さない運用にする 事前説明の上判断する、 --dangerously-skip-permissions を利用しないなど 拡張機能（Skill 、MCP 等）も信頼できないものは導入しない パッケージと違い、ハッシュ固定の仕組みが弱いため、予防や検知が困難 「便利そうだから入れてみよう」はパッケージと同じリスクがある 判断に迷ったら、自分だけで決めず、調べつつ有識者に相談する前提で進めること AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 37
38. まとめ（再掲） 38
39. まとめ①：マルウェアガチャの時代と認識する コーディングエージェントが広まるにつれて、誰もが一定確率でインシデントを起こ しうる状況になっており、複数の層で守る（多層防御）必要がある 確率を下げる マルウェアの引き当て確率を下げる 影響を最小化する 万が一引いてしまった時の影響を最小化する 発生時に検知する 引いてしまった時に検知できるようにする AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 39
40. まとめ②：適切な対策を打つ 現状を正しく理解する ソフトウェアサプライチェーン攻撃の現状 自分の端末に存在するリスク コーディングエージェントの挙動 対策を打つ コーディングエージェントの挙動を踏まえて、インシデント確率を下げる 外に漏れて困る情報を可能な限り端末から減らし、影響を最小化する 自分で判断できない時は、調べつつ有識者に相談する AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 40
41. 参考 「2026 年3 月19 日の Trivy 再侵害の概要と対応指針」 「2026 年3 月24 日の LiteLLM 侵害の概要と対応指針」 「2026 年3 月27 日の Telnyx 侵害の概要と対応指針」 「axios ソフトウェアサプライチェーン攻撃の概要と対応指針」 「Vercel 侵害：OAuth サプライチェーン攻撃がプラットフォーム環境変数に潜む見 えにくいリスクを露呈」 「axios, LiteLLM... 不使用だったのでOK 、ではない。 「次に備える」ソフトウェアサ プライチェーン侵害への対策」 Takumi Guard 41
42. 関連情報 生成AI やAI エージェントの仕組みについては、こちらも参考までに 「生成AI の成果物を統制するための考え方と実践：対話型AI からAgentic Coding 、 AI プラットフォーム、AI データ基盤まで」 AI コーディング時代における、ソフトウェアサプライチェーン攻撃に対する防衛術（簡易版） by D （@SoySoySoyB ） 42