日本の能動的サイバー防御法（Active Cyber Defense law）について、重要インフラ事業者とそのサプライヤーが押さえておくべきポイントと、現実的な対応策を解説します。
はじめに
日本の重要インフラを運用している組織、またはその運用事業者にシステムを供給している組織にとって、2026年10月1日にルールが変わりました。日本の能動的サイバー防御法（2025年法律第42号）は2025年5月16日に成立し、中核となる規定が順次施行されています。インシデント報告の義務化、政府による情報共有、官民協議会が含まれます。2027年3月31日までに、事業者は最重要システムで稼働している製品名とバージョンを政府に届け出る必要があります。さらに、通信データに関する政府の権限は2027年11月22日までに全面施行されます。
この法律をめぐる議論の多くは、通信データの政府分析や攻撃者サーバーの無害化権限といった目玉の権限に集まっています。もちろん重要です。しかし、オープンソース上で重要システムを運用するすべてのCISOとエンジニアリングリーダーが最優先で意識すべき義務がもう一つあります。それは、ソフトウェアのバージョンが政府の目に触れるようになる点です。EOL（End-of-Life：サポート終了）ソフトウェアは、社内のリスク台帳の一項目ではなくなり、規制当局から見える存在になります。
この法律は、上流のフレームワークがEOLを迎えたかどうかを考慮しません。問われるのは、日本が依存する脆弱なシステムを修正できるかどうかです。コンポーネントにアップストリームのメンテナーがいなければ、その答えは非常に厳しくなります。
法律はEOLソフトウェアについて何を定めているのか
義務の対象は、電力、ガス、水道、通信、金融、航空、鉄道、物流など15分野にわたる、指定を受けた約250の重要インフラ事業者です。対象となるのは**「特定重要電子計算機（specified critical computers）」**です。インターネットに面したファイアウォールやVPN、認証サーバー、重要施設へのアクセスを制御するシステムなどが該当します。ベンダー、グループ会社、クラウドプロバイダーが所有しているシステムでも、事業者がそれに依存している限り、対象になり得ます。
次の3つの義務が連動して、EOL問題を引き起こします。
インシデント報告（2026年10月1日施行）
事業者は、特定重要電子計算機に関するインシデントと、その発生につながり得る事象を、所管大臣と内閣総理大臣に報告する必要があります。初報は速やかに行う必要があります。政令案では、DDoS攻撃は可能な限り早く、ランサムウェアなどの攻撃は3〜5日程度以内が想定されており、続く詳細報告は30日以内です。攻撃者がEOLコンポーネントの既知の脆弱性を悪用した場合、パッチの有無にかかわらず報告義務が発生します。
資産届出（最初の期限は2027年3月31日）
事業者は、特定重要電子計算機の製品名とバージョンを届け出る必要があります。既存システムは2027年3月末まで、新規導入するシステムは導入後約4か月以内です。政府は、この届出データを未公開の脆弱性を含む脆弱性インテリジェンスと照合し、事業者に直接アラートを出す方針です。届出にEOLバージョンが含まれていれば、それは政府から見えるフラグになります。
ベンダーの義務（第42条とサイバーセキュリティ基本法）
関連する改正により、ITサプライヤーには、顧客のセキュリティを考慮した設計と、それを支える情報の共有に関する努力義務が課されます。第42条では、大臣がベンダーに脆弱性情報を共有し、製品に関する報告を求め、被害防止のための措置を依頼できます。日本向けに製品を供給する海外ベンダーも対象です。
これらの義務は連動して作用します。EOL依存関係があると、次のような連鎖的な失敗が起こります。
- そのバージョンが資産届出に載る
- 政府が既知の脆弱性と照合してアラートを出す
- アップストリームのパッチは存在しない
- 悪用されれば、修正手段がないまま報告期限のカウントが始まる
EOLソフトウェアは技術だけの問題ではない
日本の法律は、可視化と監督を土台にしています。事業者の重要システムは、バージョン単位で政府に把握されます。大臣は、最重要システムの脆弱性（ゼロデイを含む）への対処を事業者に求めることもできます。事業者にとって、パッチの当たらないEOLコンポーネントは、規制当局の監視、サービス継続性、社会的信頼の問題になります。ベンダーにとっては、顧客や所管省庁から直接問われる事項であり、次の契約を勝ち取れるかどうかを左右します。
この義務は一度きりではなく、継続的に発生します。新しい重要システムは、導入から数か月以内に届け出る必要があり、すべてのアラートに対応しなければなりません。重要システムにAngularJS（2021年12月にEOL）、Angular 18以前、Spring Security 5.x、Node.js 18、Vue 2が含まれているなら、アップストリームのメンテナーがパッチを出さないコンポーネントがすでに存在しています。
パッチのないEOL CVEの実例2件
CVE-2026-22732：Spring Security — CVSS 9.1（Critical）
この重大な脆弱性では、Spring Securityのフィルターチェーンがヘッダーを書き込む前にレスポンスがコミットされると、HTTPセキュリティレスポンスヘッダーが通知なく書き込まれません。Cache-Control、X-Frame-Options、Strict-Transport-Security、Content-Security-Policyなどのヘッダーが、単純に欠落します。影響範囲はSpring Security 5.7.xまで遡り、EOLバージョンにはアップストリームのパッチがありません。認証ポータルや運用システムがレガシーなSpring Securityに依存している場合、次の状況になります。
- 特定重要電子計算機に、アップストリームの修正がない重大な脆弱性がある
- 資産届出のバージョンを、政府がこのCVEと照合できる
- パッチを適用できないまま、政府からアラートが出る可能性が高い
- 脆弱性が悪用された場合は、インシデント報告義務が生じる（速やかな初報と30日以内の詳細報告）
CVE-2026-27970：Angular — i18n ICUメッセージ経由のXSS（CVSS 7.6、High）
このクロスサイトスクリプティング脆弱性は、Angularの国際化（i18n）パイプラインに影響します。日本語と英語のUIを提供するシステムには、特に関係の深い問題です。ICUメッセージにHTMLが含まれ、適切にサニタイズされていない場合、翻訳ファイルを侵害した攻撃者が、ユーザーのブラウザ上で実行されるJavaScriptを注入できます。影響を受けるのはAngular 18.2.14までのバージョンで、AngularチームはEOLバージョンにセキュリティ修正をバックポートしません。オペレーターポータルや管理コンソールでEOLのAngularを使っている場合、次の状況になります。
- 事業者やスタッフが使うシステムに、アップストリームのパッチがない既知のXSS脆弱性がある
- 重要システムの管理者本人から、認証情報が盗まれるリスクがある
- バージョン単位の露出が、資産届出を通じて見える状態になる
- ベンダーにとっては、第42条に基づく要請に十分に答えられない
HeroDevsのVulnerability Directoryでは、エンタープライズ製品で今も広く使われているEOLフレームワーク全般（Spring Boot、Node.js、.NET、AngularJS、Angularなど）の、数百件のCVEを追跡しています。
では、具体的に何をすればよいのか
長期的な答えは、サポート対象バージョンへの移行です。しかし、大規模なフレームワーク移行を主導した経験のある人なら、現実をご存じのはずです。こうしたプロジェクトは数か月から数年かかり、大規模なリグレッションテストが必要で、他の優先事項とも競合します。可用性と安全性が最優先となる重要インフラでは、中核システムの移行を急ぐこと自体がリスクです。
2027年3月31日の資産届出期限は、移行の完了を待ってくれません。インシデント報告もすでに始まっています。ここで力を発揮するのが、HeroDevsのNever-Ending Support（NES）です。
NESは、EOLを迎えたオープンソースソフトウェア向けの商用長期サポートです。HeroDevsのエンジニアがEOLコードベースをメンテナンスし、セキュリティ修正をバックポートして、パッチ適用済みリリースを、ドロップイン互換のパッケージとして標準レジストリ（npm、Maven、NuGetなど）経由で公開します。アーキテクチャの変更は不要です。
NESは能動的サイバー防御法への対応をどう変えるか
法律上の義務は、重要システムを運用する事業者に課され、それを供給するベンダーにも次第に課されるようになっています。NESは、こうした義務を果たすうえでの実務上の状況を変えます。
HeroDevsがEOLコンポーネントにNESを提供すると、そのコンポーネントには、セキュリティパッチを提供するアクティブなベンダー、CVE対応プロセス、文書化されたスケジュールで公開される修正がそろいます。政府から脆弱性アラートが届いたとき、HeroDevs NESは事業者に適用できる修正を提供します。
- 資産届出： 届け出るバージョンは、サポートされていないEOLリリースがフラグを立てられるのを待つ状態ではなく、アクティブなベンダーが提供する、サポート対象のパッチ適用済みビルドになります。
- アラートへの対応： 政府が脆弱性を自社システムと照合したとき、HeroDevsがトリアージ、パッチ作成、修正の提供を行います。対応できない理由を説明するのではなく、アラートに対して実際に動けます。
- インシデント報告： 悪用が実際に発生した場合でも、初報と30日以内の詳細報告で、対応が進行中の是正措置を示せます。放置された穴ではありません。
- ベンダーの義務： サプライヤーは、自社製品内のオープンソースにパッチを提供すると約束でき、顧客の期待や第42条に基づく要請にも応えられます。
- 移行までの猶予： NESは、「移行が必要なのは分かっている」と「移行が完了した」の間をつなぎます。重要システムを危険にさらさず、慎重に近代化できます。
日本の能動的サイバー防御法に関するよくある質問
日本の能動的サイバー防御法は、海外ベンダーにも適用されますか？
一部は適用されます。報告と届出の義務は日本国内の指定事業者に課されますが、第42条は、海外拠点のベンダーを含め、日本向けに製品を供給するベンダーにも及びます。実務では、事業者が契約を通じて、サプライヤーにも要件を求めるようになります。
システムはクラウドプロバイダーがホストしています。それでも対象になりますか？
対象になり得ます。重要なサービスのために事業者がそのシステムに依存している限り、ベンダー、グループ会社、クラウドプロバイダーが所有していても、特定重要電子計算機に該当する可能性があります。
EOLの依存関係がスタックの深い層にあります。それでも問題になりますか？
はい、問題になります。政府は届出バージョンを脆弱性データと照合する予定で、ベンダーも、どの製品に脆弱なコンポーネントが含まれるかを問われる可能性があります。パッチのないCVEを持つ深い層のライブラリも、届け出たシステムの一部です。
移行を計画しています。それまで待てますか？
インシデント報告はすでに施行されており、最初の資産届出期限は2027年3月31日です。移行計画は意思表示にすぎず、パッチではありません。EOLコンポーネントが取り除かれるまでは、それが届出に載るバージョンであり、アラートが指し示す対象になります。
脆弱性アラートを受け取ったらどうなりますか？
最重要システムについては、事業者が脆弱性への対処を求められることがあります。EOLコンポーネントでアップストリームのパッチがない場合、選択肢は次の3つです。急ぎの移行、規制当局が納得しないかもしれない代替的な対策（compensating controls）、またはHeroDevsのようなプロバイダーが提供するサポート対象のパッチ適用済みバージョンです。
まとめ
日本の能動的サイバー防御法は、すでに動き出しています。インシデント報告は2026年10月1日に始まり、最初の資産届出は2027年3月31日が期限、全面施行は2027年11月までに続きます。この法律によって、重要システムのバージョンが政府の目に触れるようになり、EOLソフトウェアは技術的な問題にとどまらず、規制上のリスクにもなります。
重要システムにEOLのオープンソース依存関係が含まれているなら（ほとんどのエンタープライズスタックに含まれています）、リスクかどうかを問う段階ではありません。リスクです。問うべきは、資産届出を提出する前に何をするかです。
HeroDevs Never-Ending Supportは、このギャップを埋める最もコスト効率の高い手段の一つです。EOLコンポーネントにアクティブなベンダーサポートを復活させ、新たな脆弱性に対するパッチ適用を維持し、政府から問われたときに、事業者とベンダーの双方が説得力のある答えを示せるようにします。
まずは、自社のスタックに何が含まれているかを把握しましょう。HeroDevs End of Life Datasetは、1,200万以上のパッケージバージョンを追跡する無料のリソースです。既知でパッチ未適用のCVEを持つEOLフレームワークと、それぞれに利用できるNESサポートを確認できます。
お問い合わせ
本記事の内容やHeroDevsのソリューション（NES等）について、日本語でのお問い合わせに対応しています。お気軽にHeroDevsお問い合わせページからご連絡ください。
原文: https://www.herodevs.com/blog-posts/japan-active-cyber-defense-law-eol-open-source