EUサイバーレジリエンス法を満たすSBOM依存関係の記述方法の考察

Compact

true

担当領域：脆弱性管理／専門分野：脆弱性管理

サイバーセキュリティの脆弱性管理領域の業務に従事。脆弱性概況の把握や脆弱性注意喚起に携わり、近年ではSBOM関連法令やSBOMを活用した脆弱性管理に興味を抱いています。CEH保持。

columns

span-col-12

tablet-columns

tablet-span-col-8

bottomMargin

Spacing07

EUのサイバーレジリエンス法 (Cyber Resilience Act、以降CRA)[1]が2024年12月に発効されました。また2027年12月にはCRAが完全施行されるとのことで、執筆時点ではCRAが完全施行されるまで2年を切りました。昨今話題に上がっていますSBOM(Software Bill Of Materials)の作成もCRAの要件に含まれています。CRAに適合できない場合、企業は欧州で事業ができなくなる恐れがあります。
そのようなリスクを回避しようにも、CRAに準拠したSBOMの作成方法が確立されていないという問題があるため、例を挙げて考察しましたので紹介します。

法令で要求されるSBOMの依存関係

#h-c6c8c50c

要件を満たすSBOMの作成

#h-9779e7

CycloneDXで依存関係を記述してみる

#h-76079f55

依存関係において記述が難しいケース

#h-91291171

まとめ

#h-df294b9e

法令で要求されるSBOMの依存関係

CRAではセキュリティ・バイ・デザインの考え方に基づき、デジタル要素を含む製品の設計段階からセキュリティへの配慮を製造者に課しており、発見された脆弱性に対するソフトウェアアップデートの速やかな提供を要求しています。また、製品に含まれる悪用された脆弱性や重大なインシデントを認識してから24時間以内に、 NIS2 でコーディネータとして指定されたCSIRTとENISAの両者への報告が義務付けられています。このような迅速な報告をするためにはソフトウェアコンポーネントの構成管理・把握ができていることが必要となりますが、 SBOMがソフトウェアに含まれるコンポーネントとその依存関係を記述するものであることから構成把握のための手段として効果的と考えられます。
また、CRA以外にもSBOMが必要となる法令・ガイドラインはいくつか存在しています。日本においては「政府機関等の対策基準策定のためのガイドライン」[2]等の政府機関が公開しているガイドラインや、通信業界向けSBOM作成ガイドとして「OpenChain Telco SBOM Guide」[3]等があります。こちらに関連して、2023年12月時点の情報となりますが、NECセキュリティブログにて「業種別(医療機器/自動車/電気・通信/金融)のSBOMへの取り組み」[4]を公開しています。

このように国、業界別で法令・ガイドラインは整備されつつあり、場面に応じて異なる要件に従わないといけません。不要なビジネスリスクを負わないためにも、自身の事業領域に沿ったSBOMに関する要件を把握する必要があります。

それではSBOMについて、CRAにおいて製造業者に要求されている要件を確認してみます。以下はCRAの付属書Ⅰ 必須要件[5]から抜粋した文章になります。

Manufacturers of products with digital elements shall:
(1) identify and document vulnerabilities and components contained in products with digital elements, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products;

上記の文章の和訳も併記します。

デジタル要素を含む製品の製造業者は、次の義務を負う。
（1）デジタル要素を含む製品に含まれる脆弱性とコンポーネントを特定し、文書化する。これには、少なくとも製品の最上位レベルの依存関係を網羅する、一般的に使用され、機械可読な形式でソフトウェア部品表を作成することも含まれる。

現状ではどのようなSBOMの作成が求められているかを上記の条文から理解する必要があります。しかしながら、CRAの条文では SBOMの具体的な作成方法について記載されていないため、どのようにSBOMを作成すればよいかが分かりません。
そこで、CRAの要件に備えるために SBOMの作成方法について詳細に記載されたガイドラインがあります。それはドイツ政府作成のSBOM技術ガイドライン「BSI TR-03183-2」 [6]になります。以後の章でも本ガイドラインに触れていますので、CRAとSBOMに関心がある方は一度読んでみてはいかがでしょうか。

要件を満たすSBOMの作成

この章では先ほど掲載したCRAの文章の中の「一般的に使用され、機械可読な形式でソフトウェア部品表を作成する」と「少なくとも最上位レベルの依存関係を網羅する」という部分について考えてみます。
1つ目の「一般的に使用され、機械可読な形式でソフトウェア部品表を作成する」を満たすということは、様々なガイドラインで紹介されているフォーマットで記述したSBOMと解釈し、執筆時点では主に「SPDX」、「CycloneDX」という機械可読なSBOMフォーマットで書くことで満たされると考えられます。なお、「BSI TR-03183-2」でもこれら2つのフォーマットが示されており、「一般的に使用され機械可読な形式」という条件について満たしていると考えられます。
2つ目の「少なくとも最上位レベルの依存関係を網羅する」ですが、例えば図1のように「ソフトウェア A」をイメージしたとします。そして、ソフトウェアAから見て直接的に依存関係のあるコンポーネント1, 2, 3があったとします。このような場合では、「最上位レベルの依存関係を網羅する」はソフトウェアAとコンポーネント1, 2, 3との依存関係を把握し、記述することと解釈ができます。最上位レベルの依存関係は具体的に図示すると図1の破線枠内になります。
この最上位レベルの依存関係は「少なくとも」と文言で明言されていることから、必ず記述することが求められています。それ以外のコンポーネント（例えば、ソフトウェアAに間接的に依存するコンポーネント1-1など）について言及はありませんが、把握できている範囲で記述するほうがよいかと思われます。

図1 ソフトウェアAにおける依存関係のイメージ

CycloneDXで依存関係を記述してみる

この章ではCycloneDXを使って、図1を例に最上位レベルの依存関係を記述してみます。
CycloneDXとはOWASPが主導しているフォーマットです。OWASPが提供しているツールの中にはCycloneDXに対応しているものもあり、CycloneDXフォーマットでのSBOMの作成・分析が可能です。詳細は割愛しますが、SBOMだけでなく他の種類のBOMであるHBOM、CBOM、SaaSBOMなどの作成に使用できます。
CycloneDXでは依存関係を「dependencies」というフィールドで表現します。フィールド内は以下の項目を使って表現します。[7]

「ref」：対象となるコンポーネントをbom-refを使って記述
「dependsOn」：refと依存関係のあるコンポーネントをbom-refを使って記述

※ 「bom-ref」：特定のコンポーネントを指す一意な識別子。「ref」、「dependsOn」の記述に使う

では本題に入ります。図1のソフトウェアA の最上位レベルの依存関係をCycloneDXで記述しますと、図2のようになります。なお、図1での各コンポーネントのbom-refは下記とします。@の右にはコンポーネントのバージョン番号を示しています。

ソフトウェアA：pkg:nec_service/com.nec/software_a@1.2.3
コンポーネント1：pkg:nec_service/org.nec/component_1@12.2.4
コンポーネント2：pkg:nec_service/org.nec/component_2@2.17.3
コンポーネント3：pkg:nec_service/com.nec/component_3@7.0.2

図2 図1の破線枠内の依存関係についてCycloneDX形式での記述例

依存関係において記述が難しいケース

この章では依存関係を記述するときにいくつかの記述方法があり、どの記述をすればよいか悩んでしまうケースを2つ紹介します。
1つ目のケースについてソフトウェアAの動作環境として複数のOSをサポートしている場合を挙げます。
例えば、ソフトウェアAがRed Hat Enterprise Linux 9、 Windows Server 2019、 Rocky Linux 9をサポートしている場合、ソフトウェアAはこれらのOSに依存していると言えます。
このとき、1つの表現方法として図3のようにまとめて捉える方法が考えられます。

図3 サポートしているOSを3つまとめて捉えた場合の依存関係のイメージ

これをSBOMの依存関係として記述してみると次のようになり、CycloneDXとして記述すると図4のようになります。なお、図3での各コンポーネントのbom-refは下記とします。

ソフトウェアA：pkg:nec_service/com.nec/software_a@1.2.3
コンポーネント1：pkg:nec_service/org.nec/component_1@12.2.4
コンポーネント2：pkg:nec_service/org.nec/component_2@2.17.3
Red Hat Enterprise Linux 9：pkg:RedHatEnterpriseLinux@9
Windows Server 2019：pkg:WindowsServer@2019
Rocky Linux 9： pkg: RockyLinux@9

図4 サポートしているOS3つをまとめて捉えた場合のCyloneDXの依存関係の記述例

このように書くとソフトウェアAが3つのOS上での動作をサポートしていると言うより、動作する上で3つのOSの機能を同時に使用しているような依存関係に見えます。
続いて、サポートOS毎にSBOMを作成する場合を考えます。このとき、図5のようになります。

図5 サポートOS毎に分割した場合の依存関係のイメージ

この捉え方であれば、SBOMを3種類に分割し、サポートOSに応じて作成することになります。それぞれの依存関係をCyloneDXで記述すると、次の図6, 7, 8のようになります。

ソフトウェアA：pkg:nec_service/com.nec/software_a@1.2.3
コンポーネント1：pkg:nec_service/org.nec/component_1@12.2.4
コンポーネント2：pkg:nec_service/org.nec/component_2@2.17.3
Red Hat Enterprise Linux 9：pkg:RedHatEnterpriseLinux@9

図6 Red Hat Enterprise Linux 9に依存する場合のCyloneDXの依存関係の記述例

ソフトウェアA：pkg:nec_service/com.nec/software_a@1.2.3
コンポーネント1：pkg:nec_service/org.nec/component_1@12.2.4
コンポーネント2：pkg:nec_service/org.nec/component_2@2.17.3
Windows Server 2019：pkg:WindowsServer@2019

図7 Windows Server 2019に依存する場合のCyloneDXの依存関係の記述例

ソフトウェアA：pkg:nec_service/com.nec/software_a@1.2.3
コンポーネント1：pkg:nec_service/org.nec/component_1@12.2.4
コンポーネント2：pkg:nec_service/org.nec/component_2@2.17.3
Rocky Linux 9： pkg: RockyLinux@9

図8 Rocky Linux 9に依存する場合のCyloneDXの依存関係の記述例

このように3つのSBOMに分けて作成することで、ソフトウェアAの動作は各OSの機能を同時に使うものではなく、いずれかのOSに依存して動作することを明確に表すことができます。
ここではOS毎に分けて記述する例を提示しましたが、OS以外のコンポーネントも動作環境により差分が生じる場合もあるかと思います。その場合は、さらに多くのSBOMを作成するケースも考えられますので、一概に分けて記述するほうがよいとも限りません。用途に応じてどちらで記述するか検討するのが良いかと思います。

2つ目のケースとして、製品に依存するコンポーネントを同梱する場合としない場合を挙げます。
例えば、ソフトウェアAを動作させるための主要なコンポーネントとしてOpenSSLが必要だとします。この時、OpenSSLをソフトウェアAに同梱して提供する場合、図9のようになり、同梱しない場合は図10のようになります。なお図中では、同梱して提供するものを「提供範囲」として記述しています。

図9 OpenSSLを同梱する場合の依存関係イメージ

図10 OpenSSLを同梱しない場合の依存関係イメージ

このとき、図9に対応した依存関係を書いたものが図11になります。
なお、図9での各コンポーネントのbom-refは下記とします。

ソフトウェアA：pkg:nec_service/com.nec/software_a@1.2.3
コンポーネント1：pkg:nec_service/org.nec/component_1@12.2.4
OpenSSL 3： pkg:OpenSSL@3
コンポーネント3：pkg:nec_service/com.nec/component_3@7.0.2

図11 OpenSSLを同梱する場合のCycloneDXの依存関係の記述例

なお、OpenSSLを同梱しているということは、OpenSSLの依存しているコンポーネントも把握できるということになります。「BSI TR-03183-2」では、最低限、このような同梱したコンポーネントとそれに依存するコンポーネントの依存関係※をSBOMに含めることを求めています。

※ なお、「BSI TR-03183-2」では、依存するコンポーネントについて以下の情報も含めるよう明言されています。

コンポーネント作成者
コンポーネント名
コンポーネントバージョン
その他の固有識別子

次に図10のようにOpenSSLを同梱しないケースを考えます。これは例えば、ソフトウェアAを動作させるための主要なコンポーネントとしてOpenSSLを必要としつつも、 OpenSSLをソフトウェアAに同梱せずにお客様にて調達するようなケースとなります。
このとき、図10に対応した依存関係を書いたものが図12になります。

ソフトウェアA：pkg:nec_service/com.nec/software_a@1.2.3
コンポーネント1：pkg:nec_service/org.nec/component_1@12.2.4
OpenSSL 3：pkg:OpenSSL@3
コンポーネント3：pkg:nec_service/com.nec/component_3@7.0.2

図12 OpenSSLを同梱しない場合のCycloneDXの依存関係の記述例

図11と図12を比較すると同じ内容であり、SBOMの依存関係からは提供範囲内外の区別がつきません。これらを区別することについてはCRAの要件には明確に記載されていないですが、CycloneDXには納品者の情報を記述するsupplierと製造者の情報を記述する manufacturerというフィールドが用意されていますので、それらのフィールドを記述するのが良いかと思います。

まとめ

CRAの要件を満たすSBOMについて考察し、依存関係の記述方法について悩ましい例を紹介しました。製品を提供する側が製品に組み込んでいるソフトウェアやコンポーネントについてどこまで責任を負うかについては、SBOMの依存関係の記述だけでは難しいと言えます。CRAでは製品に含まれる悪用された脆弱性や重大なインシデントを認識してから24時間以内の報告を求めており、SBOMの作成が不可欠となっています。CRAに限らず、今後はSBOMに関わる各種法令の要件明確化が進み、ガイドラインの整備が進んでいくことを期待します。SBOMでの依存関係の記述については引き続き注目したいと考えています。