GitHubは2026年3月以来、npmのマルウェアを検知してきました。しかし、悪意のあるPyPI、Maven、RubyGems、NuGet、Go、crates.io、PHP Composerのパッケージを取り込んでしまったユーザーには、こうした警告は一切届いていませんでした。GitHubのマルウェア検知が対象としていたのはnpmという単一のエコシステムだけだったからです。この状況が今月変わりました。
GitHubのAdvisory Databaseは現在、OpenSSFのmalicious-packagesリポジトリからマルウェア報告を取り込むようになりました。これはOSV形式で提供される公開フィードで、2023年の開始時点で15,000件を超える報告を抱え、その後も日々増加を続けており、タイポスクワッティング、依存関係の混同を悪用したパッケージ、アカウント乗っ取り、悪意のあるビルド済みバイナリなどを網羅しています。
これまでnpmのデータのみを頼りに動いていたDependabotのマルウェアアラートは、ユーザーがマルウェアアラートを有効にした瞬間から、この8つのエコシステスすべてを情報源として活用するようになります。Dependabot自体は既に3,000万を超えるリポジトリと34以上のパッケージエコシステム全体で稼働しており、この規模を踏まえれば、マルウェア検知パイプラインが今後どれほどの処理能力を求められるかが見えてきます。
8つ別々ではなく、たった1つのインポーターに集約
8つの検知システムを個別に構築していれば、何年もかかっていたはずです。そこでGitHubのチームは、GitHubの既存のインポーターがRubySecやRustSecのアドバイザリを読み込んでいるのと同じ方式で、OpenSSFのフィードを読み込み、レコードをマッピングする単一のインポーターを構築しました。
「正規化という作業は、実際のデータに触れるまでは退屈な話に聞こえます。まず、上流のエコシステム名は必ずしもこちら側の表記と一致しません（リポジトリ側ではPyPIと表記されていても、私たちのデータベースではpipとしています）。OSVのレコードでは影響を受けるバージョンが離散的な値として列挙されている一方、私たちの側では範囲として捉えたいと考えています。さらに、使えるバージョン情報が一切記載されていないレコードも存在します。詳細フィールドは空欄であることが多く、複数のソースが同一のパッケージについて報告している場合には、それぞれの説明文が一つの塊としてただ連結されてしまいます。報告が撤回されるケースもあり、リポジトリには誤りだったと判明したアドバイザリのためにosv/withdrawnというフォルダがまるごと用意されています。つまりインポーターは、あるパッケージが月曜日にフラグを立てられ、水曜日にはそれが否定されるという事態にも対応しなければならないのです」と、GitHubのシニアエンジニアリングマネージャーであるAnkit Kumar Honey氏は記しています。
もう一つ、もう少し分かりにくい問題があります。GitHubがnpmで検出したマルウェアの情報は、既にOpenSSFのリポジトリへと流れ込んでいるのです。そのフィードをフィルタリングせずにそのままインポートすれば、GitHub自身が発行したアドバイザリを堂々巡りで再インポートすることになってしまいます。この問題への対処は、OSVのレコードが持つ発生元のメタデータを利用することで実現しています。「ghsa-malware」というタグが付いたエントリはGitHub発のものと分かるため、新しいフィードのエントリになる前に除外される仕組みです。GitHubが実際のデータでこの仕組みを検証したところ、毎月新たに届くnpm関連の報告の半数以上が、まさにこの「堂々巡り」に該当するものだったことが判明しました。
あえてレビュー工程を省略
GitHubの同僚であるMadison Ficorilli氏は、脆弱性アドバイザリにおける「レビュー済み」が何を意味するかについて解説しています。それは、何かが公開される前に人の手でパッケージのマッピング、バージョン範囲、深刻度をチェックする、というプロセスです。
マルウェアに関するアドバイザリは、このレビュー工程をあえて飛ばして自動的に公開されます。認証情報を窃取するパッケージが何日もレビュー待ちの列に並んでいる状況は、それを仕込んだ攻撃者にとって都合が良いだけだからです。今回新たに変わったのは、こうした未レビューのアドバイザリが直接Dependabotのアラートを発動できるようになった点です。これはこの機能拡張以前には存在しなかった動作です。
上流のフィードが不正なデータを流してきた場合の備え
この仕組みが成り立つのは、上流のフィードがクリーンな状態を保っている場合に限られます。そのためこのパイプラインは、いずれそうではなくなる事態を最初から想定して設計されています。それに備える安全策は3つあります。まず、1回のインポート処理で作成できるアドバイザリの件数には上限が設けられており、これを超えると処理全体が停止し、何も公開されないままチームに通知が飛びます。通常の5倍もの量を求めてくる処理は、単に忙しい日だったというよりも、情報源そのものが侵害された兆候である可能性が高いためです。次に、インポートされたすべてのアドバイザリには、上流のどのコミットに由来するかという出所情報が付与されており、不正なアドバイザリが見つかった場合でも数分でその発生源を追跡できます。そして、各バッチはひとまとまりとして丸ごとロールバックできるため、後になって誰かがデータベースから不正なレコードを一つずつ手作業で選び出す必要はありません。
有効化の方法
「マルウェアアラートはオプトイン方式です。リポジトリ、組織、またはエンタープライズのセキュリティ設定から有効化してください。有効にした瞬間から、Dependabotはお使いの依存関係をAdvisory Database内のマルウェアアドバイザリと照合します。この照合には、既存のアドバイザリに対するバックフィル(遡及チェック)も含まれます」とHoney氏は説明しています。
翻訳元: https://www.helpnetsecurity.com/2026/08/10/github-dependabot-malware-alerts/
