【ITニュース解説】New stricter rules from GitHub for code packages after security investigation
2026年10月14日に「Dev.to」が公開したITニュース「New stricter rules from GitHub for code packages after security investigation」について初心者にもわかりやすく解説しています。
ITニュース概要
GitHubは、攻撃者が放棄されたリポジトリ名を悪用し不正なパッケージ更新を公開できた脆弱性に対処するため、npmパッケージ公開ルールを厳格化した。未検証の信頼公開設定に48時間の有効期限を設け、サプライチェーン攻撃を防ぐ。開発者には設定確認などを促す。
ITニュース解説
GitHubが、ソフトウェアを公開する際のセキュリティルールを強化したという重要なニュースがあった。これは、ソフトウェア開発の世界で非常に広く使われている、ソースコードを管理するプラットフォームであるGitHubと、JavaScript製のソフトウェア部品(パッケージ)を管理する「npm」という仕組みに関わる話だ。
今回の問題は、ソフトウェアが誰によって作られ、誰によって公開されたものかをシステムがどのように判断するか、という点に根差していた。具体的には、GitHubのnpmを通じたパッケージ公開において、「信頼された公開設定」という仕組みがある。これは、あるソフトウェアパッケージが、本当にそのパッケージの正規の所有者によって公開されたものであることをシステムが信頼するための設定のことだ。この設定が正しく機能しないと、悪意のある第三者が、あたかも正規の所有者であるかのように振る舞い、誰もが利用するソフトウェアに不正な変更を加えてしまう危険性がある。
これまで、この「信頼された公開設定」には、セキュリティ上の「抜け穴」が存在していた。この抜け穴は、「リポジトリのアドレス名」の扱いにあった。リポジトリとは、ソースコードや関連ファイルをまとめて管理する場所のことだが、GitHubのシステムは、このリポジトリが誰のものかを識別する際に、そのリポジトリの「名前」に強く依存していた。永続的なデジタル識別子ではなく、一時的に変わりうる「名前」に頼っていたのだ。
この仕組みのせいで、もしあるリポジトリのアドレス名が何らかの理由で使われなくなり、空っぽの状態、つまり「放棄された」状態になった場合、そこには大きな隙が生まれてしまう。巧妙な攻撃者は、この空になったアドレス名を特定し、自分たちがその名前を使えるようにする方法を見つけ出した。そして、そのアドレス名を乗っ取ることで、システムに「自分たちがそのリポジトリの正規の所有者である」と誤解させることができたのだ。
一度システムを騙すことに成功すると、攻撃者は、本来自分たちが所有していないはずのソフトウェアパッケージに対して、あたかも正規の所有者であるかのように「更新」を公開できるようになる。この更新には、悪意のあるコードが含まれている可能性がある。例えば、そのソフトウェアを使う人のコンピューターから情報を盗んだり、別の不正なプログラムをダウンロードさせたりするようなコードだ。このような不正な更新が公開されてしまうと、そのパッケージを信頼してダウンロードした多くのユーザーが、知らず知らずのうちに攻撃の被害に遭う可能性があった。何しろ、これらのパッケージは、すでに多くの開発者や企業に利用されており、高い評判とダウンロード数を持っていたからだ。調査の結果、このような脆弱な状態にあるパッケージが1,500以上も見つかり、それらが合計で1,000万回以上もダウンロードされていたことが明らかになった。これは、広範囲にわたる深刻な問題であったことを示している。
この問題は、セキュリティ専門企業のBloom Securityによって発見され、2026年6月6日にGitHubに報告された。これを受けて、GitHubは迅速に対応し、ソフトウェア公開の仕組みにいくつかの重要な変更を加えることを決定した。
主な変更点の一つは、「検証されていない信頼設定」に対する48時間の有効期限だ。新しく作成された「信頼された公開設定」は、作成されてから48時間以内に一度も成功した公開が行われない場合、自動的にその設定は無効となる。つまり、設定を作っただけでは「信頼」は確立せず、実際にパッケージを公開し、その設定が正しく機能することを確認しなければ、その「信頼」は持続しないということだ。
もし48時間以内に最初の公開が成功すれば、その設定は「永続的」なものとして扱われ、以降は安心してその設定を使ってパッケージを公開できるようになる。しかし、もし何らかの理由でプロジェクトの「識別子」、例えばリポジトリ名やその関連情報などが変更された場合は、再度新しい「信頼された公開設定」プロセスを開始する必要がある。その場合も、また新しい48時間の期限が設けられることになる。これは、リポジトリ名のような「識別子」が変わった際に、古い信頼設定が悪用されるリスクをなくすための措置だ。
さらに、GitHubのnpmは、特定の種類の「自動化されたコードコメントやリクエストプロセス」からの公開リクエストを拒否するようになった。これは、悪意のあるボットや自動化されたツールが不正な公開を行うことを防ぐための追加的な対策である。
これらの変更により、攻撃者が放棄されたリポジトリ名を悪用して、正規の権限なしにパッケージを更新する、といったタイプの攻撃は非常に困難になる。
この変更を受けて、ソフトウェアパッケージを管理している開発者、つまり将来のシステムエンジニアである皆さんも、いくつか注意すべき点がある。まず、現在利用している「信頼された接続」の設定を改めて確認することが求められる。これは、自分のパッケージが安全な状態で公開されているかを再確認する作業だ。
次に、もし自分のリポジトリの名前を変更したり、別の場所に移動させたりした場合は、これまで使っていた「信頼された公開設定」のリンクを一度削除し、新しい設定として再作成する必要がある。これにより、古い設定が悪用されるリスクを排除できる。
そして、自分の管理しているパッケージに、予期しない公開や不審な変更がないかを常に監視することも重要だ。何か異変に気づいた場合は、速やかに確認し、必要に応じて対応することが求められる。これは、日々のソフトウェア開発において、セキュリティ意識を高く持ち続けることの重要性を示している。
今回のGitHubのセキュリティ強化は、ソフトウェアの「サプライチェーン」、つまりソフトウェアが開発され、提供され、利用されるまでの一連の流れの中で、どこに脆弱性が潜んでいるかを常に注意深く見つけ出し、改善していくことの重要性を私たちに教えてくれる。システムエンジニアを目指す上で、このようなセキュリティの動きを理解し、自分の開発プロセスに取り入れていくことは、将来のキャリアにおいて不可欠なスキルとなるだろう。ソフトウェアは人々の生活や社会を支える基盤であり、その安全性を確保することは、開発者一人ひとりの責任である。