GitHubとPyPIがサプライチェーン攻撃対策に「時間ベースの防御」を導入|セキュリティニュースのセキュリティ対策Lab

投稿日時: 2026年07月29日更新日時: 2026年07月29日

GitHubとPyPI（Python Package Index）は2026年7月、ソフトウェアサプライチェーン攻撃の被害を抑えるための時間ベースの防御機構をそれぞれ導入しました。GitHubは依存関係更新ツールDependabotに、新しいリリースが公開されてから最低3日間はバージョン更新のプルリクエストを作成しないという標準の「クールダウン（冷却期間）」を設定しました。PyPIは、リリースの公開から14日が経過した後は、そのリリースへ新しいファイルを追加することを拒否する仕組みを導入しました。いずれも、悪意あるパッケージが公開されてから発見・削除されるまでの短い時間差を突く攻撃や、公開ツールの侵害によって古い安定版が汚染される攻撃に対抗するものです。過去1年間で両エコシステムがchalk・debug攻撃、s1ngularity作戦、Shai-Huludキャンペーン、GhostActionといった重大な攻撃を相次いで経験したことを受けた対策です。

サマリー

GitHubとPyPIが2026年7月、サプライチェーン攻撃対策の時間ベース防御を導入
GitHub Dependabot：新リリース公開から最低3日間はバージョン更新PRを作成しない標準クールダウン
PyPI：リリース公開から14日超が経過した後は新規ファイルのアップロードを拒否
Dependabotのクールダウンはセキュリティ更新には適用されず、緊急修正は即時に反映
3日間という設定は、リスク回避と最新版追随のバランスから選定
PyPIの14日制限は、公開トークンやワークフローの侵害で古い安定版が汚染されるのを防ぐ狙い
PyPIの制限による影響を受けるプロジェクトは上位15,000件中56件のみと極めて少数
どちらも万能ではなく、ロックファイルやトークンのスコープ制限など多層防御との併用が推奨される

項目	GitHub（Dependabot）	PyPI
導入内容	バージョン更新の標準クールダウン	古いリリースへのファイル追加拒否
期間	3日間（標準）	公開から14日
適用範囲	バージョン更新（セキュリティ更新は除外）	全プロジェクトのリリース
設定変更	1〜90日の範囲で変更・無効化可能	個別の緩和なし（次バージョンへ移行を推奨）
主な狙い	短命な悪性リリースの取り込み防止	古い安定版の汚染（リリースポイズニング）防止
発表時期	2026年7月14日（Changelog）	2026年7月22日（PyPI Blog、実装は7月8日マージ）
影響	標準で全ユーザーに適用	上位15,000件中56件のみが該当

背景――相次ぐサプライチェーン攻撃と「数時間の時間差」

今回の対策の背景には、この1年間でnpm・PyPIなどのパッケージエコシステムを襲った、深刻なサプライチェーン攻撃の連鎖があります。

ソフトウェアサプライチェーン攻撃は、ソフトウェアそのものではなく、開発・運用に使われる外部パッケージや配布経路を標的とする攻撃手法です。攻撃者は、正規のパッケージのメンテナーアカウントや公開トークンを乗っ取り、悪意あるコードを混入させた新バージョンを公開します。多くの開発現場では、依存パッケージの更新が自動化されているため、この汚染されたバージョンが人間やスキャナーの目に触れる前に、数分でビルドパイプラインに取り込まれてしまいます。

これらの攻撃で共通する特徴は、悪性バージョンの生存時間が極めて短いことです。GitHubが2018年から2026年にかけて広く報じられた21件のサプライチェーンインシデントを分析したところ、axios、Solana web3.js、ua-parser-js、Ledger Connect Kitといった著名パッケージの悪性バージョンは、いずれも公開から数時間以内に削除されていました。つまり、更新を数日待つだけで、これらの短命な悪性リリースの大半をインストール前に排除できたことになります。

当サイトでも、TeamPCPによる自己増殖型ワーム「Shai-Hulud」がnpmパッケージ323件へ637件の悪性バージョンを公開し、週間ダウンロード数約1,600万件に影響した事案や、TanStack・Mistral AI・UiPathなどを狙ったMini Shai-Huludキャンペーンを報じてきました。こうした攻撃の頻発が、エコシステム側の構造的な対策を促した形です。

GitHub Dependabotの3日間クールダウン

Dependabotは、依存パッケージの新バージョンを定期的にチェックし、更新用のプルリクエスト（PR）を自動で作成するGitHubの依存関係更新サービスです。更新の手間を減らす一方で、公開されたばかりの危険な新バージョンに開発者を即座にさらす可能性がありました。

GitHubは2026年7月14日、このDependabotに標準のクールダウンを導入しました。Dependabotは、新しいリリースがレジストリ上で公開されてから最低3日間が経過するまで、バージョン更新のPRを作成しなくなります。GitHubは公式ブログで、この仕組みについて「新しいリリースはサプライチェーン攻撃の一般的な侵入口であり、侵害された、あるいは壊れたバージョンが、メンテナーやコミュニティが気づく前に依存関係の更新に到達しうる」と説明しています。数日の遅延を設けることで、悪性バージョンが発見・削除されるための時間を確保し、公開直後の不正なリリースを取り込むリスクを下げる狙いです。

重要な設計として、このクールダウンはセキュリティ更新には適用されません。既知の脆弱性を修正するセキュリティ更新のPRは従来どおり即座に作成されるため、重大な修正が遅延することはありません。あくまで通常のバージョン更新のみが対象です。

3日間という期間は、リスクの高いリリースを回避することと、最新版への追随を維持することのバランスから選ばれています。GitHubは、ユーザーが.github/dependabot.ymlのクールダウン設定を通じて、より短い、あるいはより長い遅延（1〜90日の範囲）を構成したり、機能を無効化したりすることも可能だとしています。この機能自体は2025年7月からオプションとして提供されていましたが、2026年7月の変更により、設定不要の標準動作となりました。従来は開発者が自らオプションの存在を知り設定する必要があったのが、初期状態で有効になったという点が今回の変化です。

PyPIの14日ルール――古いリリースの汚染を防ぐ

PyPIが2026年7月22日に公式ブログで発表したのは、Dependabotとは異なる角度からの時間ベースの防御です。PyPIは、リリースが公開されてから14日が経過した後は、そのリリースへ新しいファイルを追加することを拒否するようになりました。

この制限の狙いは、公開トークンやワークフローが侵害された場合に、古く安定したリリースが汚染される（リリースポイズニング）ことを防ぐ点にあります。従来のPyPIでは、メンテナーは3年前に公開したリリースであっても、後から新しいファイル（wheelなど）を追加できました。これは新しいPythonバージョンへの対応などのために便利な機能でしたが、攻撃者が公開トークンを盗んだ場合、誰もが長年ダウンロードしてきた安定版に、バックドア入りのバイナリを、一切のアラートを発生させずに忍び込ませることができるという危険性を抱えていました。

PyPIのSeth Larson氏（Python Software Foundationのセキュリティ開発者）は、この手口について「我々の知る限り、これはまだ悪用されていない。しかし、攻撃者がそれが可能だと気づいていなかったという以上の技術的な理由はない」と述べ、悪用される前の予防的措置であることを強調しています。この制限により、侵害が発生した際に、リリースの一部のファイルだけが汚染され、残りは無害という「汚染されているとも、されていないとも言えない」曖昧で紛らわしい状態が生じることも防げるとしています。

この変更のきっかけは、2026年3月に発生した人気パッケージLiteLLMとTelnyxの侵害でした。これらはTrivy（Aqua SecurityのGitHub Action）の使用における「ミュータブルな参照」が原因で侵害されました。当初、一部のプロジェクトが公開済みリリースへのファイル追加機能に依存していたため議論は停滞しましたが、PyPIがデータベースを分析した結果、この慣行が稀であることが判明しました。上位15,000パッケージのうち、元のリリースから14日を超えてPython 3.14対応のwheelをアップロードしていたのは、わずか56件だけでした。PyPIのセキュリティエンジニアMike Fiedler氏がPyCon US 2026のPackaging Summitでこの変更を提案し、おおむねの合意を得たうえで、Larson氏がパッチを2026年7月8日にマージしています。

両者に共通する限界――時間は「真正性」を保証しない

GitHubとPyPIの双方が、これらの時間ベースの防御が万能ではないことを明確にしています。

GitHubは、Dependabotのクールダウンが長期的な侵害に対しては限界を持つと指摘しています。3日間経過したパッケージは「3日間public上で生き延びた」というだけであり、その来歴、ビルドプロセス、メンテナーの正当性、実行時の挙動が自動的に証明されたわけではありません。時間は、メンテナーやレジストリ、スキャナー、利用者が不正なリリースを発見するための「窓」を作り出しますが、誰かが必ず発見することを保証するものではありません。GitHubは、より長期的な侵害への対抗策として、依存関係を固定するロックファイルの使用、スコープを制限したトークンの利用、CIにおける不要なインストールスクリプトの無効化を併せて推奨しています。

PyPIについても、Larson氏は、14日ルールにはまだ明確なセマンティクス（「新規ファイルを受け付けなくなったリリース」の定義）が存在せず、リリースの状態を確認するAPIも提供されていないため、利用者はこの動作にまだ依存すべきではないと注意を促しています。これらの正式なルールは、PEP 694で標準化される「Upload 2.0 API」と「Staged Previews」の導入後に定義される予定です。

サーバーサイド・ネットワークの実務経験から補足すると、これらの対策は「タイミング制御」であって「真正性の判定」ではないという点が本質です。パッケージが3日間や14日間問題を起こさなかったという事実は、そのパッケージが安全であることの証明にはなりません。あくまで、悪性リリースの大半が短命であるという統計的な傾向を利用して、被害に遭う確率を下げるリスク低減策として理解する必要があります。

エコシステム全体に広がる「クールダウン」の潮流

時間ベースの防御は、GitHubとPyPIに限らず、パッケージエコシステム全体に急速に広がっています。

近年、pnpm、npm、Homebrew、そしてVS Code 1.123が、いずれも数週間のうちに相次いでクールダウンの仕組みを導入しました。npmは2026年5月に、パッケージを保留状態に置き、メンテナーによる二要素認証の承認を経て初めて公開される「ステージド・パブリッシング」を導入しています。これは公開トークンが漏洩しても悪意あるパッケージの配布を困難にし、更新版が登録される段階で攻撃を食い止めることを狙ったものです。当サイトでもGitHubによるnpmサプライチェーン攻撃防御の強化（二要素認証の必須化・トークンの短期化）を報じてきました。

英国のNCSC（国家サイバーセキュリティセンター）も、この方向性を支持しています。同機関のオリー・ホワイトハウスCTOは、サプライチェーン攻撃について「実際のところ、これらは数時間から数日という短期間で検出されており、多くの組織は分単位の更新を必要としていない」と述べ、公開リポジトリからの更新パッケージを取り込む前に時間ベースの遅延（コードのクールダウン期間）を設けることを推奨しています。

情報システム部門・開発チームが取るべき対応

これらのエコシステム側の対策を踏まえ、開発チームや情報システム部門が取るべき対応を整理します。

第一に、標準設定を活かしつつ自社に合わせて調整することです。GitHub Dependabotのクールダウンは標準で有効になったため、多くの組織は特別な設定なしにこの保護を受けられます。そのうえで、より慎重な運用を求める場合は、.github/dependabot.ymlでクールダウン期間を延長する(コミュニティでは7日を推奨する声もあります)ことを検討できます。逆に、セキュリティ更新は即座に反映される設計であるため、緊急パッチの適用が遅れる心配はありません。

第二に、インストール層での別途の対策です。Dependabotのクールダウンはあくまでバージョン更新PRの作成タイミングを制御するものであり、npm installやpip installといったパッケージマネージャーの直接実行には及びません。CI/CD環境でパッケージを直接インストールする場合は、パッケージマネージャー側でも最小リリース経過日数（release-age）のポリシーを設定し、インストール層でのクールダウンを別途構成する必要があります。

第三に、時間ベースの防御を多層防御の一部として位置づけることです。前述のとおり、クールダウンは真正性を保証しません。ロックファイルによる依存関係の固定(ピンニング)、依存パッケージのハッシュ検証、スコープを限定したトークンの利用、CIでの不要なインストールスクリプトの無効化、そしてSBOM(ソフトウェア部品表)による依存関係の可視化といった対策と組み合わせることで、初めて実効的な防御となります。

サプライチェーン攻撃はShai-Huludの亜種がGitHub自身やRed Hat、欧州委員会にまで波及するなど、依然として活発です。エコシステム側の防御強化は前進ですが、最終的にどのコードを自社の環境に取り込むかを管理する責任は、各組織に残り続けます。今回の時間ベースの防御を、自社のサプライチェーンセキュリティ戦略を見直す契機とすることが望まれます。