「SLSA証明付きでもマルウェア混入って、何を信じればいいでしゅか?」
「Red Hat従業員のGitHubが乗っ取られて、コードレビューも素通りって怖すぎでしゅ……」
うちもnpm依存だらけでしゅ……どこから手をつければいいんでしゅか?
ふふふ、サプライチェーン攻撃は「上流の信頼」を前提にしない設計が要るな。今回の手口を知れば、自社で削るべき盲点が見えるぞ。
本記事ではRed Hat関連npmパッケージへのMiasma混入事件と、TeamPCP系マルウェアの広がり、開発組織が取るべき防御強化策を整理します。
- @redhat-cloud-services配下32本以上のnpmパッケージにMiasmaマルウェアが混入、週間ダウンロード約8万件に影響
- Red Hat従業員のGitHubアカウント乗っ取り、オーファンコミット直接プッシュでコードレビューを回避
- OIDCで取得した正規トークンと有効なSLSA Provenance付きで公開、SBOMや署名検証だけでは防げない事案
読み終える頃には、SLSA時代でも通用するnpm依存管理の見直しポイントが手に入ります。
目次
Miasma混入事件の中身
まずはWiz Researchが2026年6月1日に公表した事実関係を整理します。
従業員GitHub乗っ取りからSLSA署名偽装までの一連の流れ
攻撃者はRed Hat従業員のGitHubアカウントを侵害し、frontend-componentsやjavascript-clientsなど複数のRedHatInsights傘下リポジトリへ、レビューを通さない「オーファンコミット」を直接プッシュしました。
その上でGitHub Actionsの`id-token: write`権限を悪用し、npm公開用OIDCトークンを取得して有効なSLSA Provenanceを付けたままMiasma入りパッケージを公開しています。
Miasma自体は2026年5月にTeamPCPがオープンソース公開した「Mini Shai-Hulud」を流用したもので、表面の名称をDune系からギリシャ神話系に置き換えただけで中身はほぼ同一です。
新機能としてGCPとAzureのクレデンシャル収集が追加され、感染ごとに一意のキーで暗号化されたペイロードを生成するためハッシュベースの検出は通用しません。
事件の主要数値は以下のとおりです。
| 項目 | 内容 |
|---|
| 発覚日 | 2026年6月1日(Wiz Research) |
| 対象 | @redhat-cloud-services配下32本以上 |
| ダウンロード | 週間約8万件 |
| 侵入経路 | Red Hat従業員GitHubアカウント乗っ取り |
| マルウェア | Miasma(Mini Shai-Hulud派生、GCP/Azureクレデンシャル収集) |
正規アカウントから正規署名で出されたら、見抜きようがないでしゅ……。
そこが本質だ。鍵は「コミット履歴の正しさ」と「公開フローの監査」だな。署名は出発点であってゴールではない。
開発組織が取るべき防御強化
本件はSBOM整備やSLSA署名確認だけでは止められない点が、運用上もっとも痛い部分です。
依存導入のレビューと公開フローの監査を二重化する
まず実施すべきは、過去30日間で@redhat-cloud-services配下のパッケージを取り込んだ開発端末・CI/CD環境を洗い出し、GitHubトークンやクラウド認証情報を強制ローテーションすることです。
そのうえで、npm依存はバージョンの固定化と整合性チェック(npm install –ignore-scripts、npm audit signatures)を組み合わせ、postinstallスクリプトの実行を抑止する運用が有効です。
OSS公開側に対しては、メンテナアカウントへのハードウェアキーMFA必須化、保護ブランチ+必須レビュー設定、リリース署名と公開ワークフローの分離が再点検対象になります。
SLSA Provenanceは強力な仕組みですが、メンテナのGitが侵害されればフロー全体が汚染されるため、コミット履歴の異常検知も並行して導入する必要があります。
具体的な対策をまとめると次のとおりです。
- @redhat-cloud-services配下の依存を棚卸しし、影響バージョンを使ったCI/CD環境はクレデンシャルを総入れ替えする
- npm依存は許可リスト方式で管理し、postinstallスクリプトの実行を制御するサンドボックスを導入する
- 自社OSSではメンテナにハードウェアキーMFAを義務化し、保護ブランチ・必須レビュー・タグ署名を組み合わせる
- 公開ワークフロー側のOIDCトークン権限を最小化し、`id-token: write`を持つジョブの変更には別承認者をつける
OIDC便利だから、ついつい広めの権限で組んじゃってるでしゅ……。
そこを攻撃者が狙っている。今回の事件を教材にして、ワークフロー権限の見直しを通せば、社内説明にも説得力が出るぞ。
まとめ:SLSAの先にある「人と権限」の管理
Miasma事件は、SLSA Provenanceや署名検証といった最新のサプライチェーン防御がそろっていても、メンテナアカウントとワークフロー権限が崩れれば容易に突破できることを示しました。
npm依存の棚卸し、postinstallスクリプト制御、メンテナ側のハードウェアキーMFA、OIDC権限の最小化を組み合わせ、「人と権限」を中心に据えた防御へ進める必要があります。
サプライチェーン攻撃が高頻度・高巧妙化する2026年において、開発組織の足腰を強くする実務はますます重要度を増しています。
こうしたDevSecOps領域の実装に挑みたい方は、ぜひセキュリティフリーランス案件で多様な現場を経験してみてください。
参考: Wiz Blog「Miasma: Supply Chain Attack Targeting RedHat npm Packages」 / Microsoft Security Blog「Preinstall to persistence: Inside the Red Hat npm Miasma credential-stealing campaign」