securitywebops

npmサプライチェーン対策｜依存差分をCIで止めるチェックリスト（新規依存/Install Script）

2026年4月2日

4 min read

npmのサプライチェーン攻撃はアプリのコードレビューをすり抜ける。依存グラフの差分を「セキュリティイベント」として扱い、新規依存とinstall/postinstallをCIで止めるための実務チェックリスト。

結論（Conclusion）
背景（Explanation）
実務手順（Practical Guide）
手順1（ベースライン）：ビルドを再現可能にする
手順2：2つの“ハードストップ”を決める
手順3：レビュー面を固定する
手順4：アップデートはバッチ化する
手順5：侵害が疑われた時の最初の動き
失敗パターン（Pitfalls）
チェックリスト（Checklist）
FAQ
Q1. 厳しすぎて開発が遅くならない？
Q2. コードレビューで十分じゃない？
Q3. 1つだけやるなら？
内部リンク（Internal links）
参考（一次/準一次）

小規模チームでnpmサプライチェーン攻撃を防ぐなら、何を最初にやる？

結論（Conclusion）

SOCは不要。必要なのは CIが依存差分を止めること。

最強のコントロールはこれ。

新規依存の追加を検知して止める（承認が必要）
installスクリプト（preinstall/install/postinstall）をゲートする
lockfileを必ずコミットし、CIは npm ci で固定する

AI実装で出荷が速いほど、依存の増加も速い。だからゲートが効く。

背景（Explanation）

サプライチェーン攻撃は、アプリコードのレビューをすり抜ける。典型はこう。

メンテナーアカウントが侵害
本体コードは一見クリーン
新しい依存が追加
install scriptでpayload実行

だから「リポジトリ内の怪しい文字列検索」では間に合わない。見るべきは 依存グラフの差分。

実務手順（Practical Guide）

手順1（ベースライン）：ビルドを再現可能にする

lockfileをコミット（package-lock.json / pnpm-lock.yaml / yarn.lock）
CIは npm ci（依存解決の揺れを防ぐ）

判断基準：

lockfileが無いと「何が実行されたか」証明できない。

手順2：2つの“ハードストップ”を決める

ハードストップ①：新規依存の追加

package.json のdirect dependency追加
lockfileに新パッケージ増加

ハードストップ②：installスクリプト

preinstall
install
postinstall

ポリシー：

install scriptを持つ依存が増えたら、明示承認が必要

手順3：レビュー面を固定する

見る場所を2つに絞る。

package.json
lockfile

そしてCIで強制：

新規依存が入ったらfail
allowlist（例外）を用意するのはあり

手順4：アップデートはバッチ化する

依存更新は週1PRなどにまとめる
緊急パッチは例外として扱う

狙い：

変更を追いやすくする
インシデント対応を速くする

手順5：侵害が疑われた時の最初の動き

既知の安全版へpin/rollback
CIランナーも汚染前提で疑う
秘密情報があればローテーション検討

判断基準：

ビルド環境に秘密があったなら、漏洩前提で動く。

失敗パターン（Pitfalls）

「本体がクリーンだからOK」（payloadは新規transitiveにいる）
lockfile差分を見ない
install scriptを無条件許可
依存更新がPRに散ってレビューできない

チェックリスト（Checklist）

[ ] lockfileをコミットしている
[ ] CIは npm ci（または同等）で再現性を担保
[ ] 新規direct dependency追加でCIがfailする
[ ] lockfileに新パッケージが増えたらCIがfailする
[ ] install script持ち依存の追加は明示承認が必要
[ ] install scriptポリシーが文書化されている
[ ] 依存アップデートはバッチ化（週次）
[ ] 緊急パッチの例外手順がある
[ ] インシデント初動（pin/rollback、runner疑い、secret rotation）がある
[ ] PRテンプレに「依存変更」欄がある
[ ] 後から「何が実行されたか」追えるログ/成果物がある

FAQ

Q1. 厳しすぎて開発が遅くならない？

対象はレアイベント（新規依存・install script）だけ。事故のコストを考えると最も費用対効果が高い。

Q2. コードレビューで十分じゃない？

不十分。payloadはtransitive dependencyやinstall時実行で入る。依存グラフの差分を止めないと抜ける。

Q3. 1つだけやるなら？

CIで「新規依存追加」をfailにする。新しい依存は必ず“意思決定”にする。

内部リンク（Internal links）

親記事（Hub）：AI開発：まずはここから
関連記事：

参考（一次/準一次）

StepSecurity（axios侵害）: https://www.stepsecurity.io/blog/axios-compromised-on-npm-malicious-versions-drop-remote-access-trojan
Socket（依存差分の観点）: https://socket.dev/blog/axios-npm-package-compromised
Snyk（対処まとめ）: https://snyk.io/blog/axios-npm-package-compromised-supply-chain-attack-delivers-cross-platform/