EUのCRAが真に問うべき点：何が出荷されたのか、そしていつそれを知ったのか？

EUの「サイバーレジリエンス法」がまもなくすべてのソフトウェアベンダーに問うことになる質問について、メンテナーの開示用受信箱にはすでにどのような情報が寄せられているのか。

執筆者：シェーン・ウォーデン（ActiveState プリンシパル・アーキテクト） 

昨年、私がレビューに携わっているあるフリーソフトウェアプロジェクトのセキュリティ連絡先宛てに、ある人物から脆弱性報告が寄せられました。その報告は、GPG署名と適切な責任ある開示手順が伴い、当プロジェクトの報告ガイドラインに準拠したもので、閲覧権限を持つべき人々にのみ送られていました。

その報告には、95件の脆弱性が含まれているとされていた。我々はこれを真剣に受け止めた。なぜなら、まさにこうした事態に備えて、そのセキュリティプロセスが存在しているからだ。

しかし、どこか違和感を覚えました。なぜなら、人間のセキュリティ研究者が、3つや4つで止まってさらなる協力を求めるのではなく、95件ものリストを作成し続けるとは考えにくいからです。

95件のうち、実際に有効だったのは2～3件に過ぎませんでした。割合としては低いですが、問題ではありませんでした。なぜなら、有効な2～3件を見つけるために、95件すべてを精査しなければならなかったからです。 その後、2通目のメールが届きました。「10万ドルを支払わなければ、Heartbleed事件のような大々的な報道とともに報告書を公開する」という内容でした。

報告書そのものは誇張されていた。しかし、その背後にある脅威は誇張ではなかった。なぜなら、そのような情報公開による影響範囲は、攻撃者がオープンインターネットをスキャンして、まだそのソフトウェアを実行しているシステムをすべて見つけ出し、攻撃できるすべての導入環境に及ぶからだ。

このような事態を目の当たりにしたのは私だけではありません。そして、オープンソースのメンテナーたちが現在苦闘している問題は、他の企業も間もなく直面することになる問題だと私は考えています。ボランティアによる非公式な現実が、ソフトウェア業界全体の運営上の現実となるのです。

2026年9月11日、私が先ほど説明した状況に類似した事象は、もはやボランティアだけの問題ではなく、非常に多くの企業にとって法的な問題となる。

その日、EUサイバーレジリエンス法の報告義務が発効する。EU域内で販売されているデジタル要素を含む製品を製造するすべてのメーカーは、その製品の脆弱性が実際に悪用されていることを知った場合、24時間以内にENISAに通知し、72時間以内に詳細な報告書を提出しなければならない。

製品の構築および保守方法、すなわち技術要件を実際に義務付ける同法の部分は、2027年12月11日から適用が開始されます。

つまり、法律の他の条項で「適切に製品を構築した」ことを証明することが求められるようになるまでの間、15ヶ月間の「迅速な報告」期間が設けられていることになります。

当社のCEOであるアビー・カーンズは最近、このギャップについて次のように述べています。この移行期間中、CRAは実質的には可視性の要件であり、セキュリティ要件ではないのです。 私も同感です！私はこの部分を身をもって経験してきました。「何がリリースされ、その問題に最初に気づいたのはいつか」という質問は、コンプライアンスチームが9月に初めて答えるような質問ではありません。

開示プロセスを設けているオープンソースのメンテナーなら誰でも、すでにこの質問に答えています。非公式に、プレッシャーの下で、自分たちで何とか組み立てたツールを使って――なぜなら、誰かが私たちのためにそれを構築してくれたわけではないからです。

課題は、実際に何がリリースされたかを把握することだ

私たちは以前にも、このような慌ただしい状況を目の当たりにしてきました。2021年に米国が大統領令14028号を発令し、連邦政府のベンダーに対してソフトウェア部品表（SBOM）の提出を義務付けた際、多くの組織が、他のコンプライアンス関連資料を作成するのと同じ方法でSBOMを作成しました。 期限のプレッシャーの下で一度だけ作成され、作成されたその瞬間には正確であっても、誰かが再度確認を求めた時点ではすでに古くなっているものでした。

昨年3月に生成され、それ以来誰も手を加えていない文書は、今日何が稼働しているかを教えてはくれません。それは、3月に何が稼働していたかを示すに過ぎないのです。EUのCRA（サイバーリスク評価）は、あの大統領令よりもさらに明確です。第13条では、SBOMが最新の状態であることが求められています。

このギャップは、ほとんどのチームが予想しているよりも大きいものです。アプリケーションの98％にオープンソースコンポーネントが含まれている（Black Duck、2026年版「オープンソースセキュリティおよびリスク分析レポート」）ため、EU向けに製品を販売するほぼすべてのメーカーが、ごく一部の例外的なケースではなく、この要件に対応しなければなりません。

メーカーは現在、出荷された内容と、それをいつ把握したかを証明しなければならず、法的期限が刻一刻と迫っています。 修正が適用されるまでの期間に関する業界自身のデータも、決して楽観できるものではありません。アプリケーションの「高」または「重大」な脆弱性を修正するまでの平均所要時間は約55日です（Edgescan、2026年脆弱性統計レポート）。

EUのCRA（サイバーレジリエンス法）の執行は、24時間の早期警告から72時間の完全な通知までの期間と、その是正措置の基準期間との間のギャップにおいて行われることになる（欧州委員会、『サイバーレジリエンス法』第14条の報告義務）。 

組織はこのギャップを2つの方法で埋めています。一部は社内で体制を構築しています。 独自のパイプラインを整備してSBOMを自動的に再生成したり、責任者を明確にした文書化された脆弱性対応プロセスを確立したり、出所情報を監査の圧力の下で作成する報告書ではなく、自らが構築するソフトウェアサプライチェーンの属性として扱ったりしています。

他方、チームが扱うあらゆる言語エコシステムにわたって、使用するすべてのオープンソースコンポーネントの来歴を再導出することは中核的な技術スキルではないと判断し、代わりにすでに審査済みかつ認証済みのコンポーネントを採用することで、コンポーネントがビルドに入る前に来歴に関する疑問が解消されるようにしている組織もあります。

どちらのアプローチも有効ですが、資金の残存期間が14ヶ月目になって初めて、「コンプライアンスは満たせる」という主張の背後にある「実際に質問された際にその質問に答えられる」という裏付けがなかったことに気づくのは、リスクが高いと言えます。

私が話を聞いたエンジニアの多くは、ソフトウェアサプライチェーンに詳細な自己点検機能を追加することではなく、優れたソフトウェアの構築に注力したいと考えています。

そのギャップを埋めるために、ActiveStateは「Curated Catalogs」を構築しました。これは、12の言語エコシステムにわたるオープンソースコンポーネントを、不変のビルド時の来歴情報とともに提供し、契約上のSLAに基づいて修正が施されたものです。アップストリームの修正が存在する場合、重大（Critical）の深刻度については5営業日、高（High）については10営業日、その他については30営業日以内に修正されます。

これは既存のプロセスを補完するものであり、チームが72時間以内に手作業で回答しなければならない質問リストから、「誰が、いつ、これをビルドに組み込んだのか」という項目を排除します。

ENISAが初年度に第14条の条文をどれほど厳格に施行するかはまだ分かりませんし、それを確信を持って語ってくる人に対しては懐疑的です。 ただ、先ほど説明した95項目の報告書は、規制によって問題が強制されるのを待っていなかったことは確かです。それは単に、期限とコストを提示した上で、私が実際に何を稼働させているのか、そしてそれをどれほど迅速に証明できるのかを問うものでした。

EUのCRA（サイバーリスク評価機関）は、EU域内で製品を販売するすべてのメーカーに対し、法的な強制措置が迫る中、大規模に同じ問いを投げかけようとしています。

9月11日を待ってはいけません。チームが6ヶ月前に出荷した製品を1つ選び、その製品に何が含まれているか、そしてその中の最新の重大なCVEについて最初に把握したのはいつか、誰かが答えるまでにどれくらいの時間がかかるかを計ってみてください。もしそれが72時間以上かかるなら、答えはすでに明らかです。

著者

シェーン・ワーデン、ActiveState プリンシパル・アーキテクト

シェーン・ワーデン氏は、ActiveStateのプリンシパル・アーキテクトであり、同社には7年近く在籍しています。1990年代後半からオープンソース活動に携わっており、自身のプロジェクトのセキュリティ情報開示プロセスを直接担当する現役のメンテナーでもあります。

ActiveStateによる提供・執筆。