.NET の崖：.NET 8と.NET 9のパッチ提供が終了するとどうなるのか

要約

1つのリリース日。2つのフレームワーク。その後はパッチが一切不要。

2026年11月10日、マイクロソフトは「.NET 8」（現在の長期サポート版）と「.NET 9」（現在の標準サポート版）の両方について、同日にサポートを終了します。これは、単に日程が偶然重なっただけのものではありません。この日をもって、これら上でまだ稼働しているすべてのアプリケーションに対するパッチの提供が、永久に停止されるのです。

‍

組織で.NET 8または.NET 9を本番環境で運用している場合、このガイドでは、「サポート終了」によって実際にどのような変化が生じるのか、規制対象のチームがデータ漏洩ではなくコンプライアンスや保険の観点からその影響を真っ先に感じやすい理由、そして今後の現実的な2つの選択肢、すなわち.NET 10への移行、あるいは継続的なセキュリティサポートによるギャップの解消について解説します。

‍

このガイドで取り上げる内容：「サポート終了」によって実際に何が停止するのか、コンプライアンスや保険上のリスクが、実際の情報漏洩が発生するより前に表面化することが多い理由、パッチが適用されていない単一のフレームワークが、その上に構築されたすべてのシステムにどのようにリスクを波及させるのか、そして「崖っぷち」から脱却するための2つの道筋（90日間の計画を含む）。

• 2026年11月10日：マイクロソフトが「.NET 8」および「.NET 9」向けのセキュリティ更新プログラムの提供を終了する日
• 同じ日にサポートが終了する2つのフレームワーク：LTS版とSTS版が同時に
• 「.NET 6」のサポート終了後に56件のCVEが公表され、これらは「.NET 6」向けのNESで修正された

‍

この締め切りがなぜ異例なのか

LTS版とSTS版のリリース期間は、通常、同時に終了することはありません。

マイクロソフトの.NET のリリースサイクルは、リスクを分散させるように設計されています。.NET 8のような長期サポート（LTS）リリースには3年間のパッチ提供が行われるのに対し、.NET 9のような標準サポート（STS）リリースには18ヶ月間のパッチ提供が行われるため、STSリリースは、その前のLTSリリースよりも6ヶ月早くサポートが終了することになります。

‍

2026年11月10日は、このオフセットが初めて解消される日です。.NET 8（2023年11月出荷）と.NET 9（2024年11月出荷）は、どちらも同じ暦日にサポート期間の上限に達します。これは、マイクロソフトが2025年9月に、.NET 9を皮切りに、STSサポート期間を18ヶ月から24ヶ月に延長したためです。 これにより、.NET 9のサポート終了日は、2026年5月12日から、.NET 8の3年間のサポート期間が終了する日に変更されました。

‍

実際、直近の2つのリリースを混在させて運用することでリスクを分散させていたチーム（以前は一般的かつ妥当な戦略だった）は、今回のサイクルでは段階的な導入によるメリットを一切得られないことになる。 現在の.NET 8や.NET 9の導入状況がどうであれ、すべてについて同じ日付に向けた計画を立てる必要があります。また、これが最後になるわけでもありません。24カ月のポリシーに基づき、次期STSリリースである.NET 11は、2028年11月に.NET 10と同時にサポート終了を迎える見込みです。

‍

サポート終了そのものは目新しいことではありません： .NET 6は、.NET 7の6か月後となる2024年11月12日に、予定通りサポート終了を迎えました。Microsoftやエコシステム側が期限を延長するだろうと想定したり、サポート終了（EOL）したランタイム上の未修正のCVEは注目されないだろうと考えたりして、これを「目安」として扱ったチームは、その後1年間、監査人、保険会社、場合によっては顧客に対して、未修正のリスクについて説明に追われることとなりました。 2026年11月10日は、その同じ期限であり、影響範囲は2倍に拡大しています。

「サポート終了」が意味しないこと

だからといって、.NET 8 や.NET 9 が動作しなくなるわけではありません。アプリケーションは、前日とまったく同じように実行され続けます。そのため、社内でこの期限の重要性を過小評価しがちになります。11月11日になっても、目に見える形で不具合が発生することはないからです。変化は目立たないものですが、規制対象となる組織の多くにとっては、より重大な影響をもたらします。これについては、次に説明します。

‍

11月10日には実際に何が変わるのか

パッチの提供は終了しても、脆弱性は消えることはありません。

マイクロソフトがパッチの提供を停止したからといって、セキュリティ研究者や攻撃者が「.NET 」の脆弱性を探し続けるのをやめるわけではありません。.NET 8 および.NET 9 のコードパスに影響を与える新たな CVE は、今後も発見され続けるでしょう。唯一変わるのは、公式の修正プログラムが提供されなくなるという点だけです。 11月10日は「パッチ・チューズデー」であり、マイクロソフトは通常、サポート終了となるバージョンの最終リリースを、その最後のパッチ・チューズデーに公開します。それ以降に公表された脆弱性については、マイクロソフトによる修正は行われません。HeroDevsのセキュリティチームは、これを「フォーエバー・デイ問題」と呼んでいます。つまり、ランタイムのサポートが終了すると、それに対する新たに公表された脆弱性には、修正への道が閉ざされてしまうのです。

‍

パッチの配信対象はランタイムだけにとどまりません。.NET 8 または.NET 9 のインストール構成は 4 つの部分から成り立っていますが、そのすべてに対して修正プログラムの提供が終了します。具体的には、.NET ランタイム、ASP.NET Core 共有フレームワーク、WPF および Windows Forms 用の Windows デスクトップランタイム、そして MSBuild を含む.NET SDK です。.NET 6 では、サポート終了後の状況が示されています。 HeroDevsが .NET 6向けのNESで提供した修正は、これらすべてのコンポーネントに反映されました。具体的には、ランタイムにおけるWebSocketの解凍時のサービス拒否（DoS）脆弱性とLinux診断ソケットの露出（6.0.44）、KestrelにおけるHTTP/3制御ストリームのサービス拒否（DoS）脆弱性（6.0.45）、 WPFのフォントおよびグリフレンダリングにおけるヒープの範囲外書き込み（6.0.44）、およびSDKにおけるMSBuildのダウンロードファイル名偽装の修正とdotnet watchのオリジンチェック（6.0.45および6.0.46）。

4つの実際的な結果

• 脆弱性スキャナーは、際限なく警告を出し続けます。SCA や脆弱性管理ツールは、.NET 8/9 に対する CVE を引き続き検出しますが、サポート対象のランタイムとは異なり、それらのいずれについても「修正済み」の状態になることはありません。11月10日以降のスキャンはすべて、増え続ける未処理事項に追加されていくだけです。
• スキャナーは、実際の脆弱性の影響範囲を見落とすこともあります。マイクロソフトは、サポート終了済みの.NET のバージョンについてはCVEやパッチを公開していないため、新しいCVEではサポート対象のバージョンのみが影響を受けると記載され、その記録と照合するスキャナーは、.NET 8や.NET 9については警告を出せません。 2025年10月14日に公開された、ASP.NET Core Kestrel サーバーの「リクエスト・スマグリング」脆弱性（CVE-2025-55315、深刻度9.9）がその例です。.NET 6には脆弱性がありましたが、CVEには記載されておらず、マイクロソフトもパッチを適用しませんでした。HeroDevsは、その3日後に.NET 6.0.39向けのNESで修正プログラムをリリースしました。
• 深刻度スコアは固定されたものではありません。CVSS 4 や 5 の時点では優先度が低いと見なされていた CVE でも、CISA の「既知の悪用済み脆弱性（KEV）」カタログに追加されたり、EPSSの悪用確率スコアが急上昇したりすると、一夜にして緊急性を帯びる可能性があります。こうした再分類は、最初の開示から数年経ってから起こることもあります。サポート対象のランタイムでは、それによってパッチ適用サイクルが開始されるだけです。 EOL（サポート終了）状態のランタイムでは、適用できるパッチが存在しません。
• 深刻度の低い発見事項が、連鎖して深刻度の高い問題につながる可能性があります。あるコンポーネントにおける些細な問題が、スタック内の他の要素と組み合わさることで、多段階の攻撃経路における「欠けていた一環」となる可能性があります。個々のCVSSスコアでは、そのような組み合わせは決して反映されません。それを反映できるのは、自社独自のリスク分析のみであり、監査人は、その分析結果が文書化されていることをますます期待するようになっています。

これは.NET に限った話ではありません。どのオープンソースエコシステムにも、すでにサポート終了となり、既知のCVEが存在し、アップストリームからの修正が見込めないパッケージが数多く存在します。.NET 8と.NET 9により、そのリストにさらに2つの広く利用されているランタイムが、同じ日に、エンタープライズ規模で追加されようとしています。

‍

実際に最初に影響が出る場所

通常、その代償は、情報漏洩ではなく、監査や更新の際に支払われることになる。

多くのチームは、EOL（サポート終了）リスクを「ハッキングされるかもしれない」と捉えています。規制対象の組織にとって、より差し迫ったリスクは、サポート終了したソフトウェアを黙って使い続けることで、すでに遵守が義務付けられている規制枠組みに違反することになり、しかもその事実が、自らがコントロールできないタイミングで発覚してしまうという点にあります。

サイバー保険も同様の理屈に基づいています

保険会社は、このリスクを直接価格に反映させてきました。Coalitionの「2023年サイバー保険金請求レポート」によると、サポート終了済みのソフトウェアを運用している組織は、企業の規模にかかわらず、セキュリティインシデントに見舞われる確率が3倍高く、また、未修正の重大な脆弱性が1つでも存在する被保険者は、保険金請求を行う確率が33％高くなることが明らかになりました。

‍

保険会社は、EOL（サポート終了）ソフトウェアに関連する保険金請求について、いくつかの手段を通じて拒否または制限することができます。具体的には、過失の有無にかかわらず適用される特定除外条項、アプリケーションにセキュリティ対策に関する虚偽の記載があった場合の契約解除、およびサポート対象外のコンポーネントが関与する侵害が発生した場合に補償が無効となる保証条項などです。また、多くの保険契約では、復旧費用は事前の状態に戻すためのものに限られており、アップグレード費用は対象外となっているため、「侵害発生後に修復する」という戦略は、保険会社が補償する対象にはなりません。

‍

その窮地からの脱出法

監査人や引受会社は、あなたが「最新の状態」であることを求めているわけではありません。彼らが求めているのは、あなたが「裏付けがある」ということです。

これは、締め切りのプレッシャーに追われる多くのチームが見落としがちな点です。上記のフレームワークのいずれも、実際には「最新バージョンを使用しなければならない」とは明記していません。それらは、運用している環境が何であれ、ベンダーによるサポートとパッチ適用への取り組みを実証できなければならないと定めているのです。これは完全な移行よりも低いハードルであり、長期にわたるベンダーによるサポートがクリアするように設計されたハードルなのです。

‍

引受会社や監査人が通常認めているもの：

• 特定のコンポーネントおよびバージョンを明記した、署名済みのサポート契約書
• そのバージョンにおけるCVEの修正に関する、日付入りの文書化された記録
• 当該サポートの範囲および実施頻度を確認するベンダーの証明書

つまり、前述のコンプライアンスや保険上のリスクは、11月10日までに移行を完了させるだけでは解決されません。解決するには、現在稼働中の環境がどのようなものであれ、また移行のスケジュールがどうであれ、サポート対象となるパッチの提供体制を確保する必要があります。真の選択肢は、現実的なスケジュールで移行を進めるか、その間、そのギャップを文書化され、監査可能なサポート関係へと転換するか、という点にあります。

‍

現実的な選択肢

.NET 10 への移行、サポート期間が延長されたブリッジ、あるいはその両方を行う。

.NET 8 または.NET 9 を本番環境で運用しているすべての組織は、その選択が明示されているかどうかにかかわらず、現在この 2 つの道のいずれかを選ばざるを得ない状況にあります。ほとんどの企業は、現実的に移行可能なアプリケーションは移行し、移行不可能なアプリケーションについてはブリッジを構築するという、両方のアプローチを講じることになります。

方法 A：.NET s 10 への移行

.NET バージョン10は現在のLTSリリースであり、.NET 8や.NET 9をまだ使用しているすべてのシステムにとって、長期的な移行先として想定されています。マイクロソフト自身のリリースノートには、JITおよびランタイムのパフォーマンス向上、ポスト量子暗号のサポート拡充、すべての主要プラットフォームにおける最新のTLS 1.3対応、コンソールアプリがDockerfileなしでネイティブにコンテナイメージを作成できる機能、およびベクトル検索やネイティブJSONサポートを含むEntity Framework Core 10の更新などが挙げられています。 これらの機能だけでも、期限の有無にかかわらずアップグレードする価値は十分にあります。エンタープライズアプリケーションのアップグレードは、特に推移的依存関係、サードパーティ製ライブラリの互換性、回帰テストが絡んでくると、チームが当初想定していたよりも時間がかかるのが常です。コンプライアンスのタイムライン内で移行が可能な場合は、これが最適な主要なアプローチとなります。不可能な場合は、代替案として「パス B」が用意されています。

経路 B：Never-Ending Support (NES) を使用したブリッジ（用途：）.NET

.NET 用のNESは、サポートが終了した.NET 6、8、または9のランタイムに代わる、安全でそのまま置き換え可能な代替ソリューションです。コードの変更は一切必要ありません。監査担当者や引受担当者が求める、サポート対象のパッチストリームを復元すると同時に、Microsoftが設定したスケジュールではなく、お客様自身が管理するスケジュールに従って移行を進めることができます。

• .NET のセキュリティプロセスを直接確認できます。HeroDevsは.NET 財団の企業スポンサーであり、Microsoft、Red Hat、IBM、Canonicalと共に「.NET Security Group」に参加しています。このグループは、情報公開前のパッチ適用と、.NET の同時リリースを調整する役割を担っています。メンバーは公開の約1週間前にソースパッチを受け取るため、.NET ビルド向けのNESは、Microsoftと同じ「パッチ・チューズデー」にリリースされます。
• この課題についてはすでに実績があります。 .NET 向けのNESは、9つの.NET 6のリリースにおいて、62件のCVEに対する修正プログラムを提供しており、そのうち56件は、Microsoftが.NET 6へのパッチ提供を終了した後に公表されたものです。
• プラットフォームの変更は不要です。WindowsとLinuxの両方で、実行時の動作もデプロイモデルも同じです。唯一変わるのは、パッチが継続的に提供されるという点だけです。
• スキャナーが読み取れるOpenVEXステートメント。HeroDevsは、.NET のリリースについて、NES（NES for ）形式のOpenVEXステートメントを公開しています。これにより、スキャナーは、サポート終了したランタイムに対する漠然とした検出結果のリストではなく、そのビルドで修正されたCVEと、適用対象外のCVEを具体的に報告するようになります。
• 継続的なエコシステムへの投資に支えられています。HeroDevsの2,000万ドル規模の「オープンソース・サステナビリティ・ファンド」は、.NET を含む、オープンソース・エコシステム全体のメンテナーを支援しています。

‍

これを計画に落とし込む

11月10日までの現実的な道筋。

この対応をうまくこなしているチームは、ポートフォリオ全体にわたる「移行かブリッジか」という単一の決定を待つことはありません。彼らは、短期的かつ具体的なタイムラインに基づき、アプリケーションごとに優先順位を付けます。以下に、開始時点で残りの期間がどれほどあるかに関わらず、実用的な枠組みを紹介します。

ステップ1：現状把握（第1～2週）

• .NET 8 または.NET 9 上で稼働しているすべての本番用アプリケーション（社内ツールやベンダー提供のシステムを含む）を一覧表示してください。
• 規制対象データ（PHI、カード保有者データ、PII）にアクセスするデータ、またはSOC 2/ISO 27001の監査範囲内に含まれるデータを特定する
• .NET 10 への移行に向けた、すでに進行中で、担当者が配置された移行パスがある点にご留意ください

ステップ2：申請ごとに決定する（第3～4週）

• .NET 10 との互換性に関する作業の範囲、リソース、および期限までに現実的に完了可能かどうかが確定した場合は、移行を行う
• 移行のスケジュールが11月10日以降にずれ込む場合、アプリケーションが書き換えではなく廃止の対象となる場合、または移行作業が並行して進められている間にコンプライアンス対応範囲を現時点で確定しておく必要がある場合は、NESとの連携を図ってください。

ステップ3：実行および記録（11月10日まで）

• 移行対象者への注意：他のコンプライアンス主導のプロジェクトと同様に、範囲を確定し、担当者を割り当て、期限を厳守して進捗を管理してください。
• ブリッジ候補の皆様へ：署名済みの支援契約書とCVE是正記録は、11月10日までに、それ以降ではなく、確実に整備しておいてください。これらは、次回の監査やポリシー更新の際に提出を求められる書類となります。
• コンプライアンス、セキュリティ、および該当する場合はサイバー保険ブローカーに対し、すでに移行済みの申請だけでなく、各申請ごとの計画について簡潔に説明してください。

ステップ4：11月10日以降

• 残りのすべての「.NET 8/9」アプリケーションについて、移行済みであるか、有効なサポート契約が締結されているかを確認してください。監査人の要件を満たす第三の状態は存在しません。
• 「サポート対象」という状態が恒久的な解決策とならないよう、ブリッジが確保するはずだったスケジュールに従って、ブリッジ対象アプリケーションの移行作業を継続する

‍

HeroDevsの役割

万が一、申請の締め切りに間に合わない場合、.NET 向けのNESが役立ちます。

弊社にご相談いただく前に、すべてを完全に整理しておく必要はありません。多くの場合、最初の相談は1つ、あるいは数個のアプリケーションから始まります。具体的には、移行が明らかに期限内に完了しないケースや、次回の監査またはポリシー更新（いずれか早い方）までに、署名済みのサポート契約を締結しておく必要があるケースなどが挙げられます。

HeroDevsにNESについて相談するには.NET

.NET 6、8、9向けの、安全で即座に適用可能なパッチです。コードの変更やプラットフォームの変更は不要で、.NET セキュリティグループの情報開示プロセスを直接把握しているチームによって開発されています。

‍

カスタム見積もり

‍

出典および調査方法

本ガイドは一般的な情報提供を目的としており、法的またはコンプライアンス上の助言を構成するものではありません。PCI DSS、HIPAA、SOC 2、ISO 27001、またはその他の規制枠組みの対象となる組織は、本ガイドを参考にする前に、自組織のコンプライアンス、法務、監査の各チームと、現在の要件の詳細や発効日を含む具体的な義務について確認する必要があります。

• マイクロソフト、「.NET 10 の発表」、「.NET 8 および.NET 9 は 2026 年 11 月 10 日にサポート終了となります」、「.NET STS リリースは 24 か月間サポートされます」（2025 年 9 月 16 日）、および「.NET セキュリティグループの発表」（2025 年 10 月 14 日）、.NET ブログ。
• Coalition, Inc.の「2023年サイバー保険金請求報告書」（Businesswireを通じて2023年5月に独立して報道されたもの）によると、未解決の重大な脆弱性を抱える組織は、サイバー保険金請求が発生する確率が33％高いことが判明した。また、サポート終了済みのソフトウェアは、インシデント発生の可能性が3倍高くなる要因となっている。
• 米国保健社会福祉省、HIPAAセキュリティ規則、45 CFR §164.308(a)(1)(ii)(A) および (B)。
• ISO/IEC 27001:2022、附属書A、管理措置8.8（技術的脆弱性の管理）。
• CISAの「既知の悪用済み脆弱性（KEV）」カタログ、FIRST.orgの「エクスプロイト予測スコアリングシステム（EPSS）」。
• HeroDevs、「HeroDevsが.NET 財団に参加し、オープンソース・エコシステムの維持と成長に貢献」および.NET 財団のスポンサースポットライト（dotnetfoundation.org）：2,000万ドルのオープンソース・サステナビリティ・ファンドと、.NET セキュリティ・グループへの参加。
• HeroDevsNES for.NET 6.0.x リリースノート：バージョン 6.0.38（2025年6月4日）から 6.0.46（2026年9月9日）までのリリースにおいて、計62件のCVEが修正されました。そのうち56件は、.NET 6のサポート終了後に公表されたものです。
• HeroDevs、「ASP.NET Coreにおける評価9.9のCVE『CVE-2025-55315』に関するFAQ」（2025年11月5日）。

‍