npm Trusted Publishing の登録先を npm trust list で点検する（SlugFest 事例）

何が起きたか

• Bloom Security が報告した問題で、通称「SlugFest」。メンテナーの認証情報やアカウントが侵害されていなくても、第三者が新バージョンを公開できた。
• 条件は「Trusted Publishing を登録したが、まだ一度も公開に成功していない」状態で、登録先リポジトリや所有者アカウントが改名・移管・削除されたこと。第三者が同じ所有者名・リポジトリ名でリポジトリを作り、ワークフローのファイル名を登録内容と合わせれば判定を通りえた。
• GitLab 連携の同機能も同様とされる。影響パッケージは 1,500 件超（名称は非公表）、累計ダウンロード 1,000 万回超と報告されている。
• GitHub（npm の運営元）は報告から約 4 か月後、作成から 48 時間以内に一度も公開に成功しなかった設定を失効させる対策を入れた。
• provenance（来歴証明）は第三者のリポジトリを出所として Sigstore で正しく署名されるため、「署名があるか」だけ見るツールでは有効と表示される点も指摘されている。

自分のパッケージでやること

1. 登録先を確認する: npm trust list <パッケージ名> で、登録されたリポジトリとワークフローが今も自分の管理下を指しているかを見る。
2. 設定したらすぐ初回公開する: 登録と最初の公開の間を空けない。公開が成功すると以降は数値 ID などで固定される前提なので、宙ぶらりんの期間を作らない。
3. 改名・移管したら再設定する: リポジトリや Organization の名前を変えたり移管したりしたら、Trusted Publishing の設定を作り直す。
4. リポジトリを消す前に設定を外す: 同じ名前で作り直す予定がないなら、削除の前に Trusted Publishing の登録を解除する。
5. 使っていない設定を棚卸しする: 「試しに登録したが結局公開していない」パッケージがないか洗い出す。

依存する側でやること

• provenance を確認するときは、署名の有無だけでなく、出所のリポジトリが想定どおりかまで照合する（例: npm view <pkg> --json の来歴情報や npmjs.com の Provenance 表示でリポジトリ名を見る）。
• AI エージェントが人の確認なしに依存を追加・実行する運用では、この種の「正規の署名付き」悪性バージョンがそのまま入りうる。依存パッケージの「クールダウン」設定（minimumReleaseAge / min-release-age） のような公開直後のバージョンを避ける設定と組み合わせる。

注意点

• 修正は「48 時間以内に公開しなかった設定の失効」で、既存の設定がすべて安全になったわけではない。登録先の文字列が今も正しいかは自分で確かめる。
• npm trust サブコマンドの細かいオプションは npm のバージョンで変わりうるので、npm help trust で手元の版を確認する。

出典

• @MalwareBibleJP · 2026-10-18
• Bloom Security「SlugFest」: bloom.security