GitHub platform security and HTTPS connectivity の今回の要点は、古いブラウザー、古い Git クライアント、古い TLS ライブラリを使う API 連携を、2026年9月15日までに更新対象として洗い出すことです。GitHub は 2026年4月20日、HTTPS/TLS における SHA-1 の利用を段階的に廃止すると発表しました。これは単なる暗号アルゴリズムの置き換えではなく、GitHub が今後も「古い接続方式を残さず、より安全な接続へ寄せていく」方針を示す動きです。(The GitHub Blog)
特に Product owner、IT decision-maker、technical strategist にとって重要なのは、「開発者の手元の Git だけ」の問題として扱わないことです。GitHub API を呼び出す社内ツール、CI/CD、古いコンテナイメージ、プロキシ、VDI、長期サポート OS 上のブラウザーなど、GitHub に HTTPS で接続する経路全体を確認する必要があります。
GitHub platform security and HTTPS connectivity の最新動向：SHA-1廃止は何を意味するか
GitHub の発表によると、今回の変更は GitHub とその CDN における HTTPS での SHA-1 利用を削除するものです。影響範囲には、GitHub の Web サイトを閲覧するブラウザー、GitHub API を使うソフトウェア、HTTPS 経由で push / pull する Git クライアントが含まれます。対象は github.com、GitHub Enterprise Cloud、GitHub Enterprise Cloud with Data Residency で、GitHub Enterprise Server は対象外です。(The GitHub Blog)
今回の変更を「暗号方式の細かい話」として流すと、実務では見落としが起きます。GitHub への接続は、開発者端末だけでなく、ビルド環境、リリースパイプライン、監査ツール、セキュリティスキャナー、データ連携基盤にも広がっているためです。
| 観点 | 今回の変更で見るべきポイント | 実務上の確認先 |
|---|---|---|
| Web 利用 | 古いブラウザーや固定化された業務端末で GitHub が表示できるか | VDI、業務端末、キオスク端末、踏み台端末 |
| Git 操作 | HTTPS 経由の clone / fetch / push が継続できるか | 開発者端末、CI runner、ビルドサーバー |
| API 連携 | GitHub API クライアントの TLS 実装が十分に新しいか | 社内 Bot、監査ツール、連携バッチ、GitHub Apps |
| ネットワーク | TLS 検査やプロキシが古い暗号設定に依存していないか | SSL インスペクション、プロキシ、出口制御 |
| 組織管理 | 廃止日までに検証・更新・例外処理を完了できるか | IT 部門、セキュリティ部門、開発基盤チーム |
2026年のスケジュール：7月に検知、9月に完全対応
GitHub は、SHA-1 廃止に向けて一時的な無効化期間である brownout を設けます。予定では 2026年7月14日 00:00〜18:00 UTC に SHA-1 を一時的に無効化し、2026年9月15日に GitHub と partner CDNs で HTTPS/TLS の SHA-1 を完全に無効化します。なお、7月の brownout は CDNs には影響しないとされています。(The GitHub Blog)
日本時間で見ると、brownout は 2026年7月14日 09:00〜7月15日 03:00 です。グローバル組織では、UTC 基準の発表をそのまま各地域の稼働時間に置き換え、アジア、欧州、米州のどの業務時間帯に影響が出るかを確認しておく必要があります。
| 日付 | 内容 | 運用上の意味 |
|---|---|---|
| 2026年4月20日 | GitHub が HTTPS における SHA-1 廃止を発表 | 影響調査を開始するタイミング |
| 2026年7月14日 00:00〜18:00 UTC | SHA-1 を一時的に無効化する brownout | 障害が起きる環境を本番相当で検知できる |
| 2026年9月15日 | GitHub と partner CDNs で完全無効化 | 未対応環境は接続不能になる可能性がある |
重要なのは、brownout を「GitHub 側の一時イベント」として眺めるのではなく、自社環境の検証日として扱うことです。7月の時点で失敗した端末やシステムを洗い出せなければ、9月の完全無効化時には計画外の障害として表面化します。
なぜ SHA-1 廃止は避けられないのか
SHA-1 は長く使われてきた暗号学的ハッシュ関数ですが、現在では安全性の観点から移行が求められています。NIST は、SHA-1 に依存している場合は SHA-2 または SHA-3 へ移行することを推奨しており、SHA-1 は有用な寿命を終えたと説明しています。(NIST)
GitHub の今回の動きも、この流れの中で見るべきです。GitHub は過去にも、TLS 1.0 / TLS 1.1、古い SSH 鍵交換方式、未認証の git:// プロトコルなど、弱くなった接続方式を段階的に廃止してきました。2017年には TLS 1.0 / TLS 1.1 と SHA-1 を含む古い SSH 鍵交換方式の廃止を発表し、2018年2月に無効化する方針を示していました。(The GitHub Blog)
さらに 2021年には、SSH でサポートする鍵やアルゴリズムを見直し、未暗号化の Git プロトコルを廃止するロードマップを公開しました。この変更では brownout を挟み、2022年3月15日に変更を恒久化する流れが取られています。(The GitHub Blog)
つまり、GitHub platform security and HTTPS connectivity の方向性はかなり明確です。古い互換性を無期限に残すのではなく、十分な告知、brownout、恒久的な無効化という流れで、接続方式を段階的に安全側へ寄せています。
今回の影響を受けやすい環境
古いブラウザーや固定化された業務端末
GitHub は、最適な利用には Chrome、Edge、Firefox、Safari の最新バージョンを推奨しています。推奨ブラウザーの最新バージョンを使わない場合や、それ以外のブラウザーを使う場合、GitHub または一部機能が期待どおりに動作しない可能性があります。(GitHub Docs)
特に注意したいのは、開発者のメイン PC ではなく、次のような「更新されにくい端末」です。
- 社内の VDI 環境
- 長期運用されている踏み台端末
- 製造・金融・公共系で固定化された業務端末
- ブラウザー更新を IT 部門が集中管理している環境
- 古い OS 上でブラウザーだけを延命している端末
ブラウザーで GitHub を開けるかどうかは、GitHub が案内している github.dev へのアクセスで確認できます。GitHub は、github.dev ではすでに SHA-1 が無効化されており、接続問題なく読み込めればブラウザーがモダンな HTTPS 構成をサポートしていると説明しています。(The GitHub Blog)
# ブラウザー検証用
https://github.devただし、この確認はブラウザー単体のテストです。API クライアントや Git クライアントの検証は、実際に利用しているランタイムや実行環境で別途行う必要があります。
GitHub API を呼び出す社内ツール
GitHub API を使うソフトウェアも対象です。たとえば、社内の棚卸しツール、権限監査ツール、リポジトリ同期ツール、GitHub Apps、Slack 連携 Bot、CI/CD の補助スクリプトなどが該当します。
ここで失敗しやすいのは、アプリケーションコードだけを見て「GitHub API の URL は変わっていないから問題ない」と判断することです。HTTPS 接続の成否は、コードだけでなく、ランタイム、TLS ライブラリ、OS、コンテナベースイメージ、プロキシ設定にも左右されます。
確認すべき対象は次のとおりです。
| 対象 | 確認ポイント | ありがちな見落とし |
|---|---|---|
| Python / Ruby / Node.js / Java などのランタイム | 使っている TLS / OpenSSL 実装が古くないか | アプリは新しくてもベースイメージが古い |
| コンテナイメージ | OS パッケージと証明書関連パッケージが更新されているか | 数年前のイメージを固定している |
| CI/CD runner | runner 本体、Git、OS が更新されているか | self-hosted runner だけ更新から漏れる |
| 社内プロキシ | GitHub への TLS 接続を古い設定で中継していないか | SSL インスペクション機器が古い |
| 外部連携 SaaS | GitHub API 連携の実行環境が対応済みか | ベンダー任せで検証日程がない |
API 連携では、以下のように実行環境ごとの TLS 実装を確認しておくと、更新対象を絞り込みやすくなります。
# Python の OpenSSL バージョン確認
python -c "import ssl; print(ssl.OPENSSL_VERSION)"
# Node.js の OpenSSL バージョン確認
node -p "process.versions.openssl"
# GitHub への HTTPS 接続確認
curl -Iv https://github.devこの確認で問題が出なくても、「本番で使っている実行環境」と同じ条件でテストできていなければ意味がありません。ローカル PC ではなく、実際の runner、実際のコンテナ、実際のプロキシ経由で確認することが重要です。
HTTPS 経由で Git 操作を行う Git クライアント
GitHub は、Git クライアントについても最近の Git バージョンを使うよう案内しています。Git は HTTPS 対応のために複数のライブラリやバックエンドを利用することがあり、Linux では OpenSSL が TLS バックエンドとして使われる例があるため、Git だけでなく OS や関連コンポーネントも最新に近い状態にしておく必要があります。(The GitHub Blog)
まずは、利用中の Git と remote URL を確認します。
git --version
git remote -vhttps:// で GitHub に接続している場合、今回の SHA-1 廃止の影響確認対象になります。SSH の場合は今回の HTTPS/TLS 変更とは直接の対象が異なりますが、過去の GitHub のセキュリティ変更では SSH 側でも古い鍵や未暗号化プロトコルが廃止されています。GitHub は 2021年の発表で、DSA 鍵の廃止、RSA 鍵の要件追加、古い SSH アルゴリズムの削除、未暗号化 Git プロトコルの廃止を示していました。(The GitHub Blog)
そのため、HTTPS だけを見て終わりにするのではなく、開発基盤全体として次の方針を持つのが安全です。
| 接続方式 | 今回の直接対象 | 中期的な運用方針 |
|---|---|---|
| HTTPS Git | 対象 | Git、OS、TLS ライブラリを定期更新する |
| GitHub API over HTTPS | 対象 | ランタイムとコンテナを棚卸しする |
| ブラウザーアクセス | 対象 | サポート対象ブラウザーを最新化する |
| SSH Git | 今回の HTTPS/TLS 変更とは別 | 古い鍵・古い SSH 実装を継続的に見直す |
| GitHub Enterprise Server 本体 | 今回の変更対象外 | 独自の TLS / SSH 設定とアップグレード計画を管理する |
GitHub Enterprise Server は対象外でも油断しない
GitHub の発表では、GitHub Enterprise Server は今回の変更対象外とされています。これは、オンプレミスまたは自社管理の GitHub Enterprise Server インスタンス自体に、今回の GitHub.com 側の SHA-1 廃止が直接適用されるわけではない、という意味です。(The GitHub Blog)
ただし、GitHub Enterprise Server を利用している組織でも、GitHub.com や GitHub Enterprise Cloud と接続する運用があれば別です。たとえば GitHub Connect を有効にすると、GitHub Enterprise Server インスタンスと GitHub Enterprise Cloud の enterprise account 間に接続が構成され、この接続は 443 または 80 番ポート上の HTTPS で、TLS により保護されます。(GitHub Docs)
そのため、GHES 利用企業は次のように切り分けて考える必要があります。
| 環境 | 判断 |
|---|---|
| GHES インスタンス内だけで完結する Git 操作 | 今回の GitHub.com 側変更の直接対象外 |
| GHES から GitHub.com / GHE.com へ接続する機能 | 実際の接続経路を確認すべき |
| 開発者が GHES と GitHub.com の両方を使う | GitHub.com 側の端末・Git・ブラウザー検証が必要 |
| CI/CD が GitHub.com のリポジトリや API を使う | runner とネットワーク経路を確認すべき |
「GHES は対象外」と「自社の GitHub 関連通信がすべて対象外」は同じではありません。Product owner や IT decision-maker は、サービス契約単位ではなく、実際の通信経路単位で判断する必要があります。
ロードマップとして読むべき3つのシグナル
シグナル1：GitHub は廃止予定を Changelog で明示する
GitHub Changelog には Release、Improvement、Retired などの情報が掲載されており、2026年4月20日の「Sunsetting SHA-1 in HTTPS on GitHub」も Retired として掲載されています。(The GitHub Blog)
これは、GitHub のロードマップを読むうえで重要です。新機能だけを GitHub public roadmap で追うのではなく、Changelog の Retired / deprecation 系情報を定期的に確認しなければ、運用リスクを見落とします。
シグナル2：brownout は「本番影響の予告」ではなく「検証の機会」
GitHub は過去のプロトコル変更でも brownout を使っています。2021年の Git プロトコルセキュリティ変更では、brownout 期間中に非推奨の鍵、署名形式、暗号、MAC、未暗号化 Git プロトコルを一時停止し、残っている古い利用を発見しやすくする方針が示されていました。(The GitHub Blog)
今回の SHA-1 廃止でも、7月の brownout は単なる注意喚起ではありません。自社で接続失敗が起きるかどうかを確認できる、限られた本番相当のテスト機会です。
シグナル3：機能ロードマップとセキュリティ廃止情報は別々に追う
GitHub public roadmap は、GitHub が取り組んでいる機能、段階、提供見込み時期を知るための場所です。公式ロードマップでは、各項目にリリースフェーズ、機能領域、対象 SKU などを示すラベルが付けられると説明されています。(GitHub)
一方で、SHA-1 廃止のような接続要件の変更は、Changelog や個別のセキュリティ告知で把握する必要があります。つまり、GitHub platform security and HTTPS connectivity の運用方針を読むには、次の2系統を同時に見るべきです。
| 情報源 | 主に分かること | 読むべき人 |
|---|---|---|
| GitHub public roadmap | 新機能、提供予定、対象 SKU | Product owner、技術戦略担当 |
| GitHub Changelog | リリース、改善、廃止、影響日程 | 開発基盤、IT 運用、セキュリティ担当 |
| GitHub Docs | サポート条件、設定、運用手順 | 実装担当、管理者 |
| GitHub Blog のセキュリティ告知 | 変更理由、背景、移行方針 | 技術責任者、アーキテクト |
企業が取るべき運用方針
まず GitHub 接続の棚卸しを行う
最初にやるべきことは、GitHub に接続しているすべての経路を洗い出すことです。特に大規模組織では、公式の開発環境だけでなく、部門ごとに作られたスクリプトや古い CI ジョブが残っていることがあります。
棚卸しでは、次の分類で一覧化すると管理しやすくなります。
| 分類 | 例 | 所有者 |
|---|---|---|
| 人が使う環境 | 開発者 PC、VDI、管理端末 | 情シス、開発部門 |
| 自動化環境 | CI/CD、self-hosted runner、cron、Bot | 開発基盤チーム |
| API 連携 | GitHub Apps、監査ツール、権限管理ツール | セキュリティ、Platform team |
| ネットワーク経路 | プロキシ、TLS 検査、出口制御 | インフラ、ネットワーク |
| 外部ベンダー | SIer 運用スクリプト、監視 SaaS | 調達、ベンダー管理 |
この時点では、すべてを即更新する必要はありません。まず「GitHub へ HTTPS で接続しているもの」を漏れなく見つけることが優先です。
brownout 前に本番相当テストを終える
7月の brownout に初めて気づく運用では遅すぎます。6月末までに本番相当環境での接続確認を終え、brownout 当日は監視と最終確認に使うのが現実的です。
おすすめの進め方は次のとおりです。
| 時期 | やること |
|---|---|
| 2026年4〜5月 | GitHub 接続経路の棚卸し、古い端末・古いランタイムの特定 |
| 2026年5〜6月 | Git、OS、ブラウザー、コンテナイメージ、TLS ライブラリの更新 |
| 2026年6月末まで | 本番相当環境で GitHub API / Git / ブラウザー接続を検証 |
| 2026年7月14日 | brownout 中のエラー監視、失敗環境の記録 |
| 2026年7〜8月 | 残課題の修正、例外環境の廃止または代替策決定 |
| 2026年9月15日まで | 完全無効化に向けた変更凍結、監視体制の確認 |
更新できない環境は「例外」ではなく「リスク」として扱う
古い OS、古い Git、古いランタイムを使い続ける理由は、現場にはよくあります。検証済みの業務システムを変えにくい、ベンダー製品が古いライブラリに依存している、コンテナイメージの更新で別の不具合が出る、といった事情です。
しかし、HTTPS 接続要件の変更は GitHub 側で実施されるため、自社だけで先送りできません。更新できない環境は「例外承認で継続」ではなく、次のいずれかに分類して対応を決めるべきです。
| 状態 | 判断 |
|---|---|
| 更新可能 | Git、OS、ブラウザー、ランタイムを更新する |
| 更新に検証が必要 | 期限を切って検証環境で確認する |
| 更新不可だが代替可能 | 別 runner、別端末、別ランタイムへ移行する |
| 更新不可かつ代替不可 | GitHub 依存業務そのものの継続可否を判断する |
特に、CI/CD やリリース作業に関わる環境は優先度を上げるべきです。開発者のブラウザー表示が一時的に失敗するよりも、本番リリースの fetch、ビルド、監査 API 呼び出しが止まるほうが事業影響は大きくなります。
失敗しやすいポイント
ローカル端末だけ検証して CI を見落とす
開発者 PC で git pull が成功しても、self-hosted runner や古いビルドサーバーが成功するとは限りません。CI/CD は普段ユーザーが直接触らないため、古い OS、古い Git、古い OpenSSL、古いコンテナイメージが残りやすい領域です。
対策は、GitHub に接続するジョブを洗い出し、実際の runner 上で検証することです。特に夜間バッチや月次処理など、実行頻度が低い処理は brownout 中にたまたま動かず、9月の完全無効化後に初めて発覚する可能性があります。
API クライアントの「コード」だけ見てしまう
GitHub API のエンドポイントや認証方式が変わらなくても、TLS 接続が失敗すれば API 呼び出しは止まります。確認すべきなのは、HTTP クライアントライブラリだけではありません。
- 実行 OS
- OpenSSL などの TLS ライブラリ
- 言語ランタイム
- コンテナベースイメージ
- CA 証明書関連パッケージ
- プロキシや TLS 検査装置
- 本番と検証環境の差分
「Postman では動く」「手元の curl では動く」だけでは不十分です。実際の本番実行環境で、GitHub API を呼び出す処理を確認してください。
GitHub Enterprise Server 対象外を広く解釈しすぎる
GitHub Enterprise Server 自体が今回の変更対象外でも、組織内の開発者や自動化処理が GitHub.com、GitHub Enterprise Cloud、GitHub API に接続していれば影響確認が必要です。
GHES 管理者は、自社インスタンスの TLS 設定だけでなく、GitHub Connect、外部 Actions、GitHub.com とのミラーリング、監査連携など、クラウド側へ出る通信を確認してください。
意思決定者向けの判断基準
Product owner や IT decision-maker は、今回の対応を「Git のバージョンアップ依頼」で終わらせないほうがよいでしょう。GitHub は開発組織の基盤であり、接続障害は開発速度、リリース、セキュリティ監査、サプライチェーン管理に波及します。
判断基準は次の3つです。
| 判断軸 | 確認すべきこと |
|---|---|
| 事業影響 | GitHub 接続失敗時にリリース、障害対応、監査が止まるか |
| 技術的負債 | 古い OS、古い Git、古いランタイムをどれだけ抱えているか |
| 統制 | GitHub Changelog や roadmap の変更を定期的に追う責任者がいるか |
特に3つ目が重要です。GitHub の変更は、ある日突然起きるのではなく、Changelog、Docs、Blog、roadmap に分散して予告されることが多くあります。組織としてそれを読む仕組みがなければ、毎回「現場が気づいたら対応する」運用になります。
今すぐ実施するチェックリスト
最後に、今回の GitHub starts sunsetting SHA-1 for HTTPS traffic を受けて実施すべきことを整理します。
| チェック項目 | 完了の目安 |
|---|---|
| GitHub に HTTPS 接続する端末・システムを一覧化した | ブラウザー、Git、API、CI/CD を分けて記録している |
| 古い OS・古い Git・古いランタイムを特定した | 更新対象と代替対象が分かれている |
github.dev でブラウザー確認を行った | 主要端末と VDI で接続確認済み |
| API 連携を本番相当環境で確認した | 実際の runner、コンテナ、プロキシ経由で確認済み |
| 7月14日の brownout 対応体制を決めた | 監視担当、連絡先、記録方法が決まっている |
| 9月15日までの更新計画を作成した | 更新不可環境の代替策まで決まっている |
| GitHub Changelog と roadmap の監視担当を決めた | 定期レビューの会議体または運用フローがある |
今回の SHA-1 廃止は、GitHub platform security and HTTPS connectivity の中期的な方向性を読むうえで分かりやすいシグナルです。古い接続方式は段階的に減り、GitHub は brownout を挟みながら安全な接続要件へ移行していきます。
まずは GitHub へ HTTPS で接続している環境を棚卸しし、7月の brownout 前に本番相当の検証を終えてください。そのうえで、9月15日を「対応期限」ではなく「未対応を残さない最終確認日」として扱うことが、今後の GitHub 運用を安定させる近道です。
コメント