GitHub platform security and HTTPS connectivity を利用している組織は、2026年4月20日の GitHub による「SHA-1 in HTTPS」の廃止告知を、単なる暗号アルゴリズムの更新ではなく、古いブラウザ、Gitクライアント、API連携、CI/CD基盤が GitHub に接続できなくなる可能性がある変更として扱うべきです。
結論から言うと、優先して確認すべき対象は「人が使うブラウザ」よりも、放置されやすい自動化環境です。古いOS上のビルドエージェント、自己管理のGitクライアント、社内プロキシ、古いJava・OpenSSL・libcurlに依存するAPI連携は、ブラウザより発見が遅れやすく、業務停止につながりやすい領域です。
GitHub は、github.com、GitHub Enterprise Cloud、GitHub Enterprise Cloud with Data Residency における HTTPS/TLS の SHA-1 利用を段階的に廃止すると発表しています。2026年7月14日に一時的な無効化、2026年9月15日に完全無効化が予定されています。GitHub Enterprise Server は今回の変更対象外です。(The GitHub Blog)
GitHub platform security and HTTPS connectivity で何が変わるのか
今回の変更は、GitHub platform security and HTTPS connectivity において、HTTPS通信で使われる古い暗号方式への後方互換を縮小するものです。
GitHub の告知では、影響を受ける可能性がある対象として、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にログインできるか」だけでは確認が足りない点です。実務では、以下のような経路で GitHub への HTTPS 接続が発生します。
| 接続元 | 代表例 | 見落としやすい理由 |
|---|---|---|
| 開発者端末 | ブラウザ、Git CLI、GitHub Desktop、IDE拡張 | 端末ごとにOSやGitの更新状況が異なる |
| CI/CD | GitHub Actions self-hosted runner、Jenkins、GitLab Runner、Azure DevOps Agent | 古いOSイメージや固定バージョンのGitが残りやすい |
| API連携 | GitHub Apps、社内ポータル、監査ツール、Webhook処理 | 実行環境のTLSライブラリが古い可能性がある |
| セキュリティ製品 | SCA、SBOM、脆弱性管理、コードスキャン連携 | ベンダー製品の内部実装を把握しにくい |
| ネットワーク中継 | プロキシ、SSLインスペクション、CASB、DLP | 通信経路上でTLS設定が変更される場合がある |
| コンテナ・VM | 古いベースイメージ、長期稼働サーバー | アプリは新しくてもOSライブラリが古い場合がある |
今回の対応では、GitHubの画面が開けるかどうかだけでなく、誰が、どの環境から、どのTLSスタックでGitHubに接続しているかを棚卸しする必要があります。
スケジュールをリスク管理の基準日にする
GitHub の予定では、2026年7月14日に brownout と呼ばれる一時的な無効化が実施されます。時間は 00:00〜18:00 UTC で、日本時間では 2026年7月14日 9:00 から 7月15日 3:00 までです。この brownout では SHA-1 が一時的に無効化されますが、CDN は対象外とされています。完全無効化は 2026年9月15日で、GitHub およびパートナーCDNの HTTPS/TLS における SHA-1 が無効化される予定です。(The GitHub Blog)
| 日付 | 変更内容 | 組織側の見方 |
|---|---|---|
| 2026年4月20日 | GitHub が SHA-1 in HTTPS の廃止予定を告知 | 影響調査を開始する基準日 |
| 2026年7月14日 00:00〜18:00 UTC | brownout。SHA-1を一時的に無効化。CDNは対象外 | 本番相当の接続テスト日として扱う |
| 2026年9月15日 | GitHub とパートナーCDNで完全無効化 | 未対応環境は接続失敗リスクが高まる |
特に注意すべきなのは、7月の brownout で問題が出なかったとしても、9月の完全無効化で初めて影響が出る可能性がある点です。GitHub の告知では brownout はCDNを対象外としているため、CDN経由の接続や一部の配信経路に依存する処理は、7月の確認だけで安全と判断しない方がよいでしょう。(The GitHub Blog)
なぜ SHA-1 廃止はセキュリティ上重要なのか
SHA-1 は古くから使われてきたハッシュアルゴリズムですが、現在のセキュリティ基準では安全な選択肢とは見なされにくくなっています。NIST は SHA-1 に依存している場合、より安全な SHA-2 または SHA-3 系列へ移行することを推奨しています。(NIST)
TLSの文脈でも、IETFの RFC 9155 は TLS 1.2 / DTLS 1.2 のデジタル署名における MD5 と SHA-1 の利用を非推奨とし、クライアントが signature_algorithms 拡張に MD5 や SHA-1 を含めてはならないとしています。なお、RFC 9155 は HMACで使われるSHA-1まで一律に廃止する文書ではありません。(RFCエディタ)
つまり今回の GitHub の変更は、GitHub だけの独自判断というより、暗号技術全体の移行トレンドに沿ったものです。組織としては「GitHub対応」という狭い範囲で見るのではなく、古い暗号方式への依存を減らす継続的なセキュリティ改善として位置づけるべきです。
影響が大きい組織の特徴
次の条件に当てはまる組織は、GitHub platform security and HTTPS connectivity の変更による影響を早めに確認すべきです。
| 組織・環境の特徴 | 想定されるリスク |
|---|---|
| 長期サポート切れ、または更新が遅れているOSを使っている | TLSライブラリや証明書検証の実装が古い |
| ビルドサーバーや踏み台サーバーを長期間更新していない | Git pull、依存関係取得、リリース処理が失敗する |
| Dockerベースイメージを固定している | イメージ内のOpenSSL、Git、curlが古いまま残る |
| Java、Python、Node.js、Rubyなどの古いランタイムを使っている | GitHub API接続やWebhook処理でTLSハンドシェイクが失敗する可能性がある |
| 社内プロキシやSSLインスペクションを使っている | クライアントとGitHubの間で暗号設定が変わる可能性がある |
| 監査・脆弱性管理ツールがGitHub APIに依存している | セキュリティ監視やコンプライアンス証跡が途切れる |
| GitHub Enterprise Cloudをグローバル拠点で利用している | 国・拠点ごとのネットワーク機器差分で一部だけ障害化する |
特に Security teams、compliance leads、platform architects は、単に「開発者が困るかどうか」ではなく、ソフトウェア供給網、監査ログ取得、リリース運用、インシデント対応に影響するかを基準に優先順位を付ける必要があります。
優先順位は「古い環境」ではなく「業務停止インパクト」で決める
SHA-1廃止対応では、古い端末をすべて一斉に探すより、まず業務影響が大きい接続経路から確認する方が現実的です。
| 優先度 | 対象 | 理由 | 最初に確認すること |
|---|---|---|---|
| P0 | 本番リリース、障害対応、セキュリティ監視に使うGitHub接続 | 失敗時の事業影響が大きい | CI/CD、監査ツール、緊急デプロイ手順 |
| P1 | GitHub APIを使う社内システム | 利用者が気づく前に処理停止する可能性がある | 実行環境、TLSライブラリ、APIクライアント |
| P1 | self-hosted runner、ビルドエージェント | 古いOSや固定イメージが残りやすい | OS、Git、OpenSSL、curl、証明書ストア |
| P2 | 開発者端末のGit over HTTPS | 利用者からの問い合わせが増えやすい | Gitバージョン、OS更新、IDE連携 |
| P2 | 社内プロキシ、SSLインスペクション | 影響範囲が広く、原因切り分けが難しい | TLSポリシー、例外設定、ログ |
| P3 | ブラウザ閲覧のみの利用 | 最新ブラウザなら影響は比較的小さい | ブラウザ更新ポリシー |
判断基準は、「接続元の古さ」だけでは不十分です。たとえば、古い開発用PCよりも、古いまま動いているリリース用Jenkinsエージェントの方が優先度は高くなります。障害時に誰が困るかではなく、止まると何ができなくなるかで判断してください。
まず作るべき棚卸しリスト
影響調査では、最初から完璧なCMDBを作ろうとすると進みません。まずは GitHub への HTTPS 接続を発生させるものを、以下の項目で一覧化します。
| 項目 | 記入例 | 確認ポイント |
|---|---|---|
| 接続元名 | Jenkins release agent 01 | サーバー名、ツール名、ジョブ名を明確にする |
| 用途 | 本番リリース時のgit pull | 業務影響を判断できる粒度で書く |
| 接続先 | github.com、api.github.com、raw.githubusercontent.com など | API、Git、コンテンツ取得を分ける |
| 実行環境 | Ubuntu、Windows Server、コンテナ、VM | OS更新の可否を確認する |
| 利用コンポーネント | Git、curl、Java、OpenSSL、libcurl | TLSを担う部品を特定する |
| 管理者 | Platform team、Security team、外部ベンダー | 対応責任者を決める |
| 重要度 | P0、P1、P2 | 9月までの対応順を決める |
| 検証状況 | 未確認、成功、要修正 | brownout前後で更新する |
この棚卸しは、セキュリティチームだけで完結しません。Platform team、SRE、DevOps、IT管理、ネットワーク、コンプライアンス担当を巻き込み、GitHubに接続しているがGitHub管理者からは見えないシステムを洗い出すことが重要です。
実務で使える確認手順
ブラウザは github.dev で接続確認する
GitHub は、ブラウザの確認方法として、SHA-1 がすでに無効化されている github.dev へのアクセスを案内しています。接続エラーなく読み込める場合、そのブラウザはより新しい HTTPS 構成に対応しているとされています。(The GitHub Blog)
ただし、これは主にブラウザ確認のための簡易テストです。ブラウザで成功したからといって、同じ端末上のGit CLI、IDE、APIクライアント、社内プロキシ経由の全接続が安全とは限りません。
Gitクライアントは「Git本体」と「TLSバックエンド」の両方を見る
GitHub は、Gitクライアントについて、最近のバージョンのGitを使い、OSやコンポーネントを最新に保つことを推奨しています。また、GitはHTTPS対応のために複数のライブラリやバックエンドを使う場合があり、LinuxではOpenSSLがTLSバックエンドとして使われる例が挙げられています。(The GitHub Blog)
確認時は、次のようにGit本体だけでなく関連コンポーネントも見ます。
git --version
curl --version
openssl versionWindows環境では、Git for Windows、Git Credential Manager、社内プロキシ、OSの証明書ストアの組み合わせも確認対象です。macOSでは、システムのTLS実装や開発ツールの更新状況が関係します。Linuxでは、OpenSSL、GnuTLS、libcurl、ca-certificates、ディストリビューションのサポート状態をあわせて確認してください。
API連携はランタイムとライブラリを確認する
GitHub APIに接続するアプリケーションでは、コード上のAPIエンドポイントだけでなく、実行環境のTLS対応を確認します。GitHub もAPI利用について、モダンなフレームワークまたはライブラリを使うよう案内しています。(The GitHub Blog)
確認対象は、たとえば次のようなものです。
| 言語・環境 | 見るべきポイント |
|---|---|
| Java | JDK/JREのバージョン、信頼ストア、HTTPクライアントライブラリ |
| Python | Python本体、OpenSSLリンク、requests/urllib3 |
| Node.js | Node.jsのバージョン、TLS設定、HTTPクライアント |
| Ruby | Ruby本体、OpenSSL拡張、Net::HTTPや利用Gem |
| Go | Goランタイム、ビルド済みバイナリの再ビルド要否 |
| .NET | .NETランタイム、OS側TLS設定、HttpClient |
古いアプリでは、TLS設定をコードで固定していることがあります。たとえば「特定のプロトコルだけを許可する」「古い暗号スイートを明示する」「証明書検証を独自実装する」といった処理がある場合、GitHub側の変更で接続が失敗する可能性があります。
brownoutを本番同等テストとして活用する
2026年7月14日の brownout は、単なる様子見ではなく、本番相当の接続テストとして使うべきです。特に日本時間では業務時間中に開始されるため、事前に観測項目を決めておくと効果的です。
| brownout前に準備すること | 目的 |
|---|---|
| 重要ジョブの一覧を作る | どの処理がGitHubに依存しているか明確にする |
| 監視項目を決める | TLSエラー、API失敗、Git clone失敗を検知する |
| 担当者を割り当てる | Security、Platform、Network、DevOpsの連携を早める |
| 一時回避策を決める | リリース停止、ジョブ延期、代替手順を判断しやすくする |
| ログ保存先を決める | 9月の完全無効化前に再発防止へつなげる |
brownout中に確認したいログは、Gitの標準出力だけではありません。CI/CDのジョブログ、プロキシログ、APIクライアントのエラーログ、ネットワーク機器のTLS関連ログ、セキュリティ製品の通信ログも確認します。
よくあるエラーパターンには、TLS handshake failure、unsupported signature algorithm、certificate verify failed、SSL connection error などがあります。ただし、製品やライブラリによって表示は異なります。エラー文だけで判断せず、どの接続元・どのTLS実装・どの経路で失敗したかを記録してください。
リスク低減策は「更新」「標準化」「例外管理」の3段階で進める
まず更新できるものを更新する
最も効果的な対策は、古いOS、Git、ブラウザ、TLSライブラリ、ランタイムを更新することです。GitHubの告知でも、ブラウザ、API利用ライブラリ、Gitクライアントについて、モダンで更新されたものを使うことが推奨されています。(The GitHub Blog)
特に優先したい更新対象は次の通りです。
| 対象 | 推奨アクション |
|---|---|
| Gitクライアント | サポート中の最新版系へ更新する |
| CI/CDエージェント | OSイメージ、Git、curl、OpenSSLを更新する |
| コンテナイメージ | ベースイメージを更新し、再ビルドする |
| API連携アプリ | ランタイムとHTTP/TLSライブラリを更新する |
| プロキシ・SSLインスペクション | TLSポリシーと証明書チェーン処理を確認する |
| 開発者端末 | OS更新、ブラウザ更新、Git更新を標準化する |
ポイントは、アプリケーションだけを更新して終わりにしないことです。TLSはOS、ライブラリ、ランタイム、ネットワーク機器が関係するため、表面上のアプリバージョンだけでは判断できません。
標準イメージと標準ランタイムを決める
Platform architects にとって重要なのは、個別対応を減らすことです。各チームが自由に古いDockerイメージや古いJDKを使っている状態では、今回のような暗号方式の廃止があるたびに影響調査が難しくなります。
組織として、次のような標準を用意すると対応が安定します。
| 標準化する項目 | 具体例 |
|---|---|
| CI/CDの標準イメージ | サポート中のOS、Git、curl、OpenSSLを含むイメージ |
| 開発端末の標準構成 | OS更新ポリシー、Git更新、ブラウザ更新 |
| API連携の標準ランタイム | サポート中のJava、Python、Node.js、.NETなど |
| GitHub接続の標準経路 | プロキシ利用有無、SSLインスペクションの扱い |
| 監査ログ取得方法 | GitHub API接続に失敗した場合の検知方法 |
標準化の目的は、統制を強めることだけではありません。障害時に「どの環境なら安全か」を素早く判断できるようにすることです。
更新できない環境は例外として管理する
すぐに更新できない古いシステムがある場合は、「例外」として管理します。例外管理では、単に残す理由を書くのではなく、期限、代替策、業務影響を明確にします。
| 例外管理項目 | 記載すべき内容 |
|---|---|
| 対象システム | システム名、接続元、GitHub接続用途 |
| 残す理由 | ベンダー制約、移行中、互換性問題など |
| リスク | 9月15日以降に失敗する可能性がある処理 |
| 暫定対策 | 接続経路変更、ジョブ移設、手動手順など |
| 期限 | 完全無効化前の対応完了日 |
| 責任者 | 技術責任者と業務責任者 |
Compliance leads は、この例外管理を監査証跡として残しておくとよいでしょう。暗号方式の廃止対応は、単なるIT運用ではなく、セキュリティ基準への適合性にも関係します。
GitHub Enterprise Server 利用組織も無関係ではない
GitHub Enterprise Server は今回の GitHub 側の変更対象外です。GitHub の告知でも、GitHub Enterprise Server は影響を受けないと明記されています。(The GitHub Blog)
ただし、GitHub Enterprise Server だけを使っている組織でも、次のような場合は確認が必要です。
| ケース | 確認すべき理由 |
|---|---|
| GitHub Enterprise Cloud と併用している | Cloud側の接続が影響を受ける |
| GitHub.com上のOSSリポジトリを参照している | 依存関係取得やビルドでgithub.comへ接続する |
| GitHub APIを外部ツールが利用している | 監査・分析・セキュリティ製品がCloud APIを使う可能性がある |
| 将来Cloud移行を計画している | 移行前に接続基盤を更新しておく必要がある |
「自社はGHESだから対象外」と即断するのは危険です。GitHub.comへの接続がゼロであることを、CI/CD、開発端末、プロキシログ、依存関係管理の観点から確認してください。
Git over SSHへ逃がす判断は慎重にする
HTTPS経由のGit接続に不安があると、Git over SSHへ切り替える案が出ることがあります。確かに今回の告知はHTTPS/TLSに関するものですが、SSHへの一括切り替えを安易な回避策にするのはおすすめできません。
理由は、認証・監査・鍵管理・ネットワーク制御の前提が変わるためです。HTTPSではトークン管理やSSO、プロキシ制御を前提にしていた組織でも、SSHに切り替えると鍵の棚卸し、失効、端末紛失時の対応、監査ログの見方を再設計する必要があります。
SSHを使う場合は、次の点を事前に確認してください。
| 確認項目 | 判断基準 |
|---|---|
| 鍵管理 | 個人鍵の作成、保管、失効手順が明確か |
| SSO・認可 | 組織のアクセス制御ポリシーと整合しているか |
| 監査 | 誰がどのリポジトリへアクセスしたか追跡できるか |
| ネットワーク | SSH通信が許可されているか、プロキシ要件と矛盾しないか |
| 運用負荷 | 開発者・CI/CD双方で運用できるか |
基本方針としては、SSHへ逃がすよりも、HTTPS接続環境をモダンなTLS構成へ更新する方が望ましいです。
失敗しやすいポイント
ブラウザ確認だけで完了扱いにする
GitHub の github.dev テストは有用ですが、ブラウザ確認だけでは自動化環境のリスクを確認できません。CI/CD、API連携、セキュリティ製品、プロキシ経由の接続を別枠で確認してください。
Gitのバージョンだけを見てTLSバックエンドを見ない
Git本体が比較的新しくても、OSやOpenSSL、libcurl、証明書ストアが古い場合があります。特にLinuxサーバーやコンテナでは、Git、curl、OpenSSL、ca-certificatesをセットで確認することが重要です。
7月の brownout で問題がなければ安全と判断する
7月の brownout はCDNを対象外としています。9月15日の完全無効化ではGitHubとパートナーCDNが対象になるため、7月に問題が出なかった接続でも、9月前に再確認してください。(The GitHub Blog)
ベンダー製品の内部接続を見落とす
脆弱性管理、コード品質、SBOM、監査、バックアップ、リリース管理などの製品が、内部でGitHub APIやHTTPS接続を使っていることがあります。自社管理のコードだけでなく、SaaSやエージェント型製品も対象に含めます。
例外を「後で対応」にする
完全無効化の日付が決まっている変更では、「後で対応」はリスクになります。更新できない環境は、期限付きの例外として管理し、9月15日前に廃止、移行、代替手順のいずれかを決めてください。
Security teams が取るべきアクション
Security teams は、暗号方式の廃止をセキュリティ改善テーマとして扱い、組織全体のリスク可視化を進めます。
| アクション | 実施内容 |
|---|---|
| 影響範囲の定義 | github.com、GitHub API、Git over HTTPS、CDN経由の接続を対象にする |
| リスク分類 | P0〜P3で業務影響を整理する |
| 監視強化 | TLSエラー、API失敗、Git操作失敗を検知する |
| brownout対応 | 7月14日の観測体制を整える |
| 例外管理 | 更新できない環境の期限と責任者を明確にする |
Security teams がやるべきことは、全端末の詳細調査を一人で抱えることではありません。各チームが調査しやすい基準、テンプレート、期限を示すことです。
Compliance leads が取るべきアクション
Compliance leads は、今回の変更を監査・統制の観点で整理します。SHA-1は業界全体で移行が進む古いアルゴリズムであり、NISTもSHA-2またはSHA-3への移行を推奨しています。(NIST)
| アクション | 実施内容 |
|---|---|
| 証跡化 | 影響調査、更新計画、例外承認を記録する |
| ポリシー確認 | 暗号方式、TLS、外部SaaS接続に関する社内基準を確認する |
| ベンダー確認 | セキュリティ製品や連携ツールのGitHub接続対応を確認する |
| 監査対応 | いつ、誰が、どのリスクを受容したか説明できる状態にする |
監査で重要なのは、「問題が起きなかった」ことではなく、変更を認識し、影響を評価し、優先順位を付けて対応したことを説明できる状態です。
Platform architects が取るべきアクション
Platform architects は、今回の対応を一時的な個別修正で終わらせず、プラットフォーム標準の改善につなげます。
| アクション | 実施内容 |
|---|---|
| 標準イメージ整備 | CI/CD、開発コンテナ、ランナーの標準イメージを更新する |
| 接続経路の整理 | GitHubへのHTTPS接続経路とプロキシ設定を明確にする |
| ランタイム標準化 | サポート中の言語ランタイムとHTTPクライアントを推奨する |
| 自動検出 | 古いOS、古いGit、古いOpenSSLを検出する仕組みを作る |
| 再利用可能な手順 | チームごとに使える確認手順とチェックリストを提供する |
特にCI/CD基盤では、古いビルドエージェントが複数チームに共有されていることがあります。1つの古いランナーが複数のプロダクトリリースを止める可能性があるため、ランナー単位での棚卸しを優先してください。
実行チェックリスト
最後に、GitHub platform security and HTTPS connectivity を使う組織が取るべき行動を整理します。
| 期限の目安 | やること |
|---|---|
| すぐ | GitHubへのHTTPS接続元を棚卸しする |
| すぐ | P0/P1のCI/CD、API連携、監査ツールを特定する |
| 2026年7月14日前 | 古いOS、Git、curl、OpenSSL、ランタイムを更新する |
| 2026年7月14日 | brownout中に本番相当の処理を監視する |
| brownout後 | 失敗ログを分析し、9月前に修正する |
| 2026年9月15日前 | CDN経由を含む接続を再確認する |
| 継続的に | 古い暗号方式や古いTLS環境を例外管理する |
今回の GitHub starts sunsetting SHA-1 for HTTPS traffic は、単なる接続仕様の変更ではなく、組織の開発基盤がどれだけ古い暗号方式に依存しているかを確認する機会です。
まずは、GitHubにHTTPS接続している人・ツール・自動化環境を棚卸しし、P0/P1の業務影響が大きい経路から更新してください。7月14日の brownout を検証機会として使い、9月15日の完全無効化までに、更新できない環境を例外として管理する。これが、Security teams、compliance leads、platform architects が優先すべき現実的なリスク低減策です。
コメント