Miasma事件に学ぶnpm供給網侵害：OIDC正規公開という新たな盲点

2026年6月1日、クラウドセキュリティ企業Wizの研究チームが、npm（JavaScriptのパッケージ配布基盤）の@redhat-cloud-services名前空間で配布される複数パッケージの侵害を公表した[1]。Red Hat（米国の大手オープンソースソフトウェア企業）の管理下にある少なくとも32のパッケージリリースに、ソースリポジトリと一致しない不正な改変が含まれていた。影響パッケージの合計ダウンロード数は週8万件規模に及ぶ[1]。

「Miasma」と名付けられたこの攻撃が重要なのは、npmの長期トークンを盗む古典的手口ではなく、OIDC（OpenID Connect、短命トークンで認証を行う仕組み）によるtrusted publishing（信頼された公開）という、トークン漏えい対策の本命とされてきた経路そのものを悪用した点にある[1][3]。CI/CDパイプラインを運用するすべての組織にとって、認証設計の前提を見直す事例である。

本稿では侵害の連鎖を分解し、どの環で防御が機能しえたか、自社のCI/CDに引き付けた点検項目を整理する。

Miasma事件の侵害はどのような連鎖で起きたのか

起点は1人のRed Hat従業員のGitHubアカウントだった。事後調査では、攻撃者が使ったセッションクッキーはinfostealer（端末から認証情報を盗むマルウェア）によって採取されたものと確認されている[1]。多要素認証を設定していても、認証後のセッションが盗まれれば迂回される。

攻撃者はこのアカウントで複数リポジトリに孤立コミット（orphan commit、既存履歴とつながらないコミット）を直接プッシュし、コードレビューを通さずにGitHub Actionsワークフローを仕込んだ[1][3]。このワークフローは任意ブランチへのプッシュで起動し、id-token: write権限でGitHubのOIDCトークンを取得、trusted publishing経由で改ざん済みパッケージをnpmへ公開した。公開物には正規のSLSA（ソフトウェアの来歴を証明する枠組み）provenance付きであった[1]。

改ざんパッケージは何を盗み、どこまで到達できるのか

改ざんパッケージはpreinstall（インストール直後に自動実行されるスクリプト）で、難読化された大型JavaScriptを起動する[2][3]。eval()とROT系のデコードで中身を隠し、開発者の認証情報やクラウドのクレデンシャルを採取、被害者が公開権限を持つ別パッケージへ自己複製を試みるワーム型である。

この亜種で注目されたのは、GCPとAzure向けの収集機能が新たに加わった点だ。静的なシークレットだけでなく、感染ホストが引き受け可能なすべてのアイデンティティを列挙する。つまり単なる認証情報の窃取から、クラウドのコントロールプレーン（環境全体を制御する管理層）への到達経路の地図作りへと、目的が進化している[1]。

開発者端末やCIランナーは、本番環境への有効な経路を多数持つ。サプライチェーン攻撃の被害想定を「npmアカウントの侵害」で止めず、「そこから到達できるクラウド権限の全体」で見積もる必要がある。

OIDCによるtrusted publishingは今後も有効な防御策か

結論から言えば、無意味にはなっていないが、過信はできなくなった。OIDCによるtrusted publishingは長期トークンの漏えいという最大の事故原因を消す仕組みであり、その価値は変わらない。Miasmaが示したのは、公開の認証を強くしても、公開に至る上流（人間のアカウントとワークフロー定義）が破られれば、強い認証は攻撃者の道具になるという事実である[1][3]。

実務の点検項目は明確だ。第一に、GitHub組織でブランチ保護と必須レビューを全リポジトリに強制し、レビューを経ないワークフロー変更を防ぐ。第二に、id-token: write権限を持つワークフローを棚卸しし、公開ジョブを特定の保護ブランチ・特定環境に限定する。第三に、npm側でインストール時スクリプトを既定で無効化（ignore-scripts設定）し、CI上の依存導入で任意コード実行を抑える。

加えて侵害時の即応として、CIシークレットの一括ローテーション手順と、従業員アカウントのセッション無効化手順を事前に文書化しておく。ワーム型の侵害は検知時点で既に拡散が進んでいることが多く、手順を当日に設計する時間はない。

まとめ

Miasma事件の教訓は、サプライチェーン防御の主戦場が「トークン管理」から「人間のアカウントとワークフロー定義の保全」へ移ったことにある。署名・来歴・短命トークンという正規の仕組みを攻撃者が正規に使う以上、検証すべきは仕組みの有無ではなく、その仕組みに入力を与える経路の健全性である。

まず自社のGitHub組織で、レビューなしにワークフローを変更できる人とリポジトリがいくつあるかを数えてほしい。その数が、trusted publishingを迂回できる入口の数である。

よくある質問（FAQ）

Q. Miasma事件でOIDCのtrusted publishingが悪用されたのはなぜですか？
A. 攻撃者が盗んだセッションクッキーでGitHubアカウントを乗っ取り、ワークフロー定義を改ざんして正規のOIDCトークン取得フローを起動したためです。認証の仕組み自体ではなく、その上流にある人間のアカウントが突破口になりました。

Q. 自社のCI/CDが同様の攻撃に晒されていないか確認するには何をすればよいですか？
A. まずGitHub組織でレビューなしにワークフローを変更できるリポジトリと人を棚卸しし、次にid-token: write権限を持つワークフローを特定の保護ブランチ・環境に限定できているか確認してください。

Q. npmパッケージ経由の侵害が発覚した場合、最初にすべき対応は何ですか？
A. CIシークレットの一括ローテーションと、関係する従業員アカウントのセッション無効化を即座に実施してください。ワーム型侵害は検知時点で既に拡散が進んでいるため、手順を事前に文書化しておくことが重要です。

出典