EUサイバーレジリエンス法(CRA)がまもなくすべてのソフトウェアベンダーに突きつける問いを、メンテナーの脆弱性報告受信箱はすでに知っています。
執筆者: Shane Warden(ActiveState プリンシパルアーキテクト)
昨年、私がレビューに携わっているフリーソフトウェアプロジェクトのセキュリティ窓口に、ある脆弱性報告が届きました。報告は私たちのガイドラインに従っており、GPG署名も付され、然るべき責任ある開示の作法にのっとって、本来見るべき人だけに宛てられていました。
報告書には、95件の脆弱性が記載されているとのことでした。私たちはこれを真剣に受け止めました。そのためにこそ、このセキュリティプロセスが存在するのですから。
ただ、どこか違和感がありました。95件ものリストを作り上げる人間のセキュリティ研究者が、いったいどれだけいるでしょうか。普通なら3件か4件で切り上げ、より長期の関与を求めてくるはずです。
結局、95件のうち実際に有効だったのは2、3件でした。割合としては低いものですが、それは問題ではありません。私たちはその2、3件を見つけ出すために、95件すべてに目を通さざるを得なかったのです。そして次に届いたのが2通目のメールでした。10万ドルを支払わなければ、この報告をHeartbleed並みの報道を伴って公表する、という内容です。
報告書の中身自体は水増しされたものでした。しかし、その背後にある脅威は決して誇張ではありません。こうした開示がもたらす被害範囲は、攻撃者がオープンなインターネットをスキャンして見つけ出せる、その脆弱なソフトウェアを稼働させているすべての環境に及ぶからです。
こうした経験をしたのは私だけではないはずです。そして、今オープンソースのメンテナーたちが直面している問題は、遠からず他の企業も直面することになる問題だと私は考えています。ボランティアたちが非公式に対処してきた現実が、やがてソフトウェア業界全体の運用上の現実になっていくのです。
2026年9月11日、私がここまで述べてきた話に近いことが、ボランティアだけの問題ではなくなり、非常に多くの企業にとって法的な問題へと変わります。
この日、EUサイバーレジリエンス法(CRA)の報告義務が発効します。デジタル要素を含む製品をEU域内で販売するメーカーは、その製品の脆弱性が積極的に悪用されていると知った時点から24時間以内にENISAへ通知し、72時間以内により詳細な報告を行わなければなりません。
製品の構築・保守方法そのものを義務付ける、いわゆる技術的要件に関する部分の適用開始は2027年12月11日です。
つまり私たちには、「まず素早く報告せよ」という段階が15か月間続いた後、法の残りの部分によって「正しく構築したことを証明せよ」と求められることになります。
当社CEOのAbby Kearnsは、最近この空白期間について論じています。この移行期間の間、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条の報告義務)。
組織がこのギャップを埋める方法は大きく二つあります。一つは、社内でその力を養う方法です。自社のパイプラインに計装を組み込んでSBOMを自動的に再生成し、担当責任者を明確にした脆弱性対応プロセスを整備し、来歴(プロバナンス)を監査圧力の下で取りまとめる報告書としてではなく、自ら構築するソフトウェアサプライチェーンの一属性として扱うというやり方です。
もう一つは、チームが関わるあらゆる言語エコシステムにわたって、消費するすべてのオープンソースコンポーネントについて来歴を一から導き出すことは、自分たちの中核的な技術スキルではないと判断し、代わりにすでに審査・証明済みのコンポーネントを利用することで、コンポーネントがビルドに組み込まれる前の段階で来歴の問いにあらかじめ答えておくというやり方です。
どちらのアプローチも有効ではありますが、猶予期間の14か月目になって「対応できているつもりだった」ことが「実際に問われたときに答えられる」ことの裏付けになっていなかったと判明するのはリスクが大きすぎます。
私が話をするエンジニアの多くは、ソフトウェアサプライチェーンへの深い内省を加えることよりも、優れたソフトウェアを作ることに集中したいと考えています。
私たちがこのギャップを埋めるために構築したのがActiveStateのCurated Catalogsです。12の言語エコシステムにまたがるオープンソースコンポーネントを、不変のビルド時来歴付きで提供し、契約上のSLAに基づいて修復します。上流での修正が存在する場合、重大(クリティカル)な深刻度なら5営業日、高(ハイ)なら10営業日、それ以外は30営業日で対応します。
これは既存のプロセスを補完するものであり、「これを誰がいつビルドに組み込んだのか」という問いを、72時間の時計の下でチームが手作業で答えなければならない項目のリストから取り除いてくれます。
ENISAが第14条の条文をその施行初年度にどれほど厳格に運用するのか、私にはまだわかりません。それを自信を持って知っていると言う人がいれば、私はむしろ疑ってかかります。ただ確かなのは、先ほど述べた95件の報告書は、規制がこの問いを突きつけるのを待ってはいなかったということです。それは締め切りと値札を突きつけながら、私に問いかけてきました。自分が実際に何を稼働させているか、そしてそれをどれだけ早く証明できるか、本当にわかっているのか、と。
EU CRAはまもなく、EU域内で販売するすべてのメーカーに同じ問いを、大規模に、しかも法的な執行に向けたカウントダウンとともに突きつけようとしています。
9月11日を待つ必要はありません。自分のチームが6か月前に出荷した製品を一つ選び、その中に何が含まれているか、そしてその中にある直近の重大なCVEにいつ気づいたかを、誰かが答えるまでにどれだけ時間がかかるか計ってみてください。それに72時間以上かかるようなら、答えはもう出ています。
著者について
Shane Warden(ActiveState プリンシパルアーキテクト)
Shane Wardenは、ActiveStateでプリンシパルアーキテクトを務めて約7年になります。1990年代後半からオープンソース活動に携わっており、自身が手がけるプロジェクトのセキュリティ開示プロセスに直接責任を持つ、現役のメンテナーでもあります。
