依存関係混乱とは？dependency confusionの危険性と対策方法を徹底解説

依存関係混乱とは何か

非公開と公開の解決順の差で、意図しないパッケージを取る問題です

依存関係混乱は、内部パッケージ名と公開レジストリ上のパッケージ名が衝突し、解決順や設定差によって意図しないパッケージが取得される問題です。パッケージ名が正しく見えていても、どのレジストリから引いたかが違えばビルド結果は変わります。

このため問題の主役は「悪意あるコードを書いた人」だけではありません。内部の命名、スコープ、レジストリ優先順、CI 設定差が組み合わさって事故になります。

悪意ある package 混入とは、成立条件が少し違います

悪意ある npm / PyPI パッケージは、公開レジストリに置かれたパッケージ自体が主役です。依存関係混乱は、本来は internal package を取るはずだったのに、解決順の都合で別物を取る点が主役です。

だから対策も、package 審査だけでは終わりません。scope 設計、private mirror、lockfile、CI 設定の統一まで必要です。

総論記事であるソフトウェア供給網記事の下位論点です

dependency confusion はソフトウェアサプライチェーン攻撃の下位論点です。供給網全体の中でも、レジストリ解決順と命名衝突に絞って深掘りすると実務で使いやすくなります。

検索意図としても、読者が知りたいのは「dependency confusion という単語の意味」より、「内部 package を使っているつもりなのに何が起きるのか」「なぜ CI だけ別の結果になるのか」です。つまりこのテーマでは、malware の種類を説明するより、package 解決の前提がずれる仕組みを具体的に整理する方が価値があります。

なぜ成立するのか、どこが盲点になるのか

名前が同じでも、どこから取るかで別物になります

依存関係混乱で重要なのは、「名前が正しいか」だけを見ても不十分なことです。実務では、どの registry をどの順番で解決するかが事故を左右します。

同じパッケージ名でも、内部から取る想定なのか、公開側から取る想定なのかで意味が変わります。これを人力運用で吸収しようとすると限界があります。

CI と開発者端末の settings 差が見落とされやすいです

Microsoft のDevOps Threat Matrix↗が示すように、DevOps 環境は code だけでなく pipeline settings や secret まで含めて threat model を作る必要があります。dependency confusion では、CI だけ設定が違うという drift が大きな原因になります。

開発者端末では再現しないのに CI だけ別パッケージを取る、という状態は実務で非常に見抜きにくく、レビューもすり抜けやすいです。

対策はパッケージ審査だけでなく、解決順の固定が必要です

依存関係混乱は「怪しい package を見つける」だけでは止まりません。scope、private mirror、lockfile、hash、CI テンプレートのような解決順そのものを固定する仕組みが必要です。

逆にいえば、package 審査だけ強くしても、同名解決や registry 優先順のずれが残っていれば事故は続きます。dependency confusion は、コードレビューより configuration review の比重が高い攻撃です。そのため review 手順も、package 名やバージョンだけでなく、取得元、scope、mirror 設定、publish 設定まで見ないと片手落ちになります。

被害の広がり方と企業側のリスク

ビルド結果が静かに変わるのが一番危険です

dependency confusion の怖さは、派手な exploit ではなく、気づかれないままビルド結果が変わることです。しかも原因がパッケージ名、レジストリ設定、CI 側のずれに分散しているため、事故後の切り分けも難しくなります。

開発 supply chain の問題ですが、外部公開導線とも無関係ではありません

パッケージ事故自体は内部のビルド問題ですが、事故後には管理画面、成果物ポータル、古いログイン画面など公開導線の確認も必要になります。だから外部接続点の可視化の補助線も無駄ではありません。

特に社内 registry や package proxy を運用している組織では、公開されていない前提の管理画面、古い mirror URL、委託先向け portal が残っていると、設定変更や credential 取得の入口になります。dependency confusion の直接原因ではなくても、事故後に「どこまで信頼境界が汚染されたか」を確認する対象として重要です。

どこで解決順がずれるのかを具体的に見る

依存関係混乱は『設定 drift の事故』でもあります

dependency confusion は、攻撃者が何かを置いた瞬間だけで成立するわけではありません。実際には、開発者端末、shared CI、container template、委託先 build 環境の settings drift が積み重なり、誰も現在の解決順を説明できない状態になった時に起きやすくなります。

そのため再発防止では、単一の設定ファイル修正より、標準 template 化、review 項目の固定、registry 設定変更の申請制が効きます。つまり技術的な脆弱性より、運用差分の統制が主役です。

『内部名だから安全』という思い込みが一番危険です

多くの組織では、内部 package 名は public 側に存在しない前提で運用されています。しかし、namespace 予約や scope 固定をしていないと、その前提はいつでも崩れます。内部名だから安全なのではなく、内部名が public 側へ解決されない仕組みがあるから安全なのです。

この違いを理解していないと、対策が「怪しい package を探す」方向へ寄り過ぎます。dependency confusion で見るべきは、package の見た目より、なぜその package がそこから取れたのかという解決経路です。

再発を防ぐ review と運用の作り方

package review と registry review を分けません

実務では、新規依存追加の review は行っていても、registry 設定や mirror 設定の review は別扱いになりがちです。しかし dependency confusion の再発防止には、この二つを一つの review にまとめる必要があります。なぜなら、「何を入れたか」と「どこから取ったか」は分離できないからです。

具体的には、新規 package 追加、registry 優先順変更、scope 追加、mirror fallback 変更、publish 権限変更を同じ change 種別として扱うと、事故の起点を見落としにくくなります。

incident review は『混入 package』より『混入経路』へ戻します

事故後に package 名だけを blocked list に入れて終わると、別名の同種事故が再発します。incident review では、どの build で、どの settings 差があり、どの token や template がそれを許したのかまで戻す必要があります。つまり review の主語は package ではなく、解決経路です。

ここはソフトウェアサプライチェーン総論やCI/CDパイプライン攻撃とつながる部分でもあり、個別事故を総論の controls に戻していく視点が必要です。

内部レジストリ運用で起きやすい誤解

private registry を入れただけでは、安全になりません

依存関係混乱でよくある誤解が、「private registry や mirror を入れたから安全」という考え方です。実際には、mirror の fallback 条件が広すぎる、内部 package 名を public 側で予約していない、scope の付け方が統一されていない、CI だけ別設定を読んでいる、といった差分が残っていると事故は普通に起きます。つまり安全性を決めるのは mirror の有無ではなく、どんな時にどこを見に行くかが固定されているかです。

特に npm や PyPI を使う現場では、複数の設定ファイル、環境変数、container image、bootstrap script が重なり、誰が最終的な解決順を決めているか分からなくなりがちです。これが dependency confusion の温床になります。だから private registry の導入は出発点であって、そこから namespace、scope、publish ルール、fallback をどこまで固定するかが本番です。

README や onboarding 手順の古さが設定 drift を生みます

実務では、技術的な設定ミスより、古い README、昔の onboarding 手順、委託先へ渡したセットアップメモの方が事故の起点になることがあります。手元の設定だけ直しても、新しく参加した開発者や委託先が古い手順で public registry 優先の環境を作れば、同じ問題は再発します。つまり dependency confusion の対策は、設定ファイルだけでなく配布している運用手順そのものも対象です。

そのため、review すべきなのは package manifest だけではありません。template repository、build container の base image、setup script、ローカル開発の初期化手順、委託先用の手順書まで含めて、同じ registry 優先順を保てているかを見る必要があります。ここを放置すると、「本番環境では直したのに、別経路から drift が戻る」状態になります。

公開 registry を完全に使わない方針でも、境界を説明できなければ危険です

「うちは public registry を使わないから関係ない」という組織でも、委託先の端末、検証用環境、ローカルの package cache、社内 mirror の upstream 設定が public 側へつながっていることがあります。つまり public registry の利用禁止だけでは不十分で、どの経路が外部とつながり、どこで遮断しているかを説明できるかが重要です。

依存関係混乱は exploit の巧妙さより、前提の曖昧さで成立する攻撃です。だから「使っていないはず」「手元では再現しないはず」のような説明が多い環境ほど危険です。安全な運用とは、禁止ルールを増やすことではなく、解決経路を現実に即して説明できることです。

委託先・template・mirror まで同じ基準で見る

委託先の build 条件が違うだけで、事故条件はそろいます

dependency confusion が厄介なのは、攻撃者が特殊な exploit を使わなくても、build 条件の違いだけで成立することです。委託先が持ち込んだ container image、古い npmrc、別の package proxy、簡略化した setup 手順などがあると、社内では private を引くのに委託先環境では public を先に引く、という状態が起きます。コードが同じでも build 条件が違えば結果は変わるため、納品されたソースだけを見ても十分ではありません。

ここは業務委託先のアカウント管理と似ています。つまり委託先管理は契約や人の問題だけではなく、技術設定の統一にも踏み込まないと、依存関係混乱の再発防止になりません。委託先へ渡す template や setup 手順も、本番 build と同じ trust boundary を前提に揃える必要があります。

template repository と base image を放置すると drift が戻ります

一度設定を直しても、template repository や base image が古いままだと、後から作られる新規 project に同じ問題が再流入します。これは dependency confusion 対策で非常に多い見落としです。既存 project の npmrc や pip.conf を直しただけでは、新規 repo 作成時の template が public registry 優先のままなら、数か月後に同じ事故が別 project で起きます。

そのため再発防止では、個別 project の設定修正と同時に、template repository、shared CI template、base image、bootstrap script、internal handbook の順に直していく必要があります。つまり dependency confusion は、単一 project の設定不備ではなく、組織標準の drift 管理の問題でもあります。

incident review の終着点は『設定差が戻らない仕組み』です

事故後に package 名を blocked list に入れたり、mirror の一設定だけを修正したりするだけでは、別の名前や別の project で再発します。incident review で目指すべきなのは、誰が registry 設定を変えられるのか、どの template が正なのか、委託先がどの手順に従うのかを固定し、設定差が勝手に戻らない仕組みを作ることです。

その意味で dependency confusion は、package 名を巡る小さな事故ではありません。settings、templates、委託先、mirror、publish ルールを同じ change 管理へ戻せるかどうかを問う記事です。ここまで整理できると、検索意図で求められる「なぜ起きるのか」「どこから直すのか」に、実務的な順番で答えられるようになります。

検知・防御・運用で押さえるべき対策

実務では、まず内部パッケージ名とレジストリ解決順の固定、その次に lockfile と hash 検証、そのうえで CI / 開発者端末のずれ解消という順で進めると整理しやすくなります。

開発関連の公開導線や管理面の棚卸しなら ASM診断 PRO

ASM診断 PRO は dependency confusion 自体を防ぐ製品ではありませんが、外から見えるログイン画面、成果物ポータル、古い管理 URL、委託先導線の棚卸しを補助する入口として使えます。

build や registry の事故後は、外部公開された開発関連導線の見直しも必要になります。公開面の棚卸しを先に進めると、事故後の確認範囲を狭めやすくなります。

依存関係混乱の中心は registry 解決ですが、実務で事故後に確認すべきなのは package manager だけではありません。artifact 参照用 portal、委託先の build 接続、古い mirror 管理面、停止済みの開発サブドメインなど、周辺の外部接点も一緒に洗う必要があります。これらが整理されていないと、どこから settings が変わり得たのかを追うだけで時間を失います。

ASM診断 PRO は dependency confusion を直接止めるものではありませんが、開発関連の公開面を見えるようにし、incident review の確認対象を減らす補助線になります。とくに委託先向け login、古い package portal、停止漏れした host が残る環境では、外部露出の棚卸しが設定統制の確認とつながります。

つまりこの文脈での ASM診断 PRO は、「package を守る製品」ではなく「supply chain 事故の後に外から確認すべき導線を平時から減らしておく製品」です。内部の registry controls と外部の露出整理を別物とせず、同じ review の一部に入れると、再発防止の精度が上がります。

よくある質問

まとめ

依存関係混乱の本質は、パッケージ名そのものではなくどのレジストリをどの順で解決するかにあります。内部パッケージ名、スコープ、CI 設定、lockfile がずれていると、気づかないままビルド結果が変わります。

守る側は、レジストリ解決順の固定、名前空間管理、CI と開発者端末の設定統一、取得元のレビューをまとめて進める必要があります。