EUサイバーレジリエンス法(CRA)の「脆弱性処理要件」はどこまで自動化できるか？

3行でわかる本記事のサマリ

• インターネットの普及に伴うサイバー攻撃の増加に対し、"EUサイバーレジリエンス法"が2024年に施行。36ヶ月の猶予期間後、2027年に正式運用へ。
• 法令適合には製品の分類、セキュリティアセスメント、脆弱性処理要件への準拠が必要。SBOMの生成や管理が重要な役割を果たす。
• 脆弱性処理要件には脆弱性開示ポリシーの策定、SBOMを活用した悪用可能な脆弱性の自動抽出が含まれる。CVSSからSSVCへの移行も注目。

はじめに

昨今、私達の生活にインターネットは欠かせないものとなり、PCや携帯デバイスだけでなく、車や家電機器、工業機器など、様々なものが当たり前のようにインターネットに繋がり、利便性が飛躍的に向上していることは、皆様ご存知のとおりです。一方でインターネット上ではサイバー攻撃が頻繁に発生し、その対策費用は年間数百兆円にものぼると言われます。

こういった攻撃の2/3はソフトウェアに混入した脆弱性に起因すると言われますが、これらの脆弱性に対するメーカーの修正やサポートは、必ずしもその製品のライフサイクルを通して提供され続けるものではありません。
実際に幼児向けの玩具を含め、一般家庭に存在するインターネット接続機能を有する機器の多くに次々と深刻な脆弱性が見つかる状況の中、それらの製品が継続的に対処や改善のサポートを適用できている状態ではないことも事実です。

こういった機器へのサイバー攻撃に対してレジリエンス(回復力)とコンプラアント(準拠)をEU圏内の人々に提供することを目的として、EUサイバーレジリエンス法(Cyber Resilience Act：CRA)が施行されます。
本法案は2024年上期に施行され、36ヶ月の猶予期間を経て2027年中には正式な運用が開始されると見られます。

目次

1.EUサイバーレジリエンス法準拠に向けた基本的な流れ
2.脆弱性処理要件
3.SBOM生成でのさまざまな検討事項
4.脆弱性開示ポリシーの策定
5.SBOMを起点とした脆弱性処理の流れ
6.悪用可能な脆弱性の抽出にCVSSを利用する課題
7.SBOMから悪用可能な脆弱性を抽出するCIツールパイプラインを構成する際のポイント
8.まとめ

１．EUサイバーレジリエンス法準拠に向けた基本的な流れ

まず、自社の製品がEUサイバーレジリエンス法の対象になるかの棚卸しをする必要があります。対象となるのはEU域内で販売・消費されるすべての「デジタル製品」です。製品の棚卸し後、規定に基づいて対象となる製品を「重要なデジタル製品(さらに低リスクのクラス1/高リスクのクラス2に分類)」とそれ以外に分類します。その後、規定に基づきセキュリティアセスメントを実施し、セキュリティ要件、脆弱性処理要件を満たすかの確認を行い、自己または第三者機関の評価に基づいて適合宣言を行います。

図1: CRA準拠に向けた基本的な流れ

２．脆弱性処理要件

EUサイバーレジリエンス法の適合宣言を行うためには「セキュリティ要件」と「脆弱性処理要件」に準拠している必要があります。今回は「脆弱性処理要件」への準拠部分を少し掘り下げて行きたいと思います。
脆弱性処理要件とは、具体的には以下のように定義されています。

図2: 経済産業省ウェブサイト
（https://www.meti.go.jp/policy/netsecurity/netsecurity/CRAdraft.pdf）

図2を見ると、(5)の脆弱性開示ポリシーの策定があり、(6)〜(8)には修正をどのように製品やユーザーまで配布するかの仕組み作りが含まれますが、それ以外の脆弱性の検知と修正判断までの作業は殆ど(1)で言及されているSBOMを起点にした自動化を検討することも可能です。

３．SBOM生成でのさまざまな検討事項

SBOMの正確性

最初に課題になるのが、SBOMをどこまで正確に作るべきか、という点です。言うまでもなく、SBOMが100%正確な状態に越したことはないのですが、それを保証してくれるSBOMジェネレーターは私達の知る限り存在しません。図2の1)に記載の通り「少なくとも最上位レベルの依存関係を含む」状態で、まずは着手することが重要です。
例えばGitHubを用いてコードからSBOMを生成する場合、対応言語であればpackages.jsonやpom.xmlといった定義ファイルをもとに、最上位レベルの依存関係が出力可能です。アプリケーションのビルドの際に生成されるLockファイルもあわせてリポジトリに保存すれば、多くの場合は推移依存関係(最上位の依存関係の導入に連鎖して導入される依存関係)を含むSBOMにすることが可能です。
また、ビルドの過程でソースコードに無いコンポーネントを追加するようなことがあり得る場合は、バイナリをスキャンしてSBOMを出力するようなスキャナーを導入いただく方法もあります。

SBOMのフォーマット

SBOMにはいくつかのフォーマットがありますが、自社でどのフォーマットを採用すべきかといった検討もあるかと思います。しかしながら今後もSBOMフォーマットが統一されることは考えにくく、複数のフォーマットが存在する状況は将来的にも変わらないと推測しています。
現時点では特に普及が進んでいるSPDXまたはCycloneDXのいずれかで生成し管理することが望ましいです。
昨今のSBOMジェネレーターの殆どがSPDXまたはCycloneDXのいずれかをサポートしています。

SBOMの管理

SBOMの生成を運用し始めると、次は管理方法が課題になります。SBOMを管理するうえでは大きく以下のような要件があります。

1) 改ざん防止/来歴記録
2) バージョン管理
3) 検索性
4) 第三者への安全な共有

もし専用のSBOM管理ツールをすでに持っている場合や新たに導入する場合は、原則上記の要件は満たすものがほとんどですので、それを利用するのが最も効率的です。
もし専用ツールをお持ちでない場合はGitHubをはじめとするGitの仕組みを利用することから始めることが可能です。
SBOMはテキストファイルであり、Gitで管理を行うことに適しています。
プルリクエストベースで更新を行うことにより、更新の来歴がすべて記録され、リリースタグなどの機能を併用すると、バージョン別の検索性も高めることが可能です。
第三者への安全な共有については、共有するリポジトリを限定するなど運用での工夫が必要となりますが、これも実現可能です。

４．脆弱性開示ポリシーの策定

EUサイバーレジリエンス法では脆弱性開示ポリシーの作成と運用が求められます。
脆弱性開示ポリシーをホームページなどに掲載している組織や企業も多くあるため、それらを参考に検討が可能です。
脆弱性開示ポリシーで重要なのは、何がどういう状態であれば、いつまでにどうする、といった、しきい値の明確化と対応の明確化です。
例えば製品に脆弱性が見つかった場合、以下のような流れで対応が進みます。

1. 製品への影響度を調査
   (脆弱性が見つかっても、対象の製品では利用しないコンポーネントであったり、利用方法によって脆弱性の条件を満たさない場合もあります)
2. 影響がある(脆弱性が悪用されるリスクがある)と判定した場合、ENISAに報告
3. 情報開示および回避策の提示、または対策が施されたアップデートを配布
   
   こういった対応は製品のライフサイクルを通して、または最低でも5️年間継続することが求められます。

５．SBOMを起点とした脆弱性処理の流れ

SBOMが生成されて管理できている状態であれば、以前のブログ(https://mnb.macnica.co.jp/2023/07/DevSecOps/sbom.html)で紹介した通り、OSVスキャナなどのSBOMから脆弱性を取得するツールや、LeanSeeksという脆弱性トリアージツールを利用して「悪用可能な脆弱性」を抽出することができ、ここまでの処理は自動化することも可能です。

図3: SBOMを起点とした脆弱性処理の流れ

悪用可能な脆弱性が発見され通知されるまでの自動化にあたっては、以前のブログ同様にGitHub ActionsなどのCIツールを利用すると便利です。
ほとんどのCIツールにはcronのように日時を指定して定期実行する機能があり、これを利用することで毎朝最新の脆弱性情報を取得して、その悪用可否を判定することで、調査の範囲を限定することができます。必要に応じてメッセージツールなどにプッシュ通知すれば、いち早く対処を進めることも可能です。

６．悪用可能な脆弱性の抽出にCVSSを利用する課題

悪用可能な脆弱性の抽出にCVSSを利用することに課題があることは以前のブログでも紹介しましたが、CVSSには主な課題として以下があります。

1) 脆弱性のCVSSの半数以上がCriticalとHighのセベリティで、必然的にスキャナで検知される脆弱性もCriticalやHighの比率が多くなる傾向があり、優先度の判断が困難
2) CriticalやHighの脆弱性であっても、実際にはほとんどの脆弱性が悪用されていない
3) 悪用される脆弱性は実績ベースでMediumやLowのセベリティのものが存在する

図4: 2024年4月時点のNVDの脆弱性数量とセベリティの比率

こういった背景から、昨今はCVSSに変わるフレームワークとして、リスクベースで悪用可能な脆弱性を絞り込むSSVCが普及してきています。
SSVCはより高い精度で悪用可能な脆弱性の絞り込みを実現しますが、フレームワークの利用に必要となる「攻撃コードの存在と完成度」といった情報には信頼できるインテリジェンスが必要です。
LeanSeeksはこういったインテリジェンスの提供にあわせてSSVCをベースとした悪用可能な脆弱性の絞り込みを自動化でき、今回紹介した悪用可能な脆弱性抽出の処理の自動化において非常に有効なツールの一つです。

７．SBOMから悪用可能な脆弱性を抽出するCIツールパイプラインを構成する際のポイント

前回のブログではGitHubの機能で対象リポジトリのSBOMを生成し、そこから悪用可能な脆弱性を抽出するまでの流れを紹介しました。
今回はSBOM自体をGitHubで管理されていることを前提とした場合、以下の2点がポイントとなります。

スケジュールジョブの構成

利用するCIツールによって設定は異なりますが、例えばGitHub Actionsを用いてパイプラインを構成する場合、以下に記載の方法で定期的なジョブの実行を自動的に行うことが可能です。
https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#schedule
毎朝9時に実行する場合の例は、以下のような記載になります。

対象となるSBOMの取得

SBOMをGitHubで管理する場合、ファイル名にバージョンを指定する方法でバージョン別の識別を行う方法もありますが、同一のファイル名で管理を行う場合においては、バージョンごとにバージョン名を含むリリースタグを付与する方法があります。
https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository
リリースタグでバージョン管理を行う場合は、ジョブの中で以下のような指定をすることで、必要なバージョンのSBOMを取得することが可能です。

８．まとめ

今回はEUサイバーレジリエンス法(CRA)の脆弱性処理要件にフォーカスして掘り下げました。SBOMの生成や管理は従来実施していなかった組織では新たなタスクになりますが、うまく活用すれば脆弱性の早期検出に役立つ情報源となることを再確認いただけたと思います。
悪用可能な脆弱性の抽出においては、すでに組織内にルールが存在するケースも多いかと思います。指標が明確に定義されている状況であれば、抽出までの処理の自動化もぜひご検討ください。
もし現状の抽出の有効性に課題を感じている(多すぎたり、正確とは考えにくい状態)ようなら、ぜひ上記で紹介したSSVCやLeanSeeksもあわせてご検討いただければと思います。

本ブログで紹介したLeanSeeksに関して、ホワイトペーパーをご用意しております。
詳しく知りたい方は、是非ダウンロードください。