正規SLSA provenance付きワーム出現：署名が証明しないもの

2026年5月11日、npm（JavaScriptの標準パッケージレジストリ）で配布される@tanstack/*系列42パッケージ、84バージョンが自己増殖型ワーム「Mini Shai-Hulud」に侵害された[2][3]。攻撃者はTanStackのGitHub Actionsワークフローを乗っ取り、正規のビルドパイプラインを通じて悪性パッケージを公開した。ここで運用担当者が見過ごせないのは、この悪性パッケージにSLSA（Supply-chain Levels for Software Artifacts、ソフトウェア供給網のセキュリティ成熟度を段階評価する仕様）Build Level 3のprovenance（来歴証明書）が正規に付与されていた点である[1]。署名やprovenanceが付いていれば安全という運用上の思い込みが、初めて実例で崩れた。本稿では侵害の技術的連鎖と、SLSA自身が公表した「証明できる範囲・できない範囲」の整理をもとに、依存パッケージを取り込む側が設計すべき検証の多層化を論じる。

予備知識

• サプライチェーン攻撃: 標的を直接攻めず、標的が利用するライブラリやビルド工程を侵害して間接的に侵入する攻撃
• CI/CD: コードの統合からビルド・配布までを自動化する仕組み。GitHub Actionsはその代表例
• OIDCトークン: CI実行中のジョブが「自分は正規のビルドである」と外部サービスに証明するための短命な認証情報
• Sigstore: OSS向けの署名基盤。ビルド成果物に「どこで・何から作られたか」の証明書を発行する

セキュリティ

Check Point VPN IKEv1バイパス：Qilinランサム侵入と緊急対策

すでに廃止されたプロトコルを使い続けることの代償がランサムウェア侵入として現れた。CVE-2026-50751（CVSS 9.3）はCheck Point Remote Access VPN / Mobile Accessが、廃止済みのI[…]

Mini Shai-Huludとは何か——TanStackなど42パッケージを侵害した自己増殖型ワーム

Mini Shai-Huludは、侵害したnpmパッケージを踏み台にして次の依存先へ自動的に拡散する自己増殖型サプライチェーン攻撃である[2][3]。初動の対象は@tanstack/系列42パッケージ84バージョンだったが、48時間以内に@mistralai/や@uipath等を含む170以上のパッケージ、403の悪性バージョンへ拡大し、npmとPyPIの両レジストリにまたがった[2]。影響パッケージの累計ダウンロード数は5億1800万件規模に達する[2]。この事案には脆弱性番号CVE-2026-45321が採番され、CVSSスコアは9.6（Critical）である[2]。攻撃を追跡したStepSecurityは、脅威アクターを「TeamPCP」と呼称し、2026年3月のAqua Security製Trivyスキャナー侵害、同年4月のBitwarden CLI npmパッケージ侵害と同一グループの手口とみている[3]。悪性ペイロードはAWS認証情報・GitHubトークン・npmトークン・Vaultシークレット・SSH鍵を窃取し、開発端末には60秒ごとにGitHubを監視する常駐デーモンを設置する機能も確認された[2]。

セキュリティ

Oracle PeopleSoft ゼロデイ：100組織侵害とERPパッチ戦略

Oracleのセキュリティアドバイザリが公開される2週間前から、攻撃者はすでに学校のネットワークを荒らし回っていた。米国のサイバー犯罪グループUNC6240（ShinyHunters）は、Oracle PeopleSoft PeopleT[…]

なぜ正規の署名を得られたのか——GitHub Actionsの信頼境界の悪用

攻撃の起点はTanStack/routerリポジトリへの偽装アカウントからのフォークとプルリクエストだった[3]。このプルリクエストはpull_request_targetトリガーで動くワークフローを起動させた。pull_request_targetはフォーク側のコードをベースリポジトリの権限とシークレットを持つ実行コンテキストで動かしてしまう既知の設定ミスパターンで、業界では「Pwn Request」と呼ばれる[3]。攻撃者はここでGitHub Actionsのキャッシュを汚染し、ビルド実行中のランナープロセスのメモリからOIDC（OpenID Connect）トークンを直接抜き取った。窃取したトークンでSigstore（OSSの署名基盤）による署名を正規の手順で完了させたため、生成されたprovenance証明書は暗号学的に本物と区別がつかなかった[1][3]。ビルド基盤そのものは何ら改ざんされておらず、Sigstoreは「ビルドプロセスが宣言どおりに動いた」ことを正しく検証していた[1]。

障害

交渉最大の障害は「信頼の欠如」――プロスポーツ労使紛争に学ぶ克服法｜MBAファシリテーション＆ネゴシエーション Day6

MBAファシリテーション＆ネゴシエーション講義ノート Day6/全6回（最終回） この記事でわかること 交渉の障害を3つに分類する視点（論理的構造・認知感情・環境） あるプロスポーツリーグのロックアウト――交渉が決裂に至るメカニズム […]

SLSA provenanceが証明する範囲と証明しない範囲

SLSAの脅威モデルは供給網リスクを9分類し、直接軽減できるのはそのうち一部にとどまる。SLSA自身の事後分析でも、悪意あるソース提供者やタイポスクワッティングなど複数のカテゴリを明示的にスコープ外としている[1]。ビルドプラットフォームは自身の信頼境界の内側で「何が実行されたか」は正確に記録できるが、境界の外にある入力の安全性までは保証できない[1]。さらに重要な指摘として、SLSA公式ブログは今回の証明書を発行したビルド基盤が、実際にはBuild L3が要求する分離要件を満たしていなかったと結論づけている[1]。真にL3水準の分離を備えた基盤であれば、この攻撃経路自体が成立しなかった可能性が高いという[1]。

依存関係を取り込む側が見直すべき検証設計

provenance検証を単体の合否判定として運用すると、今回のような正規署名付き悪性パッケージを素通りさせてしまう。まず、pull_request_targetのようなPwn Request型の設定ミスは、自組織のリポジトリ側でも棚卸しの対象にする必要がある。次に、OIDCトークンの発行範囲を最小化し、ランナープロセスからの読み取りが困難な短命トークン運用に寄せる設計が有効である。加えて、SBOM（Software Bill of Materials、ソフトウェア部品表）と既知の侵害指標を突き合わせる継続的スキャン、バージョン固定とlockfile検証、依存追加時の人手レビューを組み合わせた多層防御が、provenance単体への過信を補う現実的な運用になる[1][3]。

よくある質問（FAQ）

Q1. SLSA Build L3のprovenanceが付いていれば、そのnpmパッケージは安全と判断してよいか。
断定できない。provenanceはビルド出所と改ざんの有無を証明する仕組みであり、ソースコード自体の安全性やビルド設定の妥当性までは保証しない。

Q2. pull_request_targetトリガーの何が危険なのか。
フォーク側のコードをベースリポジトリの権限とシークレットを持つ実行コンテキストで動かしてしまう設定ミスで、業界では「Pwn Request」と呼ばれる既知の攻撃パターンである。

Q3. 依存パッケージのCI/CDが侵害された場合、利用側はどう検知すればよいか。
SBOMと既知の侵害指標を突き合わせるスキャン、OIDCトークンの発行範囲と有効期限の監査、バージョン固定とlockfile検証を組み合わせた継続的な点検が現実的な検知手段になる。

まとめ

Mini Shai-Huludが示したのは、SLSA provenanceが「ビルドが宣言どおり動いた」ことの証明であって、「そのビルドの中身が安全」の証明ではないという線引きである。攻撃者はビルドパイプラインを乗っ取ることで、この境界の外側から正規の署名を得た。依存パッケージを取り込む側は、provenance検証を唯一の合否判定にせず、SBOM突き合わせ・トークン権限監査・lockfile検証を含む多層の点検体制として設計し直す必要がある。次回の依存追加やCI/CD権限のレビュー時には、自組織のワークフロー設定にPwn Request型の穴がないかを確認することが実務上の第一歩になる。

出典