EOL（サポート終了）となったオープンソース・スタックが、なぜ「技術的負債」ではなく「コンプライアンス上のリスク」となるのか
ご挨拶と注意事項
エリン・ハンナフォード：こんにちは。本ウェビナー「ライフサイクル終了間近のオープンソース・スタックが、単なる技術的負債ではなく、コンプライアンス上のリスクとなる理由」へようこそ。私はエリン・ハンナフォードと申します。本日のウェビナーの進行を務めさせていただきます。
本題に入る前に、いくつかご案内があります。本日のウェビナーは録画されており、セッション終了後には、録画映像と付随するホワイトペーパーをメールでお送りいたしますので、メールボックスをご確認ください。
最後に質疑応答の時間をたっぷり設けています。ウェビナーの途中でも、コメント機能を使ってご質問やご意見をお寄せください。できる限り多くの質問にお答えします。その場で対応できないものについては、ウェビナー終了後に個別にフォローアップさせていただきます。
それでは、本日の講演者であるHeroDevsのCOO、ロブ・ナレン氏をご紹介します。ロブさん、どうぞ。
ロブ・ナレン：ありがとう、エリン。皆さんにお会いできて嬉しいです。このテーマについてお話しできるのを本当に楽しみにしています。
まず背景として、ご存知の通り、私はHeroDevsのCOOを務めています。当社の目標は、企業が社内外のコンプライアンス要件を満たせるよう支援することであり、その中には、ここで取り上げるEU CRAも含まれます。 そのために、CVEへの継続的な対応や、サポート終了となったオープンソースソフトウェアへのサポートを提供しています。企業へのサービス提供の一環として、OpenJS Foundation、Linux Foundation、Commonest Foundationといったオープンソースコミュニティと戦略的パートナーシップを結んでいるほか、Bootstrap 、Vue、.NET など、数多くのオープンソースプロジェクトとも直接連携しています。
このウェビナーでは、EU CRAとは何か、企業がどのようにコンプライアンスを確保できるかについて詳しく解説するだけでなく、この要件が導入された背景や、AIやオープンソースの進展に伴い世界的に導入される予定のその他の要件についてもご紹介します。 また、サポート終了（EOL）となったオープンソースソフトウェアに関して、組織がコンプライアンスをどのように考えるべきかについてもお話しします。最後に質疑応答の時間を設けますので、皆様からのご質問やトピックをぜひお寄せください。双方向の議論ができるのはいつも楽しみです。
歴史は繰り返す：個人データから得られる教訓
こうした点を踏まえて、歴史がいかに繰り返されるか、そして今後どのようにそこから学びを得られるかについて、簡単に振り返ってみましょう。
「サイバーレジリエンス法」について話す前に、少し視野を広げてみたいと思います。というのも、これらはいずれもまったく新しいことではないからです。現在、ソフトウェアやAIの分野で私たちが経験していることは、個人データの収集や利用の分野でかつて見られたものと同様のパターンをたどっているのです。
それでは、その傾向について見ていきましょう。約15年前、企業は、これまで誰も想像しなかった規模で個人データを活用できることに気づきました。企業にとってのこの価値にはリスクが伴い、そのリスクは主に、データの活用や利用に実質的に同意したことのない人々に降りかかったのです。最初の数年間、個人データ保護のモデルは「最善の努力」に委ねられており、その背後にはほとんど説明責任がなく、行動を規範づける明確な法律やコンプライアンス基準も存在しませんでした。
要するに、失敗が相次ぎ、人々の個人データが大規模に漏洩した結果、法規制が追いつくことになった。欧州ではGDPRが、米国ではグラム・リーチ・ブライリー法、HIPAA、そして後にCCPAが導入された。
コンプライアンスに携わる皆様なら、これらの基準の導入が決して順風満帆ではなかったことをご記憶のことでしょう。「シュレムスI判決」を、あまり良い思い出としてではないにせよ、覚えている方もいらっしゃるかもしれません。2015年、欧州司法裁判所は、米国とEU間の「セーフハーバー」枠組みが欧州市民のデータを適切に保護していないとの判断を下し、一夜にしてその有効性を無効にしました。 コンプライアンスを遵守していると思っていた何千もの企業が、突然、非コンプライアンス状態に陥りました。この事件や、その他いくつかの類似した事例や動向が、GDPRの制定を後押ししたのです。「最善を尽くす」という保護措置は、法的義務として継続的かつ強制力のあるものとなり、違反した場合には実際の罰則が科されるようになりました。
現在目撃されているのは、AIやオープンソースと引き換えに個人データが提供されるという状況であり、これまでも同様の事態が繰り返されてきました。企業はオープンソースを大規模に活用しており、AIによってその展開速度は飛躍的に加速しています。リスクはコードを通じて広がり、それに依存するすべての人々に及んでいます。こうした要因はインフラやアプリケーションのセキュリティに明確な影響を与えており、その結果、多くのセキュリティインシデントが発生しています。その一部については、後ほど詳しく説明します。
重要な点は、その対応が形式的に同一であるということです。つまり、セキュリティが「最善を尽くす」という程度の可能性にとどまらず、その実証と完全な裏付けが必須となるよう、法規制やコンプライアンス基準が整備されつつあります。こうした法規制には、EUのCRA、NIS2、DORAなどが挙げられ、米国においても数多くの要件が定められています。
オープンソースとAIがもたらすリスクの規模
オープンソースの導入状況やAIによってもたらされる変化を具体的に把握するために、Black DuckやSonatype、および業界の他の企業から提供されている有益なデータがいくつかあります。
オープンソースに関しては、その普及がどれほど広範なものになっているかについて、混乱の余地はないと思います。企業、そして根本的には世界やインターネットそのものが、オープンソースに完全に依存しているのです。背景として：
- 年間で約10兆件のオープンソースのダウンロードリクエストがあります。
- GitHubだけでも、1億5000万人以上の開発者がいます。
- 現在、すべてのコードの70％がオープンソースとなっています。
- エンタープライズアプリケーションは、1つあたり平均900以上のオープンソース依存関係を抱えています。
開発者組織と関わりのない方々にとっては意外に思えるかもしれませんが、これは単に利用規模が大きいというだけではありません。企業が依存している主要なコンポーネントの多くが、オープンソースコミュニティによって作成・配布されているという点も重要なのです。これほど多くのオープンソースが活用されている状況では、常に最新バージョンを維持し続けることはほぼ不可能に近いかもしれません。特に、企業が自社の顧客向けに特定のバージョンを提供し続けなければならないという製品ライフサイクルの要件を考えると、なおさらです。この点については、後ほど詳しく説明します。
AIに関しては、毎日のように、あるいは毎週のようにアップデートが発表されていることは、誰もが承知しているでしょう。個人的には、AIにはできない、あるいはやるはずがないと思っていたような話を、ほぼ毎日のように耳にします。AIが将来何ができるのか、何をするようになるのかについては、まだ多くの未解決の疑問がありますが、現時点でAIが得意なことは分かっています。そして現在、AIは脆弱性の発見に極めて優れています。これが、CVEの大量発生を引き起こしています。
Spring HeroDevsでは、この傾向を如実に示す事例をいくつか確認しています。例えば、Spring フレームワークの場合、2025年には17件のCVEが公表されました。2026年については、このウェビナー開催日時点で、すでに200件以上が公表されています。
この影響は企業にとどまらず、報告されるセキュリティ問題を審査しなければならないコミュニティやプロジェクトにも及んでいます。現在、これらの組織は週に数千件ものリクエストに直面しており、脆弱性が悪用される前に発見・修正を行うために、それらを審査しなければなりません。Anthropic社の「Glasswing」イニシアチブのようなプロジェクトにより、CVEの特定件数は急速に増加しており、悪意のあるコードを含むオープンソースパッケージの数も増加の一途をたどっています。
「オープンソースの利用規模の拡大」と「脆弱性の発見の加速」というこの2つの要素が、企業に最も大きな影響を与えています。というのも、組織でははるかに大量のオープンソースを利用しており、その製品ライフサイクルに追いつくことは極めて困難だからです。そして、一度遅れをとってしまうと、コミュニティがパッチやCVEの修正を提供しなくなるため、企業はアップストリームのパッチやCVEの修正に頼ることができなくなってしまいます。
規制の推進要因となった情報漏洩の年表
個人データ規制の歴史について少し触れたいと思いますが、皆さんの多くにはその経験からトラウマを抱えている方もいらっしゃるかもしれませんので、あまり深くは掘り下げません。これまでのコンプライアンス基準を時系列でたどってみると、それらはいくつかの大きな出来事をきっかけとして生まれたものです。私にとって、こうした規制の歴史を理解することは、2つの点で役立ちます。第一に、問題の起源が分かれば、物事への取り組み方がより容易になるからです。第二に、将来どのようなことが求められるようになるのかを理解するのに役立つからです。
スノーデンの内部告発やトークトークの個人情報漏洩事件を見れば、GDPRの導入と施行が、いくつかの極めて大規模な個人情報漏洩や情報開示の直後に続いたことがわかるでしょう。
EUのCRAについても、同様の傾向が見られます。2017年に発生したエクイファックスの情報漏洩事件を例に挙げましょう。この事件では、数百万人の個人データが流出し、エクイファックスはFTCから5億ドル以上の罰金を科されました。また、後ほど詳しく触れる「Log4Shell」事件も挙げられます。これらには共通の経緯が見られます。すなわち、重大なセキュリティ侵害が発生した後、規制基準が引き上げられるという流れです。
ここで留意すべき重要な点は、個人データの観点であれ、比較的新しいインフラセキュリティの観点であれ、GDPR第32条の下であれ、EU CRA第13条(8)の下であれ、サポート終了したオープンソースソフトウェアの使用は、いずれの観点にも直接的な影響を及ぼすということです。
これはヨーロッパだけの話ではなく、世界的な傾向です。カナダには法案C-26があります。米国では、最近公布された数多くの大統領令に加え、FedRAMP、CMMC 2.0、PCI要件があり、さらにHIPAAの改正案やセキュリティ体制の抜本的な見直しも進められています。世界中で同様の要件が強化されており、アジア太平洋地域（APAC）でも、オーストラリアでは「サイバーセキュリティ法」やCPS-Aが制定されています。
これらの要件は、対象となる企業だけでなく、それらにソフトウェアやサービスを提供する企業にも影響を及ぼします。大まかに言えば、これらのコンプライアンス基準には、以下の共通する中核要素が求められています：
- 自分が何を動かしていて、何を使っているのかを把握しておきましょう。
- 脆弱性を修正するためのプロセスと能力を備えていること。
- 個人情報や一般情報に影響を及ぼす可能性のある重大なインシデントを報告するための手順と体制を整えておくこと。
- 監督機関に対して提示できる、監査対応済みの文書を用意しておくこと。
EUサイバーレジリエンス法（CRA）のご紹介
歴史について概説したところで、次はEUのCRAについて具体的に見ていきましょう。その一部はすでに施行されており、広範な影響を及ぼすことになるでしょう。
まず、EU CRAとは何かを明確にしておきましょう。これは、初の「横断的」サイバーセキュリティ法です。「横断的」とは、特定のセクターだけでなく、あらゆる製品カテゴリーに適用される初の法律であることを意味します。 比較として、2025年1月に施行された「デジタル・オペレーショナル・レジリエンス法（DORA）」をご存知の方も多いかもしれませんが、これは金融事業者およびそれらに特定のサービスを提供する組織にのみ適用されるため、セクター別、あるいは垂直的な規制となります。
EU CRAは欧州委員会によって提案され、欧州議会およびEU理事会によって採択されました。正式名称は「規則（EU）CRA」ですが、実際にこの名称を使う人はいないでしょうが、念のためご参考まで。その主な目的は、デジタル要素を含むあらゆる製品に対して、ライフサイクルに関する義務を課すことにあります。
EUのCRAを支える4つの柱
ライフサイクルに関する必須の義務は、主に以下の4つの要素に基づいて構成されています：
- 「設計段階からのセキュリティ確保」。デジタル要素を含むソフトウェア製品を提供または使用する企業は、サイバーセキュリティ機能をソフトウェアに直接組み込む必要があります。後付けの追加機能としてではなく、最初から組み込むことが不可欠です。これらの機能は、サポート期間全体を通じて維持されなければなりません。
- 脆弱性の対応。これは、セキュリティ上の欠陥を特定、記録、修正し、必要に応じて報告するという継続的な義務です。これには、タイムリーかつ安全に配布されるパッチに加え、セキュリティ研究者や顧客が問題を報告できる「協調的脆弱性開示（CVD）」ポリシーが含まれます。
- インシデント報告。脆弱性が発見された場合、期限に沿った通知を行うための明確な文書および手順が整備されていなければならない。
- SBOMの要件。ソフトウェア・ビル・オブ・マテリアル（SBOM）とは、デジタル製品に含まれるすべてのソフトウェアコンポーネント、ライブラリ、および依存関係を機械可読形式で一覧化したものです。
これらは、EUのCRAにおける4つの必須要素です。
「デジタル要素」とは具体的に何を指すのでしょうか？
EUのCRAは、引用すると「デジタル要素」を含む製品に適用されます。この定義は、その言葉が示す通り非常に広範なものです。デジタル要素には、オペレーティングシステム、デスクトップおよびモバイルアプリ、ファームウェア、ライブラリなどが含まれます。これには組み込み型のオープンソースも含まれます。基本的に、デバイスをネットワークに接続するもの、あるいはネットワークと連携するものはすべて対象となります。
他の規制要件の対象となる例外がいくつかあります。例えば、純粋なSaaSはNIS2の対象となり、自動車、航空、医療などの特定のセクターは、それぞれ独自の基準の対象となります。とはいえ、「デジタル要素」の定義は、意図的に非常に広範に定められています。
ここで明確にしておくべき例外の一つが、非営利のオープンソースです。非営利のオープンソースとは、商業モデルや収益化の道筋を持たず、完全に無料で構築・提供されるソフトウェアを指します。つまり、配布によって利益を得る意図がないものです。現実的には、この例外はアップストリームのプロジェクトやコミュニティに適用されます。明確にしておきますが、オープンソースソフトウェア（非営利のオープンソースを含む）を自社製品にバンドルするメーカーは、すべてEU CRAの適用対象となります。
また、GDPRと同様に、EUのCRAにも域外適用が認められています。EU域内に拠点を置いていない場合でも、EU域内に製品を販売しているなら、設立地や事業拠点の場所にかかわらず、この規制の対象となります。
Log4Shellの背景
注目すべきは、欧州委員会がEUのCRA（サイバーセキュリティ法）に関して提出した提案において、Log4Shellの脆弱性が具体的に言及されていた点である。Apache Log4jとして知られる小さなJavaライブラリが、数百万ものアプリケーションに組み込まれていた。あるセキュリティ上の欠陥により、一夜にしてインターネットの大部分が危険にさらされた。このCVE（共通脆弱性指数）により、攻撃者はインターネット上のどこからでも、標的となったコンピュータやサーバー上で悪意のあるコードを実行することが可能となった。これを悪用すれば、システムを完全に制御したり、データを盗み出したり、ランサムウェアをインストールしたり、あるいは大規模なネットワーク攻撃を仕掛けたりすることが可能になる。
これにより、欧州委員会が解決を目指していた厳しい現実が浮き彫りになった。すなわち、これらすべての導入環境におけるLog4jのセキュリティについて、誰も責任を負っていなかったのだ。EUのCRAは、その責任を、当該製品を市場に投入した者に帰属させている。
EUの主要なCRAに関する期限および条項
ここで、簡単な年表を振り返りながら、EUのCRAの主な要素についてさらに詳しく見ていきましょう。
- EUのCRAは、2022年に欧州委員会によって提案された。
- 2024年12月に発効し、その頃から人々の関心が高まり始めた。
- 2026年9月11日— 脆弱性の報告義務が適用されるようになりました。（このウェビナー開催時点では、これは先週のことです。）
- 2027年12月11日— 要件のすべてが施行される。
つまり、本日をもって、事実上、報告のカウントダウンが始まったことになります。自社製品の脆弱性が実際に悪用されている場合は、EUサイバーセキュリティ庁（ENISA）が運営する「単一報告プラットフォーム（SRP）」を通じて、その脆弱性を報告しなければなりません。報告された内容は、各国のコンピュータセキュリティインシデント対応チーム（CSIRT）によって受け付けられ、審査されます。 EUのCRA（サイバーセキュリティ規制）の世界に足を踏み入れたいなら、頭字語を愛さなければなりません。それは必須条件なのです。
時計は容赦ない：
- 24時間— 早期通報の要件
- 72時間— 完全な通知
- 14日間— 修正プログラムが公開された後の最終報告書
重要な点として、9月より前に製品を出荷し、それがすでに市場に出回っている場合でも、現在もこれらの義務を負うことになります。EUのCRA（コンプライアンス・リスク・アセスメント）における適用範囲の広範な定義は、特定のセクターや主にEU内で事業を展開する組織に限定されたものではありません。EUで事業を行っている場合、この規制が貴社に影響を及ぼす可能性は非常に高いでしょう。
今、最も重要な3つの要件
第13条(8) — サポート期間。デジタル要素を含む製品を提供する製造業者は、少なくとも5年間のサポート期間を明示しなければならない。この5年間、製造業者は、組み込みオープンソースを含むすべてのコンポーネントにおける脆弱性に対処しなければならない。 また、更新プログラムは10年間利用可能でなければならない。これは、製造業者がライセンス条項を理由に、事後的に修正プログラムの提供を取り下げることを防ぐためである。規制当局は、当該ソフトウェアに依存しているユーザーに移行する時間を確保したいと考えており、そのため製造業者は修正プログラムを公開した後、直ちにその提供を中止することはできない。
第14条 — 脆弱性の報告。これには、前述の24時間／72時間／14日間の報告期限が含まれます。企業が今すぐ講じるべき主な措置：
- デジタル要素を含む製品を提供する場合は、担当者を指定してください。これは、脆弱性が発見された際にENISA SRPにログインする役割を担う人物です。
- その担当者に、あらかじめEUログイン（欧州委員会へのアカウント）を作成してもらってください。ただし、欧州委員会は、SRP自体に直接事前登録することを特に推奨していない点にご注意ください。
- SRPレポート作成時に、誰が何を担当するかを明確にした社内プロセスを確立する。
付属書I — 12月から適用されるSBOM要件。主な要素は4つ：
- ソフトウェア製品の各バージョンごとに、機械可読形式のSBOMを生成し、技術文書の一部として含めることで、規制当局（監視機関）がこれを確認できるようにする。
- SBOMは継続的に更新してください。12か月前の古いスナップショットではいけません。現在のコンポーネント、パッチ、および更新内容を反映したものである必要があります。
- 脆弱性対応の統合— SBOMは、コンプライアンスの遵守と迅速なレポート作成を支援するため、継続的な脆弱性照合および追跡ツールと連携すべきである。
罰則
目標は、すべての組織がこれらの要件を満たし、コンプライアンスを維持することですが、EUのCRAには実効性のある制裁措置が盛り込まれています。罰金は数千万ユーロ、あるいは全世界の年間売上高の一定割合のいずれか高い方の金額に達する可能性があります。重大な違反があった場合、製品がEU市場から完全に撤去される可能性があり、それは深刻な結果を招く恐れがあります。
今、何をすべきか
- EUのCRA（デジタルサービス法）の適用範囲を把握しましょう。定義をよくお読みください。EU域内にデジタル要素を提供している場合は、この法律の影響を受けます。
- 担当の担当者を確認してください。
- 機械可読形式のSBOMの作成を支援できるベンダーの評価を開始してください。
- DevSecOpsプラットフォームを導入し、リスクをリアルタイムで監視できるようにします。
- 担当の担当者と共に、24時間・72時間・14日ごとの報告ワークフローを練習してください。
- 証拠を保管しておくこと――監査証跡、DevSecOpsの記録、およびSBOMは不可欠となるでしょう。
2027年12月はまだ先のように思えるかもしれませんが、あっという間にやってきます。そして、サポート終了となったオープンソースソフトウェアに依存している組織にとっては、その影響が最も深刻なものとなるでしょう。
「ライフサイクル終了時のオープンソース」が実際に意味すること
CRAの沿革や背景、そしてその要件についてはすでに説明しました。それでは、今日の組織にとってリスクが最も顕著な点に焦点を当ててみましょう。
「ライフサイクル終了のオープンソースソフトウェア」には、いくつかの意味があります：
- コミュニティから完全に見捨てられています。例：AngularJS 。Googleはもはやそのメンテナンスを行う意思がないため、ユーザーはReactや最新のAngular へ移行せざるを得ませんでした。もしまだAngularJS に依存している場合、コミュニティによるセキュリティ問題の検証やCVE修正の提供は行われていません。
- プロジェクト自体が活発に活動していても、コミュニティによるサポートが終了したバージョン。例：エンタープライズレベルのJavaアプリケーションの構築に使用されるSpring フレームワーク。このコミュニティにはリリースサイクルがあり、レガシーバージョンにはCVEの修正が提供されなくなります。したがって、Spring Boot 2.5を使用している場合、そのバージョンはサポート終了（EOL）となっており、AIの影響でセキュリティ問題が指数関数的に増加しているにもかかわらず、コミュニティはそのバージョンに対する修正を提供しません。
組織は、重大または高リスクと分類された既知のCVEが存在する、サポート対象外のソフトウェアに依存していないと安易に思いがちですが、実際のところ：
- エンタープライズコンポーネントのうち、5％から15％はすでにサポート終了となっています。
- 81,000件以上のパッケージには、コミュニティの関心が他に移ってしまったため、既知のCVEが存在するものの、修正策は知られていない。
- このリスクは、誰もが真っ先に思い浮かべる主要な依存関係やフレームワークに限ったことではありません。実際、こうしたCVEの93％は、多くの組織が明示的に選択したことのない推移的依存関係に含まれています。それらは、単にデプロイされたソリューションに最初から含まれているものなのです。
この問題は収まる気配がありません。4月から7月の間だけでも、MySQL、Node.js、Django 、Angular 、Spring Bootといったツールで、サポート終了という重大な出来事が相次ぎました。これらはすべて90日以内に発生したものです。これらのツールを利用していた組織は、近代化を進め、サポート対象のバージョンを維持するために全力を挙げて対応に追われ、その過程で他のプロジェクトや価値創造につながる業務が犠牲になることも少なくありませんでした。
コンプライアンス・リスクの実際の事例
これは単なる仮定上の問題ではありません。現在、EUのCRAに直接関連する2つの事例があります：
- Spring このセキュリティには、HTTPセキュリティヘッダーの適用を密かに妨げる重大なCVEが存在します。アプリケーションは引き続き動作し、すべてのステータスチェックを通過しますが、極めて重要なブラウザ側の保護機能が、エラーや警告を一切記録することなく完全に無効化されてしまいます。
- Angular 深刻度の高いCVEが存在していました。これは、Angular アプリケーション内の翻訳済みテキストファイルに悪意のあるコードを隠蔽することで、攻撃者がユーザーのウェブページ上で有害なJavaScriptを実行できるクロスサイトスクリプティングの脆弱性でした。
いずれの場合も、EUのCRA（あるいはDORA）の下では、組織は2つの点でコンプライアンス違反のリスクに直面することになります。第一に、デジタル要素を含む製品においてサポート対象外のソフトウェアバージョンを実行したことにより、第13条(8)に基づく違反となること。第二に、組織が第14条で定められた報告期限内に報告を行わなかった場合です。
サポート終了後のオープンソースの利用は広く見受けられ、その利用により、EUのCRA、GDPR、およびその他の基準への準拠が損なわれる可能性があります。
今後の2つの道
では、どうすればよいのでしょうか？ 選択肢は2つあります。
選択肢 1：サポート対象のバージョンへ移行する。これは直感的に思えるかもしれませんが、ここにいる多くの技術者が証言するように、移行は極めて困難になる可能性があります。特に、エコシステム内の依存関係を横断する場合などはなおさらです。 例えば、Spring への移行には、Java 8からの移行も必要となる可能性があり、その結果、移行スケジュールが12ヶ月以上先延ばしになる恐れがあります。その間、新たな機能をほとんど得られないまま、近代化のためにリソースを費やすことになり、さらに悪いことに、その間もコンプライアンス違反の状態が続いてしまいます。この道を選ぶ場合、企業は導入するオープンソースについて極めて慎重に検討し、サポート終了の時期を常に注視し続ける必要がありますが、導入事例の膨大な数を考えると、これは非常に困難な作業です。
選択肢 2：サポート終了となったソフトウェアに対応できるベンダーを見つける。ここで HeroDevs の出番です。当社は、サポート終了となったオープンソースソフトウェアの「ドロップイン置換」ソリューションを提供しています。当社のサブスクリプションサービスの一環として、契約期間を通じて CVE への対応とサポートを受けられるため、企業はコンプライアンスを維持しつつ、自社のペースでモダナイゼーションを進めることが可能になります。
汚染対策市場の活況――そしてベンダーの選定方法
AIをめぐる議論やCVEの増加に伴い、私が親しみを込めて「是正措置市場のブーム」と呼んでいる現象が起きています。SCAツールや類似のソリューションは、サポート終了したオープンソースソフトウェア内のCVEを特定する能力を高めてきました。しかし、今こそ問われるべきは、CVEが特定された後、どう対処すべきかということです。
2025年には48,000件のCVEが公開され（前年比250％以上増）、ベンダー各社は、コミュニティによるサポートが終了したバージョンを含め、オープンソースソフトウェアの脆弱性を修正できると主張し、積極的に動き出しています。 私自身、AIだけでそれが可能だと主張する組織を目にしてきました。しかし、1Passwordによるものを含む最近の調査によると、AIのみで作成されたパッチのうち、実際に根本的なバグやCVEを修正できたのは4つに1つに過ぎないことが判明しました。
当社側では、HeroDevsが調査を行ったところ、Spring のCVE修正を謳っている有力なベンダーが見つかりました。そのドキュメントを確認したところ、このベンダーが修正したと主張する258件のSpring のCVEのうち、3分の2近くについて、その主張を裏付ける有効な修正策が存在しないことが判明しました。
こうした事情を踏まえ、ベンダーを評価する方は、どのベンダー（当社を含め）の言葉も鵜呑みにするのではなく、確かな証拠を入手することを強くお勧めします。具体的には：
- 特定のCVEと特定のリリースを関連付けたリリースノートを請求してください。
- 修正済みのCVEを強調表示したVEXステートメントを要求してください。
- ベンダーの専門知識のレベルを確認してください。AIだけでは万能の解決策にはなりません。上流のパッチに依存するだけでなく、実際に自らCVEを発見した実績があり、CNA（認定セキュリティアナリスト）の資格を持つベンダーを探しましょう。
- 概念実証（PoC）スキャンを実行してください。修正によってアプリケーションに不具合が生じないことを確認するとともに、重要な点として、根本的なCVEが依然として存在しているにもかかわらず、単にバージョンを上げることによって検出結果が消えるだけになっていないかを確認してください。
適切なサポートが得られないことは、単に貴社にとってのリスクであるだけでなく、これらの規制を遵守する能力に対するリスクでもあり、ひいては顧客にとってもリスクとなります。
まとめ
歴史は繰り返すものであり、こうした傾向は以前にも見られました。EU CRAは、この種の要件の最後のものではありません。EU CRAへの準拠のために構築した取り組みを活かし、今後の動きに備えてください。オープンソースの採用は爆発的に増加しており、AIによって脆弱性の発見がより容易かつ迅速になっています。だからこそ、サポート終了となったオープンソースソフトウェアへの対応策と、EU CRAの要件を満たすための計画を立てておくことが極めて重要です。
EUのCRA規制はすでに始まっています――これは「12月に一斉に導入される」ようなものではありません。実際の要件はすでに施行されています。つまり：
- 割り当てられた担当者を特定してください。
- EUログインの設定を行ってください。
- 期限内に報告できるよう、SBOMが利用可能な状態であることを確認し、脆弱性のスキャンを行ってください。
- サポート終了となるオープンソースソフトウェアは、対処すべき直接的なコンプライアンス上の課題であることを認識し、その解決を支援できる専門知識と経験を持つベンダーを選択してください。
Q&A
エリン・ハンナフォード：ロブ、どうもありがとう。いくつか質問が寄せられているので、一番上の質問から始めましょう。
参加者からの質問：機械可読なSBOMについて少し触れられていましたが、リポジトリの依存関係マニフェストにはない、機械可読なSBOMならではの利点について、詳しく説明していただけますか？
ロブ・ナレン：良い質問ですね。package.json や pom.xml には、開発者が直接追加することを選択した内容が表示されています。 しかし――ここでEU CRAの附属書Iの義務が関係してくるのですが――それだけでは依存関係の完全なリストが把握できず、審査員が確認を求めている監査証跡も提供されません。その監査証跡には、チーム内の誰も明示的に選択しなかった可能性が高い推移的コンポーネントを含める必要があります。これが、先ほど私が言及した93％という数字が関係してくる点です。
だからこそ、SBOMは重要なのです。CycloneDXやSPDXのようなフォーマットは、機械で解析できるよう設計されており、リリースごとの差異を比較することができます。そのため、Log4Shellのような新たな脆弱性が発見された際、自社が影響を受けているかどうかを、はるかに迅速に判断できるようになります。理想を言えば、狭い視野ではなく、全体像を把握できるのです。
エリン・ハンナフォード：ありがとうございます。ラルフさんから、ベンダーの修正が単に問題を隠蔽しているのではなく、実際に解決しているかどうかをどのように確認できるかという質問があります。彼は、問題がスキャナーの検知範囲外に移されただけで、解決済みとして処理されたチケットを数多く目にしてきたそうです。
ロブ・ナレン：良い質問ですね。先ほど挙げた4つの質問に立ち返ってみたいと思います。まず、契約を結ぶ前に、ベンダーと協力して、彼らが実際に何を提供してくれるのかを見極めることです。これは、単一のフレームワークや、場合によっては単一の修正事項を検証する、単純な概念実証（PoC）でも構いません。
リリースノートを確認してください。そこには、特定のCVEと特定のリリースが紐付けられているはずです。「はい、対応しています」とだけ書かれたマーケティングページだけを鵜呑みにしてはいけません。次に、おそらく最も重要なのがVEXステートメントです。これらは機械可読形式であり、SCAやDevSecOpsプラットフォームにアップロードして、自社の脆弱性追跡システムと一致しているかどうかを確認することができます。
さらに、ベンダー自体についても詳しく調べてみてください。そのベンダーはMITREに登録されたCNA（認定セキュリティ評価機関）なのでしょうか？HeroDevsが修正を行うCVEについては、当社が当該CVEを発見し、修正を行った組織として明確に特定されています。つまり、単に上流からのパッチの提供を待つのではなく、自ら積極的にこれらの問題を探し出しているのです。
最後に、概念実証（PoC）を行う際は、実際のコードを実行し、単なるバージョンアップに過ぎないものではないことを確認してください。これもまた、VEXステートメントや、CVEが真に修正されているかどうかという点に結びつきます。こうした手順を踏むことで、ベンダーが必要な専門知識を持っているかどうかを見極めるのに役立ちます。
エリン・ハンナフォード：いいですね。さて、最後の質問を1つ受け付ける時間があると思います。リチャードさんからの質問です。「レガシーフレームワークからの移行に向けた複数年計画がすでに策定されている場合、CRAの適用対象外となるのでしょうか？」
ロブ・ナレン：良い質問ですね。残念ながら、答えは「いいえ」です。他の規制では、リスクを限定するために「開発中」である旨を例外として申請できる場合があります。しかし、EUのCRAの下では、それだけでは組織の遵守義務が免除されることはありません。 第14条の報告義務は2026年9月11日から施行されており、市場に出回っているすべての製品に適用されます。したがって、近代化の取り組みが進行中であるという事実だけでは不十分です。
私がお勧めしたいのは、各組織が今すぐSCAスキャナーを活用し、サポート終了（EOL）となったオープンソースソフトウェアがどこにあるかを特定し、可能な限り速やかに最新バージョンへ移行すること、そしてそれが不可能な場合は、HeroDevsのようなベンダーと連携して必要なサポートを得て、今日からコンプライアンスを確保することです。
エリン・ハンナフォード：ロブ、ありがとうございました。また、ご参加いただいた皆様、ありがとうございました。これで本日のウェビナーは終了となります。ウェビナーの録画と付随するホワイトペーパーをぜひご期待ください。ありがとうございました。
