GitHub上に、あるソフトの名前とロゴを勝手に使った“そっくり品”が置かれ、しかも中身にはマルウェアの警告まで出た――そんな話が、開発者本人のブログで明かされました。しかも著者はすぐに通報したのに、3週間たっても GitHub からまともな返答がなかったと言います。単なる個人の愚痴に見えるかもしれませんが、オープンな配布基盤がどこまで責任を持つのか、そして被害が出る前に止められるのか、というかなり重い問題を含んでいます。しかも最後には、状況を動かしたのが別の経路だったことまで書かれていて、後味の悪さが残ります。
この話の中心にあるのは、Easy Data Transform というデータ整形ソフトの“偽装版”です。著者によると、2026年8月31日、顧客から「GitHubでこのソフトの模倣品を見つけた」とメールが届きました。著者はそのページへの直接リンクは貼っていませんが、スクリーンショットを見ると、自社製品の名前とロゴが無断で使われていたそうです。本人は同じ日に GitHub に imitation として報告しました。
ところが、その後さらに話が悪化します。著者の同僚がリポジトリに含まれる Mac 向けの .dmg ファイルを VirusTotal でスキャンしたところ、かなり多くのマルウェア警告が出たといいます。さらに Isobuster というツールで調べると、その .dmg の背景画像まで差し替えられていて、その新しい画像は「マルウェアの警告を無視してダウンロードしろ」と促す内容だったとのことです。著者はこの追加情報も 9月10日に GitHub へ報告しました。
しかし 9月23日時点で、GitHub からの反応は最初の自動返信以外なかったと著者は書いています。つまり、通報から23日間、実質的には何も進んでいない。著者は「これはひどい。GitHub はもっとまともにやるべきだ」とかなり強い言葉で批判しています。次に何をするべきか分からないとも述べていて、DMCA の削除要請を出すべきか考えている様子でした。
著者はまた、実際にこの .dmg を落とすのは、Easy Data Transform のライセンス料を払いたくない人くらいだろうとも書いています。そういう人に同情はしないが、自分の労力を悪用されるのは嫌だ、という感情も率直です。そして最後に、「ソフトはできるだけベンダーから直接ダウンロードすべきだ」と注意を添えています。
ところがこの投稿が Hacker News のトップに出ると、状況は急に変わります。著者は 2026年9月24日の更新で、記事が Hacker News のフロントページに載ってから約10分後に、GitHub がようやく問題のページを削除したと報告しました。本人はそれを「もちろん偶然だろう」と皮肉交じりに書いています。コメント欄でも同じ見方が共有され、別の投稿者からは自分たちも似た経験をしたという声が出ていました。GitHub はすぐに認識はしたが、その後は何も起きなかった、という話です。
この件でいちばん気になるのは、問題が「見つけにくかった」わけではないことです。著者の説明が事実なら、無断でブランド名とロゴを使い、しかもファイルを調べればマルウェア警告が出る。さらに背景画像まで、警告を無視させる方向に細工されていた。ここまで材料がそろっていれば、プラットフォーム側が機械的にでも止められそうに思えます。なのに、最初の自動返信以外は3週間以上動かなかった。ここに、GitHubの審査・対応体制への不信が出ています。
私は、この種の遅さは「少し不便」では済まないと思います。被害が拡大するまで放置されるからです。偽ソフトは、見た目だけなら一瞬で本物に見えます。名前とロゴが一致していれば、検索結果やリンク経由で来た人は疑わないかもしれない。しかも今回のように“ダウンロードしたくなる文言”まで入っていると、慣れていない利用者ほど踏みやすい。つまり、対応の遅れは単なる事務遅延ではなく、利用者を危険なファイルに近づける時間そのものを伸ばしてしまう。そこが重いです。
更新部分でいちばん皮肉なのは、GitHub が重い腰を上げたタイミングです。著者によれば、記事が Hacker News の front page に出てから約10分で削除された。偶然だと本人は書いていますが、文脈から見れば、外から見られていることが強い圧力になったのはかなり自然です。コメントでも「HNのトップに行くとGitHubは動く」という受け止め方が出ていて、これは単なる気分の問題ではなさそうです。
私はここに、プラットフォーム運営の優先順位の歪みが見えると思います。平時の通報は後回しになり、騒ぎが大きくなると急に早い。もし本当にそうなら、守るべき順番が逆です。困っている小さな開発者ほど、SNSで拡散する力も、法務を振り回す力もない。だからこそプラットフォームに頼るのに、そのプラットフォームが「話題になった案件」から処理するなら、弱い側ほど不利になります。コメント欄に同種の経験談が出ているのも、その不信が個人の被害妄想ではないことを示しています。
著者は「できるだけベンダーから直接ダウンロードしてほしい」と書いています。これは当然の助言ですし、利用者側も守るべき基本です。ただ、今回の話をその一言で終えるのは少し違うとも感じます。なぜなら、問題はユーザーの注意不足だけではなく、検索・配布・信頼の仕組みが複数の地点で壊れうることだからです。偽ソフトはGitHubに置かれ、検索で見つかり、見た目を整え、マルウェアを含む。個人が「怪しいからやめよう」と思える前提は、実はかなり脆い。
特にソフトウェア配布では、正規品らしく見えるものが検索結果に混ざると厄介です。買う側は値段や公式サイトを確認できても、急いでいると細部を見落とします。しかも今回のように、正規製品の名前とロゴを使われたら、識別は一気に難しくなる。私は、ここで必要なのは利用者教育だけではなく、配布プラットフォーム側の“即時停止”に近い仕組みだと思います。疑義が濃いものは先に止め、あとで争えばいい。誤検知の問題はあるにせよ、少なくとも今回のようなケースは、先送りの方が明らかに危ないです。
著者の文面から伝わるのは、単に怒っているというより、「自分の作ったものを悪用された」ことへの強い嫌悪感です。これはよく分かります。ソフトウェアの作者にとって、名前やロゴは看板であり、信用そのものです。それを無断で使われたうえに、実際には危険なファイルをばらまかれると、被害は見えにくい形で広がります。将来的には「そのソフト、危ないらしい」と誤解されるかもしれないし、顧客との関係も傷つく。しかも元の作者がその後始末まで背負わされる。
私は、この問題は単なる著作権侵害より少し厄介だと思います。なぜなら、模倣品は“ただの盗作”ではなく、信用の貸し借りを悪用するからです。ユーザーはロゴや名前に安心してしまう。GitHubのような場所にあると、なおさらです。だからこそ対応が遅いと、被害はファイル単体にとどまらず、正規の製品ブランドにも傷が残る。著者が苛立つのは、金銭的な損失だけではないはずです。自分の仕事に乗っかって、他人が危険なことをする――その構図自体が腹立たしいのだと思います。
参考: Github has not removed malicious imitation software after 3 weeks
