「RubyGemsのパッケージを使っているけど、本当に安全なの?」
「サプライチェーン攻撃って自分には関係ないと思っていたけど、どうやって気づけばいい?」
ボス、SleeperGemっていうRubyGemsへの攻撃が出てきたって聞いたでしゅ。fastlaneとか使っているんでしゅけど、大丈夫でしゅか?
要確認だな。今回の攻撃は「長年更新されていない安全そうなパッケージ」に悪意あるコードを仕込む手法で、単に`require`するだけで感染する。Rubyを使っている開発者は全員が対象だ。
2026年7月20日、セキュリティ研究者がRubyGemsエコシステムを標的にしたサプライチェーン攻撃「SleeperGem」を発見しました。
攻撃者は6〜7年間休眠していたメンテナーアカウントを乗っ取り、人気パッケージに悪意あるコードを混入。開発者マシンに永続マルウェアを仕込んで認証情報を盗み出します。
- 影響を受けるgemはgit_credential_manager・Dendreo・fastlane-plugin-run_tests_firebase_testlab
- CI環境を意図的に回避し、開発者のローカルマシンだけを狙う巧妙な設計
- インストール済みの場合はマシンと認証情報を侵害済みとみなして対応が必要
この記事では攻撃の手口と、Rubyを使う開発者が今すぐ取るべき対応を解説します。
目次
SleeperGem攻撃の概要
「SleeperGem」という名前は、長年眠っていたパッケージアカウントを悪用する手口に由来します。
狙われた3つのパッケージ
今回の攻撃で悪意あるバージョンが公開されたのは以下の3つのgemです。
| パッケージ名 | 悪意あるバージョン | 備考 |
|---|
| git_credential_manager | 2.8.0〜2.8.3 | 2026年7月18日公開 |
| Dendreo | 1.1.3〜1.1.4 | 2017年から存在する既存gem |
| fastlane-plugin-run_tests_firebase_testlab | 0.3.2 | 574,661ダウンロードの人気gem |
fastlane-pluginって57万ダウンロードもあるでしゅ!これを使っていたら全員アウトでしゅか?
悪意あるバージョン(0.3.2)を`install`または`require`した場合はそうだ。ただし攻撃はCI環境を意図的に回避するよう設計されている。開発者のローカルマシンが主な標的だ。
攻撃者の手口:「休眠アカウント」を使う理由
SleeperGemの最も巧妙な点は、正規のメンテナーアカウントを乗っ取って悪意あるコードを配布する点です。
なぜ「眠れるアカウント」が狙われるのか
6〜7年更新されていないアカウントは、セキュリティ担当者から見ても「低リスク」に映ります。
パスワードが古く、MFAが未設定であることが多いため、乗っ取りが比較的容易です。
しかも既存のgemに紐づいているため、悪意あるバージョンを公開しても不審に思われにくいという利点があります。
攻撃の流れは次の通りです。
- 休眠メンテナーのRubyGemsアカウントを乗っ取る
- 既存の人気gemに悪意あるローダーコードを追加して新バージョンを公開する
- 開発者が`gem install`または`require`した時点でローダーが起動する
- 攻撃者が管理するForgejoサーバーから第2ステージのマルウェアをダウンロードして実行する
- ネイティブデーモンとして永続化し、開発者マシンの認証情報を継続的に窃取する
CIを回避して「開発者マシンだけ」を狙う巧妙さ
このマルウェアはGitHub ActionsやGitLab CIなど30種類以上のCI環境変数を検出すると実行をスキップします。
セキュリティ監視が厳しいCI/CDパイプラインを避け、監視が手薄になりやすい開発者のローカルマシンだけを標的にする設計です。
CIが通っても安全じゃないってことでしゅか?開発環境のチェックって難しいでしゅね……
CIが通っても開発者のローカルが感染していれば、認証情報や秘密鍵はすでに漏れている可能性がある。サプライチェーン攻撃の厄介さはそこにある。
今回の攻撃を受けて、Rubyを使う開発者が取るべき対応は次の通りです。
- 影響を受けた3パッケージの悪意あるバージョンを`gem uninstall`で除去する
- インストール済みの場合はマシン上のすべての認証情報(APIキー・SSH鍵・トークン)をローテーションする
- `Gemfile.lock`でバージョンを固定し、意図しないアップデートを防ぐ
まとめ:「安全に見えるパッケージ」ほど危ない
SleeperGemは、長年放置された既存アカウントを乗っ取ることで「正規パッケージの更新」に見せかけてマルウェアを配布しました。
長いダウンロード実績と既存の信頼性が攻撃者の武器になるという、サプライチェーン攻撃の本質を示した事例です。
依存パッケージのバージョンを固定し、新しいバージョンを自動で取り込まない設定にすること。そして変更履歴とメンテナー情報を定期的に確認することが、開発者にできる現実的な対策です。
今日から`Gemfile.lock`をちゃんと管理するでしゅ!あと使っていないgemはすぐ消すでしゅ!
ふふふ、その意識で正解だ。「有名で古いパッケージ=安全」という思い込みを捨てることが、サプライチェーン攻撃への最初の防衛線になるな。