MENU

GitHub platform security and HTTPS connectivityの最新動向: SHA-1終了で現場ワークフローはどう変わるか

WEBサービス

GitHub platform security and HTTPS connectivity の rollout で最初に確認すべきなのは、「GitHubのリポジトリそのもの」ではなく、GitHubへHTTPSで接続している端末・CI/CD・社内ツール・API連携が、古いTLS構成に依存していないかです。2026年4月20日のGitHub Changelogでは、GitHub.comとCDNでHTTPS/TLSにおけるSHA-1利用を段階的に終了する方針が発表されました。対象はブラウザ、GitHub APIを使うソフトウェア、HTTPSでpush/pullするGitクライアントです。GitHub Enterprise Serverは対象外とされています。(The GitHub Blog)

結論から言うと、多くの最新環境では大きな作業は発生しません。ただし、古いOS、古いGit、古いOpenSSLやlibcurl、長期間更新していないCIランナー、社内プロキシ経由の開発環境では、2026年7月14日のbrownoutで初めて障害に気づく可能性があります。管理者やsolution ownerは、個人PCだけでなく「自動化されたGitHub接続」を棚卸しすることが重要です。

目次

GitHub platform security and HTTPS connectivity のrolloutで何が変わるのか

今回の変更は、GitHub platform security and HTTPS connectivity のうち、HTTPS/TLS接続の安全性を高めるための更新です。GitHubは、GitHub本体およびCDNにおけるHTTPSでのSHA-1利用を取り除く予定です。影響範囲には、GitHub Webサイトを閲覧するブラウザ、GitHub APIに接続するソフトウェア、HTTPS経由でGitHubへpush/pullするGitクライアントが含まれます。(The GitHub Blog)

ここで誤解しやすいのは、「GitのコミットIDやオブジェクトIDとしてのSHA-1が即座に使えなくなる」という話ではない点です。今回の焦点は、GitHubへのHTTPS/TLS接続です。つまり、リポジトリの中身よりも、GitHubと通信する経路、クライアント、ライブラリ、プロキシ、ランナーの状態が問題になります。

GitHubの発表では、段階的なスケジュールも示されています。2026年7月14日 00:00〜18:00 UTCに一時的にSHA-1を無効化するbrownoutが実施され、2026年9月15日にはGitHubおよびパートナーCDNでHTTPS/TLSにおけるSHA-1が完全に無効化される予定です。なお、7月のbrownoutはCDNには影響しないと説明されています。(The GitHub Blog)

日付変更内容現場で起きる可能性があること
2026年4月20日GitHubがSHA-1 for HTTPS trafficのsunsettingを発表管理者・開発チームが影響調査を開始するタイミング
2026年7月14日 00:00〜18:00 UTCbrownoutとして一時的にSHA-1を無効化古い環境でGit clone、pull、push、API呼び出しが失敗する可能性
2026年9月15日GitHubとパートナーCDNで完全無効化未対応環境では恒久的に接続失敗する可能性

影響を受けるワークフローと受けにくいワークフロー

このrolloutの影響は、「GitHubを使っているか」ではなく「どのようにGitHubへ接続しているか」で決まります。特にHTTPS接続を使うワークフローは確認が必要です。

ワークフロー影響確認の必要性見るべきポイント
開発者PCからのgit clone、git pull、git push高Git、OS、TLSライブラリ、社内プロキシ
CI/CDのcheckout処理高runnerのOS、Dockerイメージ、Gitバージョン、curl/OpenSSL
GitHub APIを使う社内ツール高実行環境、HTTPクライアント、言語ランタイム、証明書設定
ブラウザでGitHubを閲覧中古いブラウザ、管理端末、VDI環境
GitHub Enterprise Cloud高GitHub.com側の変更対象
GitHub Enterprise Cloud with Data Residency高GitHub.com側の変更対象
GitHub Enterprise Server低今回のGitHub Changelogでは対象外

GitHubの公式発表では、GitHub.com、GitHub Enterprise Cloud、GitHub Enterprise Cloud with Data Residencyが対象で、GitHub Enterprise Serverは影響を受けないとされています。(The GitHub Blog)

Power usersが確認すべき利用シナリオ

Power users、つまり日常的にGitHubを深く使う開発者やテックリードは、自分のローカル環境だけでなく、開発効率を支える周辺ツールまで確認する必要があります。

HTTPS remoteを使っているリポジトリを確認する

まず、自分の作業リポジトリがHTTPSでGitHubへ接続しているかを確認します。

git remote -v

出力に次のようなURLがあれば、HTTPS経由です。

origin  https://github.com/example-org/example-repo.git (fetch)
origin  https://github.com/example-org/example-repo.git (push)

HTTPS接続自体が悪いわけではありません。問題は、接続に使っているGit、OS、TLSバックエンドが古い場合です。GitHubも、Gitクライアントについては最近のGitバージョンと最新のOSおよび関連コンポーネントを使うよう案内しています。GitはHTTPS対応のために複数のライブラリやバックエンドを使うことがあり、LinuxではOpenSSLがTLSバックエンドになる例が挙げられています。(The GitHub Blog)

手元のGitとTLS関連設定を確認する

以下のコマンドで、まず基本情報を確認します。

git --version
git config --show-origin --get http.sslBackend
git config --show-origin --get http.sslVersion
git config --show-origin --get http.sslVerify

見るべきポイントは次の通りです。

確認項目注意すべき状態対応の方向性
git --version長期間更新されていないGitGit for Windows、OSパッケージ、開発環境を更新
http.sslBackend古いTLSバックエンドに固定されている既定値や新しいバックエンドへ戻すことを検討
http.sslVersion古いTLSバージョンを明示指定している固定設定を外し、現行の安全な設定にする
http.sslVerifyfalseになっている原則trueへ戻す。社内CA問題は別途解決する

特にhttp.sslVerify falseは、接続エラーを一時的に回避するために設定されがちです。しかし、証明書検証を無効にすると通信相手の正当性を確認できなくなります。GitHub platform security and HTTPS connectivity の観点では、恒久対応ではありません。

ブラウザはgithub.devで簡易確認できる

GitHubは、ブラウザについてはhttps://github.devで確認できると案内しています。GitHubによると、github.devではSHA-1がすでに無効化されており、問題なく読み込めれば、ブラウザがモダンなHTTPS構成に対応している目安になります。 (The GitHub Blog)

ただし、これはブラウザの確認です。Git CLI、CI runner、社内ツールのAPI通信まで安全だと判断する材料にはなりません。ブラウザでは問題ないのに、古いDockerイメージ内のGitだけ失敗するケースは十分にあり得ます。

Adminsが優先して確認すべきポイント

管理者は、個々の開発者PCよりも「共通基盤」を優先して確認するべきです。理由は、共通基盤が止まると複数チームの開発・リリース・障害対応に同時に影響するためです。

最優先はCI/CDランナーとビルドイメージ

最もリスクが高いのは、CI/CDです。開発者のPCは比較的新しくても、CI用のDockerイメージやself-hosted runnerは数年前から更新されていないことがあります。

確認すべき対象は次の通りです。

対象具体例確認内容
self-hosted runnerGitHub Actions self-hosted runner、社内VMOS、Git、curl、OpenSSL、CA証明書
Dockerイメージbuild-base、ci-node、python-ciなどベースイメージの更新日、GitとTLSライブラリ
デプロイサーバー本番反映時にGit pullするサーバーGitHubへのHTTPS接続可否
IaC/構成管理Terraform、Ansible、社内スクリプトGitHub APIやHTTPS cloneの有無
セキュリティ製品SSL inspection、社内プロキシSHA-1依存、証明書差し替え、TLSポリシー

特に、ビルドの最初にactions/checkoutやgit cloneを実行している環境は、brownout当日に突然パイプラインが落ちる可能性があります。普段のテストが通っていても、TLSアルゴリズムの切り替え日にだけ失敗するため、事前検証が重要です。

CIで使う確認コマンドの例

CI runnerやDockerイメージ内で、次のような確認を行います。

git --version
curl --version
openssl version
git ls-remote https://github.com/github/docs.git HEAD

git ls-remoteは、リポジトリをcloneせずにGitHubとの接続を確認できるため、軽量な疎通確認として使いやすい方法です。社内の監査ログやCIログにアクセストークンを出さないよう、認証不要の公開リポジトリで確認すると安全です。

より詳細な調査が必要な場合は、Gitのcurlログを一時的に有効にします。

GIT_CURL_VERBOSE=1 git ls-remote https://github.com/github/docs.git HEAD

ただし、詳細ログには接続情報やヘッダーが出力される場合があります。共有CIログで実行する場合は、トークンや社内URLが含まれない環境で実施してください。

社内プロキシとSSL inspectionを見落とさない

企業環境では、開発者PCやCI runnerがGitHubへ直接接続していないことがあります。社内プロキシ、SSL inspection、ゼロトラスト系ゲートウェイを経由している場合、GitHub側がモダンなHTTPS構成へ移行しても、中間装置側のTLS設定が古いと接続失敗の原因になります。

管理者は、次の観点でネットワークチームと確認しましょう。

確認観点質問例
GitHub宛通信の経路開発者PCとCI runnerは同じプロキシを通るか
TLS inspectionの有無github.com、api.github.com、GitHub CDNで復号検査しているか
プロキシのTLSポリシー古い署名アルゴリズムや暗号スイートに依存していないか
例外設定GitHub関連ドメインを検査除外しているか
障害時の切り分け直接接続、プロキシ経由、別ネットワークで比較できるか

「ブラウザではGitHubが開けるが、Git cloneだけ失敗する」という相談が来た場合、Gitクライアントだけでなく、プロキシやCA証明書の配布状況も疑う必要があります。

Solution ownersが考えるべきAPI連携への影響

solution ownerにとって重要なのは、GitHub APIを使う業務システムや自動化ツールです。GitHubの発表では、GitHub APIを利用するソフトウェアも影響対象として挙げられており、モダンなフレームワークやライブラリを使うことが推奨されています。(The GitHub Blog)

API連携は「コード」より「実行環境」を見る

GitHub API連携で障害が起きる場合、ソースコードのロジックではなく、実行環境のHTTP/TLSスタックが原因になることがあります。たとえば、次のようなツールです。

ツール種別具体例確認ポイント
社内ダッシュボードissue、PR、release情報の集計実行サーバーのOS、HTTPライブラリ
ChatOpsSlackやTeamsからGitHub APIを呼ぶbotランタイム、SDK、証明書ストア
自動レビュー支援PR一覧、diff、status checks取得GitHub SDKのバージョン
リリース自動化GitHub Releases、Actions API利用API呼び出しの失敗時リトライ
監査・棚卸しOrganization、repo、team情報の取得古いコンテナや定期ジョブ

Node.js、Python、Java、Go、Ruby、.NETなどのアプリケーションでは、言語ランタイム、HTTPクライアント、証明書ストア、OSパッケージが絡みます。コード上でGET https://api.github.com/...と書いているだけでも、実際のTLS接続は実行環境に依存します。

API連携の検証は本番相当の経路で行う

API連携の確認は、開発者PCからcurlを打つだけでは不十分です。本番ジョブが動くサーバー、コンテナ、ネットワーク経路で確認します。

curl -I https://api.github.com

APIトークンを使う処理を確認する場合は、ログ出力に注意してください。トークン付きのcurlコマンドをCIログへ残すと、別のセキュリティインシデントにつながります。

本番影響を避けるには、読み取り系のAPIやテスト用Organization、検証用GitHub Appを使い、次の観点で確認します。

検証項目合格基準
API接続TLSエラーなしで応答が返る
認証tokenやGitHub App認証が正常に通る
リトライ一時的な接続失敗時に過剰リトライしない
ログ秘密情報を出さず、原因調査に必要な情報は残る
通知定期ジョブ失敗時に担当者へ通知される

brownoutを障害訓練として使う

2026年7月14日のbrownoutは、単なる一時停止イベントではなく、現場にとっては貴重な障害訓練の機会です。GitHubはこの期間に一時的にSHA-1を無効化し、非推奨化の認知を高めると説明しています。(The GitHub Blog)

brownout前に、次の準備をしておくと対応が速くなります。

準備目的
GitHub接続を使うジョブ一覧を作る影響範囲を即座に判断する
self-hosted runnerの一覧を確認する古い実行環境を見つける
失敗時のエラーメッセージを収集するTLS問題か認証問題かを切り分ける
開発者向けFAQを用意する問い合わせ対応を減らす
brownout後に結果をレビューする9月の完全無効化までに修正する

brownout当日に全員で慌てて調査するのではなく、あらかじめ「どのチームのどのジョブがGitHubへHTTPS接続しているか」を見える化しておくことが大切です。

現場で起きやすい失敗パターン

GitHub platform security and HTTPS connectivity の更新では、表面的には「GitHubに接続できない」という同じ症状に見えても、原因は複数あります。よくある失敗パターンを事前に知っておくと、切り分けが速くなります。

古いDockerイメージだけが失敗する

ローカルPCでは問題ないのに、CIだけ失敗するパターンです。原因としては、古いベースイメージ、古いGit、古いcurl、古いOpenSSL、更新されていないCA証明書などが考えられます。

対策は、CIイメージを作り直し、GitHub接続確認をビルド前チェックに入れることです。

git ls-remote https://github.com/github/docs.git HEAD >/dev/null

このような軽量チェックをCIの早い段階で実行すれば、本来のテストやビルドに入る前に接続問題を検知できます。

GitHub APIのSDKだけ古い

社内ツールでGitHub APIを利用している場合、SDKやHTTPクライアントが古いままになっていることがあります。GitHubの発表でも、APIについてはモダンなフレームワークやライブラリを使うよう案内されています。(The GitHub Blog)

対策は、SDKだけでなく、ランタイムとOSもセットで更新することです。たとえば、アプリケーションコードを更新しても、実行コンテナのベースイメージが古いままだと問題が残る場合があります。

エラー回避のために証明書検証を無効化する

TLSエラーが出たときに、次のような設定で回避したくなるケースがあります。

git config --global http.sslVerify false

これは避けるべきです。証明書検証を無効にすると、GitHubと安全に通信しているかを確認できなくなります。短期的な検証で使った場合でも、恒久設定として残さないようにしてください。

正しい対応は、Git、OS、証明書ストア、社内CA、プロキシ設定を見直すことです。

SSH接続に切り替えればよいと短絡する

HTTPSの問題を避けるために、全員をSSH接続へ切り替える案が出ることがあります。SSHは有効な選択肢になり得ますが、安易な一括移行は運用負荷を増やします。

考慮すべき点は、SSH鍵の配布、退職者の鍵管理、CIでの秘密鍵管理、監査ログ、Organizationポリシーです。HTTPS接続を更新で解決できるなら、まずは現行ワークフローを安全な状態に保つ方が現実的な場合が多いでしょう。

役割別の実務アクション

今回のrolloutは、開発者、管理者、solution ownerで見るべき対象が異なります。担当範囲ごとに、次の行動へ落とし込むと進めやすくなります。

役割すぐやること期限の目安
Power users自分の主要リポジトリ、Gitバージョン、HTTPS remoteを確認brownout前
AdminsCI runner、社内プロキシ、VDI、標準開発端末を棚卸しbrownout前
Solution ownersGitHub API連携、bot、定期ジョブを本番相当環境で検証brownout前
Security team証明書検証無効化、古いTLS設定、プロキシ設定を監査完全無効化前
Platform team更新済みCIイメージとトラブルシュート手順を提供brownout前

特に管理者は、2026年7月14日のbrownoutを「本番前の検証イベント」として扱い、失敗した環境を9月15日までに確実に修正する流れを作るべきです。

チェックリスト: 9月の完全無効化までに確認すること

以下のチェックリストを使うと、影響調査を具体的に進められます。

開発者PC

  • git --versionで古いGitを使っていないか確認する
  • git remote -vでHTTPS remoteの利用状況を確認する
  • git config --get http.sslVerifyがfalseになっていないか確認する
  • ブラウザでhttps://github.devへアクセスできるか確認する
  • 社内プロキシ経由と直接接続で挙動が違わないか確認する

CI/CD

  • self-hosted runnerのOSとGitを更新する
  • Dockerベースイメージを更新する
  • git ls-remoteによる疎通確認を追加する
  • GitHub APIを使うジョブを洗い出す
  • brownout当日の失敗ログを保存する

API連携・社内ツール

  • GitHub SDKやHTTPクライアントを更新する
  • 実行環境のOS、証明書ストア、TLSライブラリを確認する
  • 読み取り系APIで本番相当の疎通確認をする
  • リトライやタイムアウト設定を見直す
  • エラー通知が担当者へ届くようにする

ネットワーク・セキュリティ

  • GitHub宛通信がどのプロキシを経由するか確認する
  • SSL inspectionの対象範囲を確認する
  • 社内CA証明書の配布状況を確認する
  • 証明書検証を無効化している端末やジョブを検出する
  • brownout時の切り分け手順を用意する

まとめ: GitHub接続を「使えている」から「継続して安全に使える」へ

GitHub platform security and HTTPS connectivity のrolloutは、単なるセキュリティニュースではありません。開発者PC、CI/CD、API連携、社内プロキシ、Dockerイメージといった日々のワークフローに直接関係します。

今回のポイントは、HTTPS/TLSにおけるSHA-1の段階的な終了です。2026年7月14日のbrownoutで一時的な影響を確認し、2026年9月15日の完全無効化までに古い環境を更新する流れで対応するのが現実的です。GitHubの発表では、最新のブラウザ、モダンなAPIクライアント、最近のGitと最新のOS・関連コンポーネントを使うことが推奨されています。(The GitHub Blog)

次に取るべき行動は明確です。まず、HTTPSでGitHubへ接続しているワークフローを棚卸ししてください。次に、CI runner、Dockerイメージ、API連携、社内プロキシを優先して検証します。最後に、brownoutで得た失敗ログをもとに、9月の完全無効化までに更新を完了させます。

WEBサービス
セキュリティ HTTPS TLS GitHub CI/CD SHA-1

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次