SBOM - リスクマネジメントからその先へ- (OWS2023から)

はじめに

こんにちは。OpenChain Japan-WG、Automation-SGリーダーの忍頂寺です。
OpenChain Japan Advent Calender 17日目を担当します。

本記事は、2023年10月にOSSセキュリティ技術ワークショップ(OWS)2023 でお話した「SBOM -オープンソースコンプライアンスなどリスクマネジメントの基礎となるもの。そして、その先へ-」のダイジェストとしつつ、若干の更新を追加しています。

SBOM: ソフトウェアサプライチェーンにおけるリスクマネジメントの基礎として

SBOM (ソフトウェア部品表) について、ライセンスコンプライアンスやサイバーセキュリティの観点からその必要性が知られています。昨今は特にサイバーセキュリティ (脆弱性管理) の強化のためSBOMの管理を法的に求められる流れがあり、取引要件としても求められるケースが増えつつあります。その対象は、政府調達や重要インフラやデジタル製品など各国法令が定めようとしており、関連して業界独自の取組などもあります。関係する産業での動向を適切に把握することが重要です。

この時「SBOM」はソフトウェアサプライチェーンにおいてソフトウェアと共に流通します。そのため、サプライヤ (SBOMのプロデューサ) と エンドユーザ (SBOMのコンシューマ) とでの情報の相互流通性の確保が重要となります。

現在までのところ、日米欧の動きからは、米国NTIAが発行する「The Minimum Elements For Software Bill of Materials (SBOM) 」を基礎にしてSBOMに関する検討と共通認識の整備が進んでいるように思われます。この文書では、SBOMにおける管理項目ともいえるデータフィールド、SBOMの運用に係る自動化促進に向けてのフォーマット、SBOMの実務上の要点などを扱っています。この文書も言及する通り、SBOMについては、それがどのようなものであるべきか、どのように作成し、流通し、運用すべきか、またSBOMの品質とは何か、どのようにしてその品質を確保するかなど、現時点でも発展途上の部分があることには注意が必要です。したがって、同文書が発行されて以降、各所で活発な議論がなされている中、同文書の改訂又は同文書を置き換える文書の発行もありえます。

参考までにデータフィールドについて紹介します。同文書が示す要求項目や推奨項目に加えて、実務的にはライセンスに関する項目を含むのが良く見られる内容です。こうした情報に基づいてソフトウェア(システム)を構成するソフトウェアコンポーネント(部品)を明確にします。コンポーネントの粒度についてはパッケージとする見解が多く見られます。そして個々のコンポーネントにその脆弱性情報があれば関連付けて管理することになります。表1は、SBOMのデータフォーマットの国際標準 ISO/IEC 5962 (SPDX Specification V2.2.1) のベースであるSPDXのデータフィールドにマッピングして検討したものです。

表1. SPDX データフィールドの比較検討
(Source: [WIP] SPDX datafield comparison より)

SPDX Lite ¹は、実務的な観点に基づいてオープンソースライセンスコンプライアンスで必要となる最小限の要素を定義しています。

SPDX v2.2 及び SPDX v2.3 (以降双方を指してSPDX v2.2+)では Annex G として規格されています。なお SPDX v2.2+における SPDX Lite を利用しつつ先にみたNTIAの文書に準拠したい場合は注意が必要です。同文書では管理項目にて Dependency Relationship (コンポーネント間の依存関係) を要求し、Lifecycle Phase²を推奨としています。SPDX v2.2+における SPDX Lite を利用して同文書に準拠したい場合はこれら追加項目への対応が必要になります。公的機関が発行するガイド³、オープンソースコミュニティでの議論⁴、さらに商取引などで挙がる論点を考慮すると、この表1のCaseStudy1に見られるデータフィールドは一つの目安になるかも知れません。

なお Lifecycle Phase として挙げられる SBOM Type に次のものが挙げられます(図1、2、表2)。

図1. SBOM Type
(Source: Kate Stewart. “SPDX SBOMs: Enabling Automation of Safety & Security Analysis SPDX SBOMs: Enabling Automation of Safety & Security Analysis” から一部改変)

表2. SBOM Type の概要
(Source: CISA. Types of Software Bill of Material (SBOM) Documents. から抄訳
https://www.cisa.gov/sites/default/files/2023-04/sbom-types-document-508c.pdf)

図2. SBOM Type に基づくTraceability
(Source: Kate Stewart. “SPDX SBOMs: Enabling Automation of Safety & Security Analysis SPDX SBOMs: Enabling Automation of Safety & Security Analysis” から一部改変)

SBOM Type はそれぞれソフトウェア開発工程に基づくものであり、それぞれの段階で変化するであろうソフトウェア構成を反映することとなります。NTIAの文書が発行された当時は推奨でしたが、昨今ではこの項目を必要とする例が増えつつあります。

管理項目については産業に中立的なものとして整備できていると、サプライチェーンにおけるSBOMの流通性が高まると期待されます⁵。SPDX は次期仕様v3.0⁶の検討が進んでおり、SPDX Lite もv3.0に対応して Lite Profile¹ として提案されています。

なお、オープンソースに関するプロセスマネジメント標準である ISO/IEC 5230 (OpenChain Specification)(ライセンスコンプライアンスに関する)や、ISO/IEC 18974 (OpenChain security assurance specification)(セキュリティアシュアランスに関する)でも、SBOMの作成、その内容のレビューと承認のプロセスを要件に挙げています(図3)。組織内でのプロセスの整備を検討する際にはこれらの仕様も参考になります。

図3. ISO/IEC 5230 及び ISO/IEC 18974 の要件比較
(Source: 忍頂寺. OWS2023講演資料より)

SBOM: ソフトウェアアセットマネジメントの基礎として

ここで述べることは、コミュニティでの意見をまとめたものではないことを予めお断りしておきます。

ソフトウェア開発力の強靭化のためには、基礎情報として実態の把握が必要になります。SBOMはソフトウェアの構成を管理するものです。SBOMの管理は、法令遵守や取引要件への対応に留まらず、価値創出に向けた取り組みと捉えることもできます(図4)。

図4. SBOMはソフトウェアアセットマネジメントの基礎である
(Source: 忍頂寺. OWS2023講演資料より一部改変)

事業戦略、技術戦略、ソフトウェア技術戦略等々、組織に応じて様々な「戦略」を定めると思われます。SBOMを作成管理する仕組みを構築することで、ソフトウェアに係る競争力を高める取り組みに活用することが考えられます(図5)。

図5. SBOMから自組織のソフトウェア技術(力)を把握する
(Source: 忍頂寺. OWS2023講演資料より)

このとき、ソフトウェア開発の文化や環境の整備は非常に重要です。
DevSecOpsやCI/CDなどでも、SBOMの管理運用における自動化や省力化への関心が高まっています。ワークフローの確立では、再現性があり一定の品質を達成するとともに、記録管理の整備などが考えられます。次の図6では開発からリリースするまでを記していますが、先に見たLifecycle Phase にあるとおり、設計から終了までをカバーするためには、調達やリリース後の保守といった工程にも留意が必要になります。

図6. ソフトウェア開発環境の整備
(Source: 忍頂寺. OWS2023講演資料より)

オープンソースでの取組であれば、Linux Foundation での取組だと Cloud Native Computing Foundation (CNCF)、Open Source Security Foundation(OpenSSF)、Continuous Delivery Foundation (CD Foundation) などの活動や成果が参考になるかも知れません。

おわりに

1. 明日(12/18)は、@hiromotai7 さんが2023年12月4日に開催された OpenSSF Day Japan / Open Source Summit Japan 2023 の模様を紹介します。お楽しみに！　
2. 是非、SPDX のウェブサイトの"Areas of Interest"と、そこから "SPDX Lite" のページをご覧ください！ 2023年12月に SPDX Lite のロゴが決まりました！
3. OpenChain Japan-WG の Automation-SG & SBOM-SG では、SBOMの検討や普及展開に取組んでいます。関心のある方、 OpenChain JapanWG のSlackに気軽にご参加ください！
4. OWS2023 の実行委員会及び参加頂いた皆様に改めて感謝申し上げます。セキュリティ業界の方々を中心とするコミュニティでSBOMに関してお話しするのは初めてでしたが大変刺激的なものでした。より広くコミュニティの方々と連携してオープンソースの発展に貢献していきたいとの思いを新たにした機会でした！

1. @Yoshiyuki_Itoによる「SPDX v3.0 に向けた Lite Profile の紹介」も参照ください。 ↩ ↩²

2. ソフトウェア開発ライフサイクルに照らしてどの段階のSBOMか。SBOMタイプとも。米国CISAが発行する「Types of Software Bill of Materials (SBOM)」なども参照ください。 ↩

3. ドイツ情報セキュリティ局による、CRA法案への対応で必要となるSBOMを作成する上でのガイドとして発行しているものに TR-03183-2 があります。 ↩

4. Draft Proposal for an OpenChain Telco SBOM Specification Version 1.0。@Masahiro_DAIKOKUによる「OpenChain Telco-WG のご紹介」も参照ください。参照記事にもある通り、SPDX 3.0 に向けた Lite Profile の検討は、Telco-WGの検討成果を盛り込むなど業界を超えた取り組みになっています。 ↩

5. 医療機器については、IMDRF (International Medical Device Regulators Forum) による "Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity"や、FDA (U.S. Food & Drug Administration) による "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions" などがあります。FDAはNTIA文書が挙げる項目以外に"Software level of Support" (SPDX v2.2+で該当するデータフィールドの定義がない。SPDX 3.0では検討中) や "End-of-support date" (SPDX v2.2+では"ValidUntilDate"が相当。SPDX 3.0でも定義予定) などもSBOMで明確にすることを求めています。 ↩

6. @nori0428による「SPDX v3.0 概要と仕様の理解」も参照ください。 ↩