GitHubに正規OSSを擬装したマルウェア配布リポジトリ約1万件 — fork扱いされず検索結果に紛れ込む

「フォークではない複製」が偵察網をすり抜ける #

開発者の Orchid 氏が、GitHub 上で 正規 OSS を丸ごと複製したうえでバックドアやマルウェアを仕込んだリポジトリ約 1 万件 を確認したと報告した。手口の核心は、git clone した内容を git push で別 owner / 別リポジトリ名として作り直す点にある。GitHub 内部の fork ネットワークから完全に切り離される ため、UI 上には「forked from ...」の表記が出ず、依存関係グラフのフォーク横断スキャンにも引っかからない。たとえ運営側が元プロジェクトを汚染リストでフラグしても、コピー側のリポジトリは独立した「正規プロジェクト」として残り続ける。

検索結果を汚染する SEO 型サプライチェーン #

注目すべきは、攻撃者が star や fork の数より GitHub 検索のキーワード一致と更新日 を狙っている点だ。README の文章、トピックタグ、コミット履歴を元プロジェクトと同じ構造で複製し、最新タイムスタンプを上書きすることで、検索結果の上位や Trending のカテゴリ別タブに紛れ込ませる。pip install / npm i / go get のような コマンドを Stack Overflow や AI の回答からそのままコピーする開発者 が直撃の被害者になる。typosquat (reqeusts のような綴り違い) の進化形でありながら、綴りそのものは正規と同一なのが厄介な点だ。

防御は「リポジトリ URL を見ない癖」を捨てるしかない #

検索結果のリンクをクリックする前に org 名と historical commit graph を一度確認する だけで多くの罠は外せる。README のロゴが正規でも、コミット履歴に元のメンテナの GPG 署名や CI バッジが無ければ複製を疑う価値がある。組織としては社内プロキシで github.com/{org}/... の owner ホワイトリスト化、Renovate / Dependabot の自動 PR で公式 org のみを許可する設定が現実的だ。検索結果の 1 位がいつでも正解とは限らない時代に、開発者の 「何を import するか」の最終判断責任 が、生成 AI からの貼り付けコード時代にいよいよ重くなっている。