署名偽装パッケージ：npm/pip/apt事例と検出シグネチャ

導入：署名偽装（サプライチェーン侵害）の現状と危険性

近年、オープンソース・パッケージ管理エコシステム（npm／PyPI／apt）の維持者アカウント侵害やビルド流用を起点に、署名や公開履歴を悪用した「署名偽装／供給連鎖（software supply chain）」攻撃が増加しています。攻撃者は正規の公開手順を経て見せかけの署名・配布を行うため、従来の単純なハッシュチェックだけでは検出が困難です。

直近の代表例として、2026年3月にAxiosのnpm公開が乗っ取られ、悪意ある依存関係を挿入してRATを配布した事例や、2026年3月下旬に発生したLiteLLM／TelnyxのPyPIパッケージ改ざん（悪意あるバージョンが短時間公開）など、広範な影響をもたらしたインシデントが確認されています。これらの事例は、メンテナのフィッシングやCI/CDトークンの横取りを経て実行されました。

事例の要点（短期把握）

Axios (npm)：リードメンテナのアカウント乗っ取りにより、axios@1.14.1 および axios@0.30.4 等の悪意あるリリースが短時間で公開され、外部依存（plain-crypto-js）を経由してクロスプラットフォームRATを配布した事例。侵害の軌跡と対応はセキュリティ研究者が詳細解析を公表しています。
LiteLLM / Telnyx (PyPI)：2026年3月にTeamPCPとされる攻撃者が複数のPyPIパッケージに悪意あるバージョンを押し込み、litellm 1.82.7/1.82.8 や telnyx 4.87.1/4.87.2 等が短時間で公開・隔離された事例。侵害は外部のCI／トークン経路を悪用して行われたと分析されています。影響範囲は数万〜数百万ダウンロード規模に及び得ます。
メンテナ／アカウント向けフィッシング：npm／PyPIのメンテナが標的となるフィッシングによりトークンや管理アクセスを奪取され、正規のパブリッシュ経路を悪用するケースが継続して観測されています（2025年7月の大規模なメンテナ向けフィッシング事案も含む）。

検出シグネチャと実務ルール（現場で即使える例）

以下は現場での早期検出に有効なシグネチャ例と検査手順です。ルールは環境に合わせてチューニングしてください。

1) npm（node）向け検出

インストール時フック（postinstall/preinstall）を検出するYARA（パッケージアーカイブ内検査）例：

rule Suspicious_NPM_Postinstall {
  strings:
    $a = /"postinstall"\s*:\s*"/i
    $b = /node-gyp|regsvr32|powershell|schtasks/i
  condition:
    any of them
}

package.jsonの直近変更検知：ローカルキャッシュやSBOMと照合して、直近の公開者（publisher）欄の急な変更や未見の公開元をアラート化する。
偽装依存名（homoglyph/typosquat）検出：正規パッケージ名集合とのレーベンシュタイン距離でスコアリングし、閾値越えで検出（自動スクリプト化推奨）。

2) PyPI（pip）向け検出

import時実行コードの検査：wheel/eggの中にsite-packagesへインジェクトする .pth や import-time 実行コードがないかをYARAでスキャンする。
```
rule PyPI_ImportTime_Exec {
  strings:
    $pth = /\.pth\"/i
    $eval = /exec\(|compile\(|importlib\.import_module\(/i
  condition:
    $pth or $eval
}
```
不審ファイル拡張子（.exe, .dll, .so）や大きなバイナリを含むパッケージをブロック or 要審査に設定する。
既知の悪意あるバージョンのシグネチャ（例：litellm 1.82.7/1.82.8, telnyx 4.87.1/4.87.2）は即時IOCとしてブロック・探索を行う。該当バージョンがインストールされたCIやホストは全数調査が必要。

3) APT（.deb）向け検出

リポジトリ署名（Release/InRelease）とパッケージ署名（.deb内部のアーカイブ署名）を照合できる仕組みを整備する。TUFやin-totoの導入を検討し、署名の多重化とメタデータ有効期限の厳格化を行うことが推奨されます。
第三者リポジトリの公開鍵（apt-key）を最低限にし、キー所有者と配布元が一致しない場合は自動ブロックする運用を入れる。

4) SIEM／EDR向けのSigmaルール（例）

title: NPM postinstall spawning shell
logsource:
  product: linux
detection:
  selection:
    EventID: 1
    ProcessCommandLine|contains: "npm install"
    ChildProcess|contains_any: ["powershell","cmd.exe","rundll32","regsvr32"]
  condition: selection

上記はサンプル。実運用ではプロセスツリーとネットワーク接続の相関で誤検知を低減してください。

予防・封じ込めの実務対策（CI/CD・署名・運用）

署名の改善と短期鍵／キーレス署名：Sigstore（cosign等）やin-totoを用いた短命キー／透明性ログ（Rekor）で署名の信頼性を高め、長期鍵が盗まれても被害を限定する。TUFの採用も検討し、クライアント側でリポジトリの最新性・多重署名を検証する仕組みを作ることが重要です。
CI/CDとトークン管理の硬化：公開トークンのスコープを最小化し、秘密は短期化・ハードウェア保護（HSM／KMS）、Publish権限は複数人承認の運用にする。CIの実行環境は最小権限で外部依存を定期検査する。
SBOM・プロビナンスの運用：SBOMとビルドアテステーション（in-toto）を組み合わせ、ダウンストリームがビルドソースを検証できるようにする。再現可能ビルドを活用し、配布アーティファクトとソースの不一致を検出する。
検出後の対応（IR）：疑わしいパッケージのインストール履歴、CIでのpublishログ、トークン使用ログを迅速に回収し、露見したバージョンのアンインストール／ロールバック、認証情報のローテーション、ネットワーク封鎖、フォレンジック取得を行う。前述のlitellm/telnyxやaxiosの事例では、短時間で改ざんバージョンが公開→隔離されたため、迅速なスキャンとロールバックが被害縮小に有効でした。

まとめと推奨アクション（CISO／開発責任者向け）

・攻撃手口は“正規の公開経路を悪用する”ため、単なるリポジトリスキャンだけでは不十分です。CI/CDと署名プロビナンスの一体的な強化が必須です。

・まずは内部での影響範囲特定（該当バージョンの存在、CIジョブのログ、トークン露出の有無）を行い、疑わしいホストは即時隔離、ログを保全してください。

・短期的実務投資優先順位（例）：1) 2段階認証＋フィッシング耐性（ハードウェアキー）をメンテナ全員に必須化、2) CIトークンの最小権限化とローテーション自動化、3) SBOM＋in-toto/Sigstoreの導入、4) SIEM+EDRでの上記シグネチャ実装、5) インシデント演習で供給連鎖シナリオを検証。

本稿で示した検出シグネチャ例と運用チェックリストを起点に、自組織のソフトウェア配布経路を可視化し、継続的な脅威ハンティングと自動化を回してください。