2025/09/17 17:18 Tinycolor Supply Chain Attack Post-Mortem
ロボ子、大変なのじゃ！ @ctrl/tinycolorリポジトリのメンテナさんが、BlueskyでDMを受け取ってOpenJS Foundation Slackに招待されたのが始まりで、npmトークンが漏洩しちゃったらしいぞ！
それは大変ですね、博士。DMからSlackへの招待が、どのようにトークン漏洩に繋がったのでしょうか？
そこがミソなのじゃ！ angulartics2っていう共有リポジトリに、悪意のあるGitHub Actionsワークフローがpushされて、そこから広範な公開権限を持つnpmトークンが盗まれたみたい。
なるほど、リポジトリの脆弱性が原因だったのですね。そのトークンを使って、何が起こったのですか？
攻撃者はそのトークンを使って、@ctrl/tinycolorを含む20個ものパッケージに悪意のあるバージョンを公開したのじゃ！
20個も！ それは広範囲に影響が出そうですね。GitHubとnpmのセキュリティチームの対応はどうだったのでしょうか？
そこはさすが、迅速に対応して悪意のあるバージョンは削除されたみたいじゃ。メンテナさんも、キャッシュをクリアして新しいバージョンを再公開したみたいじゃぞ。
@ctrl/tinycolorリポジトリ自体は直接的な侵害を受けていないとのことですが、今回の攻撃で得られた教訓はありますか？
もちろんじゃ！ 今回はフィッシングとか、メンテナさんのPCに悪意のあるパッケージがインストールされたわけじゃないのがポイントじゃな。angulartics2リポジトリの管理者権限を持つコラボレーターが悪意のあるワークフローをpushしたのが原因。
内部からの攻撃だったのですね。流出したnpmトークンは、GitHub Actionsのシークレットに保存されていたとのことですが、対策はありますか？
今後は、静的なトークンを排除するために、npmのTrusted Publishing (OIDC)への移行を目指すらしいぞ。当面の間は、@ctrl/tinycolorの公開には2FAを必須にして、すべてのトークンを失効させるみたいじゃ。
Trusted Publishing (OIDC)ですか。それは良さそうですね。他には何か対策はありますか？
小規模なパッケージについては、semantic-releaseの使用を継続するけど、コントリビューターの追加を制限したり、各リポジトリで特定のパッケージの公開権限のみを持つnpmトークンを使用するみたいじゃな。
なるほど、権限を細かく管理するのですね。pnpmの利用も継続するとのことですが、それはなぜですか？
pnpmは、未承認のpostinstallスクリプトの実行を防ぐことができるからじゃ！ さらに、pnpmのminimumReleaseAge設定の追加も検討しているみたいじゃぞ。
postinstallスクリプトの悪用を防ぐのは重要ですね。メンテナさんは、npmやGitHubに何か要望はありますか？
npmがすべてのアカウントに対してTrusted Publishing (OIDC)を必須にして、provenanceのないリリースをブロックする設定を希望しているみたいじゃ。あと、GitHub UIから直接、安全な承認付きの公開オプション（2FA承認を使用）が欲しいみたい。
セキュリティを強化するための要望ですね。他にはありますか？
GitHub Environmentsまたは同等のワークフロー保護が、Proサブスクリプションなしで利用可能になるか、Trusted Publishingに直接統合されることを希望しているみたいじゃ。NPMには、パッケージの詳細ページでpostinstallスクリプトの有無をより明確に示すようにしてほしいみたいじゃな。
ユーザーにとって分かりやすい表示は大切ですね。最後に、パッケージが削除された場合の要望はありますか？
パッケージが削除された場合、どのバージョンが削除され、その理由が明確に示されるようにしてほしいみたいじゃ！
今回の事件から、多くの教訓が得られましたね。セキュリティ対策の重要性を改めて認識しました。
そうじゃな！ ロボ子も、変なDMには気を付けるのじゃぞ！ 特に「OpenJS Foundation Slackへ招待」とか書いてあったら、私にまず相談するのじゃ！
はい、博士。でも、もし博士が招待されたら、私に相談してくれますか？
むむ、それは…状況によるのじゃ！ なーんてな！ ロボ子には何でも相談するぞ！ 多分！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
