GitHub は 2026年4月20日、HTTPS 通信における SHA-1 の段階的な廃止を発表しました。結論から言うと、github.com、GitHub Enterprise Cloud、GitHub Enterprise Cloud with Data Residency を HTTPS 経由で利用している環境では、古いブラウザ・Git クライアント・API クライアント・TLS ライブラリを早めに確認する必要があります。一方で、GitHub Enterprise Server は今回の対象外です。(The GitHub Blog)
特に注意すべきなのは、この変更が「Git のコミットハッシュに使われる SHA-1」そのものの話ではなく、GitHub platform security and HTTPS connectivity に関わる HTTPS/TLS 接続上の SHA-1 廃止である点です。GitHub をブラウザで開く、GitHub API を呼び出す、git clone や git push を HTTPS で実行する、といった日常的な操作に影響する可能性があります。
GitHub platform security and HTTPS connectivity で何が変わるのか
今回の変更は、GitHub とその CDN における HTTPS 通信で SHA-1 の利用を取り除くものです。GitHub の公式 Changelog では、影響を受ける対象として、GitHub Web サイトを閲覧するブラウザ、GitHub API を利用するソフトウェア、HTTPS 経由で push / pull する Git クライアントが挙げられています。(The GitHub Blog)
実務上は、次のように捉えると分かりやすいです。
| 確認対象 | 影響の可能性 | 実務で見るべきポイント |
|---|---|---|
| ブラウザ | 低〜中 | 古い OS や更新されていないブラウザで GitHub にアクセスしていないか |
| Git クライアント | 中 | CI/CD、開発端末、踏み台サーバー、古いコンテナイメージで HTTPS clone / push をしていないか |
| API クライアント | 中〜高 | 社内ツール、Bot、GitHub Apps、連携サービスが古い TLS ライブラリを使っていないか |
| プロキシ・SSL インスペクション | 中 | 社内プロキシやセキュリティ製品が古い暗号アルゴリズムに依存していないか |
| GitHub Enterprise Server | 対象外 | 今回の GitHub.com 側の HTTPS 変更とは切り分けて考える |
多くの新しい環境では問題になりにくいものの、古い Linux ディストリビューション、更新されていない OpenSSL、長期間メンテナンスされていない CI ランナー、レガシーな社内 API クライアントは確認対象になります。
重要なスケジュール
GitHub は、完全な無効化の前に一時的な停止期間である brownout を予定しています。公式発表では、2026年7月14日に brownout、2026年9月15日に GitHub とパートナー CDN で SHA-1 in HTTPS / TLS を完全に無効化するとされています。なお、brownout は CDN には影響しないと説明されています。(The GitHub Blog)
| 日付 | 内容 | 実務上の意味 |
|---|---|---|
| 2026年4月20日 | GitHub が SHA-1 in HTTPS の廃止方針を発表 | 影響調査を開始するタイミング |
| 2026年7月14日 00:00〜18:00 UTC | brownout を実施 | 影響のあるクライアントでは一時的に接続失敗が起きる可能性 |
| 2026年9月15日 | GitHub とパートナー CDN で完全無効化 | 未対応環境では恒久的に HTTPS 接続できなくなる可能性 |
日本時間で見る場合、2026年7月14日の brownout は UTC 基準です。運用チームは、自社のタイムゾーンに換算したうえで、該当時間帯の CI/CD、リリース作業、バッチ処理、依存関係取得に失敗が出ないかを確認しておくと安全です。
最初に確認すべき変更点
Platform engineers、security teams、DevOps、enterprise GitHub admins が最初に見るべきポイントは、細かい暗号仕様よりも「どの経路で GitHub に HTTPS 接続しているか」です。
GitHub.com と Enterprise Cloud が対象
今回の対象は、github.com、GitHub Enterprise Cloud、GitHub Enterprise Cloud with Data Residency です。GitHub Enterprise Server は対象外とされています。(The GitHub Blog)
そのため、まずは次のように切り分けます。
| 利用形態 | 今回の確認優先度 | 理由 |
|---|---|---|
| GitHub.com を直接利用 | 高 | 公式発表の対象 |
| GitHub Enterprise Cloud | 高 | 対象に含まれる |
| GitHub Enterprise Cloud with Data Residency | 高 | 対象に含まれる |
| GitHub Enterprise Server のみ | 低 | 今回の変更対象外 |
| Enterprise Server と GitHub.com の併用 | 中〜高 | GitHub.com 側の連携や Actions で影響する可能性 |
Enterprise Server だけを使っている組織でも、外部連携、GitHub Marketplace、GitHub.com 上の公開リポジトリ取得、Actions の依存関係取得などで github.com に接続している場合があります。「自社は Enterprise Server だから関係ない」と即断せず、実際の通信経路を確認してください。
Git のオブジェクト ID の SHA-1 とは別問題
現場で混乱しやすいのが、「SHA-1 廃止」という表現です。
今回の変更は、Git のコミット ID やツリー ID として使われる SHA-1 の話ではありません。対象は HTTPS/TLS 接続の暗号アルゴリズム側です。
つまり、次のような作業が直接必要になるわけではありません。
- 既存リポジトリのコミットハッシュを変更する
- Git の履歴を書き換える
- SHA-256 リポジトリへ即時移行する
- GitHub 上のリポジトリ名や設定を変更する
実務で必要なのは、GitHub に HTTPS 接続するクライアント側が、SHA-1 に依存しない現代的な TLS 構成に対応しているかを確認することです。
影響を受けやすい環境
最新の OS、ブラウザ、Git、TLS ライブラリを使っている一般的な開発端末では、影響は限定的と考えられます。問題になりやすいのは、更新が止まりがちな周辺環境です。
古い CI/CD ランナー
最優先で確認したいのは CI/CD 環境です。
たとえば、次のような場所で GitHub への HTTPS 接続が発生します。
actions/checkout以外の独自スクリプトによるgit clone- Jenkins、GitLab CI、CircleCI、Buildkite などからの GitHub リポジトリ取得
- self-hosted runner での private repository 取得
- Terraform、Ansible、Helm、npm、pip、Go modules などの処理中に GitHub から依存関係を取得する処理
- Docker build 中の
git clone https://github.com/...
特に、古いベースイメージを使ったコンテナや、長く更新されていない self-hosted runner は要注意です。ホスト OS は新しくても、ジョブ内で使うコンテナイメージが古い場合、そこで使われる Git や OpenSSL が接続失敗の原因になることがあります。
社内ツールや Bot
GitHub API を使う社内ツールも確認対象です。
たとえば、次のようなツールです。
- Pull Request のレビュー状況を集計する Bot
- リポジトリ一覧や Issue を取得する社内ダッシュボード
- GitHub Apps や OAuth Apps
- Dependabot や監査ログを処理する周辺ツール
- Webhook 受信後に GitHub API を呼び返す自動化処理
GitHub は、API 接続ではモダンなフレームワークやライブラリを使うよう案内しています。(The GitHub Blog)
実務では、利用言語だけでなく、実際に TLS を処理しているランタイムやライブラリまで見る必要があります。
| 言語・環境 | 確認ポイント |
|---|---|
| Python | 実行環境の Python バージョン、OpenSSL、requests などの依存関係 |
| Node.js | Node.js のバージョン、実行コンテナの OS、HTTPS クライアント |
| Java | JDK / JRE のバージョン、TrustStore、社内プロキシ設定 |
| Go | Go ランタイムのバージョン、静的リンクされた古いバイナリ |
| .NET | .NET ランタイム、Windows Server の TLS 設定 |
| Ruby / PHP | 実行環境、OpenSSL、HTTP クライアントライブラリ |
「コードは変えていないのに突然 API が失敗する」という形で表面化しやすいため、重要な自動化処理は brownout 前に検証しておくべきです。
社内プロキシや SSL インスペクション
見落としがちなのが、開発端末やサーバーそのものではなく、途中にあるネットワーク機器です。
たとえば、次のような構成です。
- 企業プロキシ経由で GitHub に接続している
- SSL インスペクションを行うセキュリティ製品を利用している
- 開発者端末と GitHub の間に DLP、CASB、SWG などの製品がある
- データセンターや VDI 環境からのみ GitHub に出る
この場合、クライアント側の Git やブラウザが新しくても、途中のプロキシが古い TLS 構成に依存していると問題が出る可能性があります。brownout 中に一部拠点だけ失敗する、VDI だけ失敗する、特定のネットワークだけ GitHub API が通らない、といった症状が出る場合はネットワーク経路も確認してください。
初動チェックリスト
まずは「影響があるかもしれない接続」を洗い出し、優先順位を付けて確認します。すべてを一度に調べるより、業務停止リスクの高い順に見るほうが効率的です。
| 優先度 | 確認項目 | 具体的な確認方法 |
|---|---|---|
| 高 | CI/CD が GitHub に接続しているか | ジョブログで github.com、api.github.com、git clone を検索 |
| 高 | self-hosted runner が古くないか | OS、Git、OpenSSL、ベースイメージを確認 |
| 高 | 重要な社内 Bot が GitHub API を使っているか | API トークン利用箇所、GitHub Apps、定期バッチを棚卸し |
| 中 | 開発者端末の Git が古くないか | 端末管理ツールや MDM で Git / OS のバージョンを確認 |
| 中 | 社内プロキシが介在しているか | ネットワークチームに GitHub 宛て HTTPS の経路を確認 |
| 中 | ブラウザで GitHub を開く端末が古くないか | VDI、共有端末、閉域端末を確認 |
| 低 | GitHub Enterprise Server のみの利用箇所 | github.com への外向き通信がないかだけ確認 |
確認対象を洗い出すときは、GitHub の URL だけでなく、以下のホスト名や用途も含めると漏れにくくなります。
github.comapi.github.com- GitHub からのリポジトリ clone / fetch / push
- GitHub Releases からのバイナリ取得
- GitHub-hosted コンテンツや CDN 経由の取得
- GitHub Apps / OAuth Apps の API 通信
具体的な確認手順
ブラウザは github.dev で簡易確認する
GitHub は、ブラウザ確認の方法として https://github.dev へのアクセスを案内しています。GitHub によると、github.dev では SHA-1 がすでに無効化されており、接続問題なく読み込めれば、そのブラウザは現代的な HTTPS 構成に対応していると判断できます。(The GitHub Blog)
確認手順はシンプルです。
| 手順 | 作業 |
| -: | ————————————- |
| 1 | 対象端末の通常ブラウザで https://github.dev を開く |
| 2 | 接続エラー、証明書エラー、プロキシエラーが出ないか確認する |
| 3 | エラーが出る場合は、ブラウザ、OS、社内プロキシの順に切り分ける |
| 4 | VDI や共有端末など、特殊な端末でも同じ確認を行う |
注意点は、開発者の手元の最新端末だけで確認して終わらせないことです。実際に問題が起きやすいのは、VDI、踏み台、閉域ネットワーク、古い業務端末です。
Git クライアントは HTTPS 経由の操作を確認する
GitHub は Git クライアントについて、最近の Git を使い、OS や関連コンポーネントを最新に保つことを推奨しています。また、Git は HTTPS 対応のために複数のライブラリやバックエンドを使う場合があり、Linux では OpenSSL が TLS バックエンドとして使われる例が挙げられています。(The GitHub Blog)
まずは対象環境で次を確認します。
git --versionLinux では、可能であれば OpenSSL のバージョンも確認します。
openssl versionGitHub との疎通確認には、実際の運用に近い形で HTTPS 経由の操作を行います。
git ls-remote https://github.com/github/gitignore.gitこの確認で見るべきなのは、単にコマンドが成功するかだけではありません。どの環境で実行したかが重要です。
- 開発者端末
- CI ランナー
- self-hosted runner
- Docker コンテナ内
- Kubernetes Job 内
- 踏み台サーバー
- 社内ネットワーク配下の端末
- VPN 接続時の端末
同じコマンドでも、ローカル端末では成功し、古いコンテナ内では失敗するケースがあります。CI/CD で使う実行環境ごとに確認してください。
API クライアントはランタイム単位で確認する
GitHub API を利用している場合は、コードリポジトリ内の URL 検索だけでは不十分です。実行環境がどこにあるか、どのランタイムで動いているかまで確認します。
たとえば、次の観点で棚卸しします。
| 確認項目 | 見るべき内容 |
|---|---|
| API 呼び出し元 | 社内サーバー、クラウド Functions、CI ジョブ、Bot、業務端末 |
| 認証方式 | Personal access token、GitHub App、OAuth App |
| 実行言語 | Python、Node.js、Java、Go、.NET など |
| 実行基盤 | VM、コンテナ、Kubernetes、サーバーレス |
| ネットワーク経路 | 直接接続、プロキシ経由、VPN 経由 |
| エラーハンドリング | TLS エラー時にログが残るか、リトライで隠れないか |
API クライアントの検証では、単純な疎通だけでなく、実際に使っているエンドポイントに近いリクエストを送ることが重要です。読み取り専用の API 呼び出しで検証し、レスポンスコードと TLS 関連のエラーを記録します。
例として、権限不要のエンドポイントで疎通を見る場合は次のように確認できます。
curl -I https://api.github.comただし、curl が成功しても、アプリケーション本体が成功するとは限りません。curl とアプリケーションで使っている TLS ライブラリが異なる場合があるためです。最終的には、本番と同じランタイム・同じコンテナ・同じネットワーク経路で確認してください。
brownout 前にやるべき対応
2026年7月14日の brownout は、影響を検知するための重要な機会です。ただし、本番環境で初めて気づくのでは遅い場合があります。brownout 前に、少なくとも次の準備をしておきましょう。
重要なジョブを一覧化する
まず、GitHub への接続失敗が業務に与える影響を整理します。
| 業務 | GitHub 接続失敗時の影響 | 優先度 |
|---|---|---|
| 本番リリース | デプロイ停止、緊急修正不可 | 高 |
| CI ビルド | Pull Request 検証停止 | 高 |
| セキュリティスキャン | 脆弱性検知の遅延 | 中〜高 |
| 社内ダッシュボード | 情報更新の遅延 | 中 |
| 開発者の clone / pull | 開発効率低下 | 中 |
リリースや障害対応に直結するジョブは、brownout 前に必ず検証対象へ入れてください。
古い実行環境を更新する
影響が疑われる環境では、次の更新を検討します。
- OS のパッケージ更新
- Git クライアントの更新
- OpenSSL など TLS 関連ライブラリの更新
- Node.js、Python、Java、.NET などランタイムの更新
- CI/CD のベースイメージ更新
- self-hosted runner の更新
- 社内プロキシや SSL インスペクション製品の設定確認
特にコンテナでは、ubuntu:18.04 や古い Debian / Alpine 系イメージなど、長期間更新されていないベースイメージを使っていないか確認してください。ベースイメージの更新は、TLS だけでなく脆弱性対応の観点でも効果があります。
brownout 中の監視ポイントを決める
brownout 当日は、何を見ればよいかを事前に決めておきます。
| 監視対象 | 見るべきログ |
|---|---|
| CI/CD | clone、fetch、checkout、dependency install の失敗 |
| API クライアント | TLS handshake error、certificate error、connection reset |
| プロキシ | GitHub 宛て HTTPS の失敗率、証明書関連エラー |
| 開発者端末 | GitHub Web、Git 操作の接続エラー |
| Bot | 定期実行の失敗、Webhook 後続処理の失敗 |
エラーが出た場合は、単に「GitHub 障害」と扱わず、対象時間帯が brownout と重なっているかを確認してください。GitHub Status だけを見ても原因が分からない場合があります。
対応時に失敗しやすいポイント
手元の端末だけで確認してしまう
最も多い失敗は、情シスや DevOps 担当者の最新端末で問題がないことを確認し、「全社問題なし」と判断してしまうことです。
実際に問題が出るのは、古い CI ランナー、閉域ネットワーク、VDI、メンテナンスされていない自動化サーバーです。確認対象は「人が使う端末」ではなく、「GitHub に HTTPS 接続するすべての実行環境」と考えてください。
SSH 利用だから関係ないと判断する
Git 操作に SSH を使っているチームでも、GitHub API やブラウザアクセス、GitHub Releases からの取得は HTTPS を使っている可能性があります。
たとえば、次のような処理は SSH とは別に確認が必要です。
- GitHub API を呼ぶ Bot
- Release assets のダウンロード
- GitHub Pages や GitHub-hosted コンテンツへのアクセス
curlやwgetによる GitHub からの取得- パッケージマネージャー経由の GitHub 参照
「Git clone は SSH だから大丈夫」ではなく、HTTPS 通信全体を棚卸しすることが重要です。
プロキシの影響を見落とす
企業環境では、GitHub への通信が直接出ていないことがあります。プロキシや SSL インスペクション製品が介在している場合、開発者端末ではなく中間機器が問題の原因になることがあります。
切り分けるときは、次のように比較します。
| 比較 | 分かること |
|---|---|
| 社内ネットワーク vs 自宅回線 | 社内経路の問題かどうか |
| VPN 接続あり vs なし | VPN 経路の問題かどうか |
| プロキシあり vs なし | プロキシの影響かどうか |
| ホスト OS vs コンテナ内 | コンテナの TLS 環境の問題かどうか |
| ブラウザ vs Git vs アプリ | どのクライアント層の問題か |
この比較を先に用意しておくと、brownout 中に短時間で原因を絞り込めます。
企業管理者向けの実務対応プラン
Enterprise GitHub admins や security teams は、単発の確認ではなく、変更管理として扱うのがおすすめです。
影響調査の進め方
まず、GitHub への接続を次の4分類で棚卸しします。
| 分類 | 代表例 | 担当チーム |
|---|---|---|
| 人の利用 | ブラウザ、Git クライアント、GitHub Desktop | 情シス、開発部門 |
| CI/CD | GitHub Actions、Jenkins、self-hosted runner | DevOps、SRE |
| API 連携 | Bot、社内ツール、GitHub Apps | Platform team、各開発チーム |
| ネットワーク | Proxy、CASB、SWG、SSL inspection | Security team、Network team |
この分類ごとに、対象システム、実行環境、責任者、確認状況、更新要否を記録します。スプレッドシートでも構いませんが、変更管理チケットとして残すと監査や引き継ぎが楽になります。
対応ステータスの例
| ステータス | 意味 |
|---|---|
| 未確認 | まだ影響調査していない |
| 対象外 | GitHub への HTTPS 接続がない、または Enterprise Server のみ |
| 確認済み | github.dev や API 疎通確認で問題なし |
| 要更新 | Git、OS、ランタイム、プロキシなどの更新が必要 |
| 更新完了 | 更新後に再検証済み |
| brownout 監視対象 | 事前確認済みだが brownout 中も重点監視する |
重要なのは、「確認した」という事実だけでなく、どの環境で、どの方法で、いつ確認したかを残すことです。後から問題が起きた場合の切り分けが速くなります。
現場向けのすぐ使える確認観点
開発チームや Platform team に共有するなら、次のような短いチェックリストが実用的です。
GitHub SHA-1 in HTTPS 廃止対応チェック
□ github.com / api.github.com へ HTTPS 接続する処理を洗い出した
□ CI/CD の Git clone / fetch / checkout を確認した
□ self-hosted runner の OS、Git、OpenSSL を確認した
□ 古い Docker ベースイメージを使っていないか確認した
□ GitHub API を使う Bot / 社内ツールを確認した
□ 社内プロキシや SSL インスペクションの影響を確認した
□ https://github.dev を対象端末・対象ネットワークで開けることを確認した
□ 2026年7月14日の brownout 中に監視するジョブを決めた
□ 2026年9月15日の完全無効化前に更新作業を完了する計画を作ったこのチェックリストを各チームに配布し、影響がある場合だけ Platform team に報告してもらう形にすると、全社調査を進めやすくなります。
今回の変更をセキュリティ改善の機会にする
SHA-1 in HTTPS の廃止は、単なる GitHub 側の仕様変更ではなく、自社の開発基盤を見直す良い機会です。
古い TLS ライブラリや古い Git クライアントが残っている環境は、今回の変更に限らず、将来の証明書更新、暗号スイート変更、API セキュリティ強化でも問題を起こしやすくなります。
特に次のような環境は、今回を機に標準化しておくと運用負荷を減らせます。
- CI ランナーのベースイメージを定期更新する
- self-hosted runner の棚卸しルールを作る
- Git / OpenSSL / ランタイムの最低バージョン基準を決める
- GitHub API を使う社内ツールを一覧化する
- 社内プロキシ経由の開発者通信を監視できるようにする
セキュリティチームにとっては、「GitHub への接続が失敗しないか」だけでなく、「古い暗号アルゴリズムに依存した経路が残っていないか」を可視化する機会でもあります。
まず取るべきアクション
今回の GitHub starts sunsetting SHA-1 for HTTPS traffic は、GitHub platform security and HTTPS connectivity を利用する組織にとって、早めに確認すれば大きな混乱を避けられる変更です。
最初に行うべきことは、次の3つです。
- GitHub へ HTTPS 接続している環境を洗い出す
- ブラウザ、Git クライアント、API クライアント、CI/CD、プロキシを優先順位付きで確認する
- 2026年7月14日の brownout 前に検証し、2026年9月15日の完全無効化前に更新を終える
特に CI/CD、self-hosted runner、社内 Bot、プロキシは影響が見えにくく、失敗すると開発やリリースに直結します。手元の端末だけで判断せず、実際に GitHub と通信している実行環境ごとに確認してください。
コメント