こんにちは。富士通の関口と申します。Linuxソフトウェア事業部アプライアンス技術部のOSSアセスメントチームに所属しています。主な業務はOSS利用でのSBOM、ライセンス管理・脆弱性監視、ツール導入等についての調査等です。SBOMの最新トピックスについてご紹介します。
*Please scroll down for the English version.
記事の内容・目的
本記事では今年起きたSBOMに関する代表的なトピックスを概観します。SBOMフォーマットの仕様・脆弱性・ツール等の個別のトピックについての詳細は他の方の記事を参照いただければと思います。
SBOMとは
SBOMとは「ソフトウェアを構成するコンポーネントの一覧」を指します。SBOMとは何かについてをもっと知りたい方は昨年のAdvent Callenderで紹介した「ソフトウェアの透明性とSBOM 」などをご参照ください。
SPDX
SPDX v2.3
SPDXのバージョン2.3が発表されました。以前の版と比較して仕様が変更されています。
SPDX2.3仕様
注目すべき点としてLicenseの項目がmandatory（必須）ではなくなったことが挙げられます。これは昨今の脆弱性監視の重要性の増加やCycloneDX等他の標準仕様との競合に伴い下された決定と思われますが、今後議論が必要なポイントだと考えられます。
今回の仕様変更に限らず、SBOMを利用してコンポーネント管理を行う際には「作成者が目的をもって主体的に作成・管理する」ことが重要です。取引先に要求されたから、製品出荷の際にエビデンスとして必要だからという目的で開発担当者が義務感でSBOM作成を担当し、SPDXの仕様への準拠だけを目的としてSBOM作成を行うと、期待する成果が得られない可能性があります。
なぜ主体的に作成・管理する必要があるのか
脆弱性管理が目的の場合とコンポーネント・ライセンス管理などそれ以外の目的の場合で作成・管理の目的が異なります。
例えば、SPDXバージョン2.3の仕様に合致するようにSPDXフォーマットでSBOMを作成した場合、Licenseの項目記載は任意のため空欄でも問題はありません。ただし、ライセンスの項目を空欄のままで作成した場合、SPDXからライセンス情報を確認することができず、各企業で設定したOSSライセンスポリシー違反の確認・是正をSPDXで行うことができません。
これは一例となりますが、SBOMを作成・管理する場合、各企業が目的をもって記載・管理していく必要があると考えます。
SBOMツール
現在、SBOMが生成できる様々なツールが存在します。前述の通り、SBOMはただ作成するだけはライセンスや脆弱性を正しく管理実施することができません。そのため目的をもって作成し、作成後の運用に主眼を置くことが必要になります。
SBOMの代表的なフォーマットとその特徴
SPDX
もともとは主に利用しているコンポーネントのライセンスを管理するために作成されたフォーマットです。
以下の６形式のいずれか（Tag:Value(txt)・RDF・xls・json・YAML・xml）で記載し、SPDX Specificationが規定した情報が記載されたファイルです。
SPDX-Identifierという短い識別子を用いてライセンスを一意に判別できることも特徴の１つです。
2021年9月にSBOMに関連するISO標準（ISO/IEC 5962:2021）として認められたことで注目されたフォーマットです。脆弱性監視・対応の需要増加に合わせてバージョン2.3で大きな仕様変更がなされました。
CycloneDXと比較すると、mandatoryでない項目も含め各コンポーネントの情報を詳細に記載することができる一方、その記載量に応じてデータが大きくなることもポイントです。
CycloneDX
セキュリティ対応を目的とし、作成されたフォーマットです。現在の最新版はバージョン1.4です。
セキュリティ監視やサプライチェーンの利用コンポーネントのチェック用に設計されたSBOM規格であり。SPDXと比べ必須（Required）の項目が少なく、目的を決めて記載箇所を絞って利用すれば比較的軽量なフォーマットです。
CycloneDX1.4仕様
ソフトウェアを構成するコンポーネントの情報を提供することで、SPDXなど他のSBOMフォーマットと同様の目的を達成することを目的としています。
CycloneDXは、4つのカテゴリーのデータ（Bill of Materialsのメタデータ・コンポーネント・サービス・依存関係）をサポートしています。
脆弱性について
最近話題になったOSSの脆弱性として以下が挙げられます。
Log4j（CVE-2021-44228：2021年12月）
Webアプリケーションで広く一般的に利用されているロギングライブラリのため、ゼロデイ攻撃の標的になった脆弱性です。組織内の影響度調査に苦労した方も多かったのではないでしょうか。SBOM管理し、どの製品に利用しているかを明らかにしていれば対応を実施しやすかったと思われます。
Apache Commons text（CVE-2022-42889：2022年10月）
SBOMの観点で注目したいのがApache Commons textの脆弱性です。本件が話題になった背景として、過去にcpeでの脆弱性が検出されておらず、紐づけに時間がかかった点が挙げられます。そのため、cpeと脆弱性情報との紐づけがなされた時点で脆弱性を検出、通知するツールは情報公開が遅くなりました。
今後も発生するであろう新規cpeに紐づけられる脆弱性に対応するためには現在のSBOMの形式のままでいいのか？など検討課題が挙げられると思います。
OpenSSL（CVE-2022-3358、CVE-2022-3602、CVE-2022-3786：2022年11月）
CVE-2022-3358の脆弱性発表当初、3.0.6で修正が発表されましたが修正が不完全だったため取り下げられました。その後CVE-2022-3602, CVE-2022-3786が発表され、それら3件の修正に対応した3.0.7が正式に発表されました。また併せてCRITICALからHIGHに深刻度の引き下げが行われました。
3件の脆弱性の影響対象はいずれも3.0.7よりまえの3.0.xであり、1.x系のバージョンの利用者は対象外でした。SBOMをツールで管理してバージョン管理できていれば自組織内の利用バージョンの該非を自動判定可能することが可能だったと思われます。
終わりに
SPDXの仕様変更、比較的大きな脆弱性の発生と対応などから今年はSBOMを用いた脆弱性管理の重要性がさらに高まった一年だったように思います。SBOM作成・管理の目的を正しく理解し、活用できるようにしていきたいですね。
明日は森田さんからLog4jに関する脆弱性についての記事です。本記事でも触れたLog4jに関する脆弱性について深堀していただけると思います。お楽しみに！
Hello. I'm Sekiguchi from Fujitsu. I am part of the OSS Assessment team in the Appliance Technology Department of the Linux Software Division. My main tasks are SBOM, license management, vulnerability monitoring, and tool introduction. This section introduces the latest topics on SBOM.
Specifically, the following contents are described.
- What is SBOM?
- Why is it necessary to create and manage them independently?
- SBOM Tools
- Typical SBOM formats and their characteristics
- SPDX
- CycloneDX
- About Vulnerabilities
- Log4j
- Apache Commons Text
- OpenSSL
Due to changes in SPDX specifications and the occurrence and response of relatively large vulnerabilities, the importance of vulnerability management using the SBOM has increased this year. We would like to be able to correctly understand and utilize the purpose of SBOM creation and management.