AIが追加したnpmパッケージは安全？依存関係とCIを守るサプライチェーン対策

こんにちは、Ryohei（@ityryohei）です！

AIにフォームや管理画面を作ってもらうと、コードだけでなく、新しいnpmパッケージやビルド設定まで提案されることがあります。画面が動き、テストが通っても、その依存関係を本番へ持ち込んでよいかは別の確認です。インストール時やCIの実行中に動くコードは、サイト利用者に公開する前から開発環境へ影響します。

英国NCSCは2026年6月4日にソフトウェアサプライチェーン攻撃への対策、6月18日にAI支援開発の監督方法を公表しました。前者は依存関係と開発・自動化環境、後者はコードの用途に応じたレビューの強さを扱います。本稿は、両資料とnpm・GitHubの公式仕様を2026年10月14日に確認して整理した深掘り解説です。新たな侵害事件の速報ではなく、以下の実務例は特定企業の被害事例でもありません。

AIが選んだ依存関係も、第三者のコードである

NCSCの依存関係に関する解説は、パッケージ管理者のアカウント侵害、似た名前のパッケージ、放置されたパッケージの引き継ぎ、インストールや更新の自動実行などを攻撃経路として挙げています。小さな依存がさらに別の依存を読み込むため、直接追加したライブラリだけを見ても全体は分かりません。出典：NCSCのソフトウェアサプライチェーン対策。

AIが生成した導入コマンドは、採用理由を調べるきっかけにはなりますが、配布元や内容を保証する証明書にはなりません。公式文書で名前・スコープ・リポジトリを確認し、実際に取得されるバージョンと公開物を点検します。名前が実在するだけでも、GitHubのスターが多いだけでも十分ではありません。正規のパッケージが侵害される可能性も含めて考えます。

ここでAIの悪用と、AI利用者の導入判断は区別してください。依存関係を通じた侵害がすべてAI攻撃というわけではありません。本稿で扱うのは、AIによって追加や更新が容易になった開発フローへ、従来のサプライチェーン対策をどう組み込むかです。攻撃者がAIを使ったかどうかが不明でも、導入したコードを管理する必要は変わりません。

本番で使わないdevDependenciesも点検する

WordPressのテーマをレンタルサーバーで運用し、SassやJavaScriptを手元またはCIでビルドする例を考えます。サーバーへアップロードするのはCSS・JS・PHPだけでも、ビルドに使う依存パッケージは開発端末やCIで実行されます。その環境にSFTPの秘密鍵、クラウドのトークン、パッケージ公開用の認証情報があれば、ビルドツールの侵害から別のサービスへ影響が及ぶ条件があります。

そのため、devDependenciesを「本番に入らないから安全」と一律に扱わないようにします。守る対象には公開サイトだけでなく、ソースコード、成果物、配布経路、開発者アカウントが含まれます。どの工程で何が動き、その工程から何へアクセスできるかを一覧にしてください。

また、ローカルでの検証用スクリプトにも注意が必要です。AIが提案したセットアップや修復コマンドが、追加パッケージの取得、シェル実行、外部通信を含む場合があります。「エラーを直すため」という説明で権限を広げる前に、変更されるファイルと実行内容を確認します。検証は、本番の秘密情報を入れていない別環境から始めるのが本稿の提案です。

優先1：package.jsonとロックファイルを同時にレビューする

コードの差分に加え、package.jsonとpackage-lock.jsonの変更をレビュー対象にします。AIには、追加した依存、採用理由、代替候補、推移的に増える依存、インストール時スクリプトの有無を説明させます。その説明を、実際の差分と提供元の資料で確かめます。

標準機能や既存の依存だけで実装できないか確認する
公式サイトとパッケージのスコープ・名前・ソースリポジトリを照合する
追加・更新したバージョン、取得先、ロックファイルの差分を確認する
新しいインストールスクリプトや外部通信、難読化されたコードの変更理由を調べる
採用判断、確認した日、担当者、更新時の確認条件を記録する

npm ciは既存のロックファイルを使い、package.jsonと不一致ならエラーにし、両ファイルを書き換えません。CIでレビュー済みの依存構成を再現するために役立ちます。一方、悪意あるバージョンがロックされていればそれも再現するので、安全性の保証にはなりません。出典：npm ci公式資料。

運用ではNode.js・npmのバージョンと設定も記録します。ロックファイルを作ったときの依存解決オプションがCIと違えば、インストールが失敗することがあります。失敗したからといってCI内でロックファイルを自動再生成し、差分を見ずに採用するのは避けます。

優先2：インストール時と実行時の境界を分ける

依存パッケージはアプリ起動時だけでなく、取得時のスクリプトでもコードを実行し得ます。初期評価でnpm ci --ignore-scriptsを使う方法は、インストール時スクリプトの実行を抑える選択肢です。ただし、既存のnode_modulesがある場合、npm ciはそれを削除して入れ直します。作業対象と影響を確認したうえで使います。

ignore-scriptsを設定しても、npm runやnpm testなど、明示的に要求したスクリプト自体は動きます。依存モジュールをimportしたときやビルドツールを起動したときまで保護するものではありません。ネイティブモジュールなど、正当なインストールスクリプトを必要とする依存ではビルドが壊れることもあります。すべてのプロジェクトへ機械的に設定するのではなく、使用中のnpm版の資料と必要な処理を確認してください。

実務では「スクリプトを禁止して終わり」ではなく、必要なスクリプトを誰が確認し、どの環境で、どの権限で動かすかまで決めます。許可対象を管理する機能の有無や設定方法はnpmの版によって確認が必要です。古いコマンド例をそのまま流用せず、環境のバージョンに対応した公式資料を参照します。

優先3：脆弱性検査と来歴確認を別々に行う

npm auditは依存構成をレジストリへ送り、既知の脆弱性の報告を求めるコマンドです。報告がないことは、新しい悪意あるコードや未報告の問題がないことの証明にはなりません。またnpm audit fixは内部でインストール処理を行うため、単なる読取確認と区別して使います。出典：npm audit公式資料。

署名やprovenanceも、別の観点の確認材料です。npmのprovenanceは公開物とソースコード・ビルド手順の検証可能な関連を示しますが、悪意あるコードがないことは保証しません。配布されたものが期待するソースと工程に対応するかと、そのソースが安全かは別の問いです。出典：npmのprovenance資料。

レビューでは、検査結果、配布元、来歴、変更内容、実行権限を合わせて判断します。npm audit signaturesで署名や来歴の検証を行う場合も、利用するレジストリの対応状況とCLIの仕様を確認します。社内パッケージを含む環境では、検査時にどの依存情報がどのレジストリへ送られるかも把握してください。

優先4：CIのビルドと本番配布を分離する

GitHubは、ワークフローで使う資格情報とGITHUB_TOKENを必要最小限の権限にするよう説明しています。第三者Actionのソースと取得元も確認対象です。現行資料はワークフロー依存のロックファイルを推奨し、導入できない場合の方法としてActionを完全なコミットSHAへ固定することを挙げています。出典：GitHub ActionsのSecure use reference。

本稿の設計例は、未承認の依存を評価するジョブ、レビュー済みコードをビルドするジョブ、本番へ配布するジョブを分ける形です。評価・ビルド段階へ本番の秘密鍵を渡さず、配布は承認済みの成果物だけを受け取ります。成果物がどのコミットとロックファイルから作られたかを記録すると、問題発覚後に対象を絞りやすくなります。

分離はジョブ名だけでは成立しません。同じ共有ディレクトリ、常駐ランナー、キャッシュ、書き込み可能な成果物保存先を通じて、後続処理が影響されないか確認します。コンテナを使っても、秘密情報やホスト領域を広くマウントすれば隔離の効果が下がります。何を隔離し、何を共有しているかを図にして点検します。

自動更新を止めっぱなしにしない

新しいバージョンを無審査で導入することと、既知の脆弱性を放置することの両方を避ける必要があります。通常更新は差分確認とテストを通し、悪用が確認された問題の修正には優先経路を用意します。一律に一定日数待つルールだけでは、攻撃進行中の修正を遅らせるおそれがあります。

具体的には、依存追加と依存更新のPRを分け、更新の理由、影響する実行工程、提供元の勧告、テスト結果、ロールバック方法を記録します。修正を急ぐ場合も、既知の悪いバージョンへ戻るだけの復旧計画にしないよう、戻し先の安全性を確認します。

不審な依存を実行してしまった場合

まず、該当バージョンを取得・実行した開発端末とCIジョブを特定し、その時点でアクセスできた認証情報とサービスを整理します。依存を削除するだけでは、すでに持ち出されたトークンや変更された成果物への対処にはなりません。ログ・コミット・ロックファイル・成果物を保全し、対応担当者と封じ込め範囲を決めます。

必要に応じて資格情報を失効・再発行し、異常な認証利用、パッケージ公開、リポジトリ変更、配布先の改変を調べます。公開物を再ビルドするなら、信頼できるソース・依存・実行環境からやり直します。取得しただけか、インストールスクリプトを動かしたか、実際にモジュールを実行したかを区別して影響を評価します。

AI支援開発で残したい採用チェック

AIが追加した依存を、人が差分から把握できるか
取得元・名前・バージョン・採用理由を確認したか
ロックファイルを保存し、CIの環境と設定を再現できるか
インストール時・ビルド時・実行時のコードを区別して点検したか
既知脆弱性と来歴の確認を、安全性の保証と取り違えていないか
評価・ビルドに本番の認証情報を渡していないか
更新と緊急修正、事故時の失効・再ビルド手順があるか

NCSCのAI支援開発に関する資料は、認証・顧客データ・秘密情報を扱うコードでは、用途に応じたレビュー、理解、検査、検証が必要だと説明しています。依存関係の採用も同じ開発判断に含めてください。AIで実装を速めるほど、「どこから何を持ち込んだか」を説明できる工程を残すことが重要です。出典：NCSCのAI支援開発資料。