こんにちは。
最近流行の兆しを見せている用語こと SBOM って一体何?と調べたところ、経産省が少し前 1 に手引きを出していたのでそれを噛み砕いた記事となっています。全部読む方は75ページあるので頑張ってください。
SBOM(Software Bill of Materials)の導⼊に関する⼿引(仮称・案) - 経済産業省 商務情報政策局 サイバーセキュリティ課
SBOMって何?なぜ必要?
Software Bill of Materials の略で、ソフトウェアコンポーネントやそれらの依存関係の情報も含めた機械処理が可能なリストです。
複数のOSSを組み込んでアプリを作るのは今や当然となっていますが、
それぞれのOSSがどのライブラリを利用しているか? を把握できている人はほぼいないと思われます。
例えば先日log4jの脆弱性が見つかった際「ウチの製品には組み込んでないよ」と思っていたのに
「製品が使っているOSSが使っているOSSが使っていた」 なんてこともあるはず。
それらの依存関係を指定のフォーマットに従って記述したドキュメント のことをSBOMと呼び、
SBOMを運用することで特定コンポーネントの脆弱性が発見されたときに、影響を受けるコンポーネントをすぐ特定することが可能になります。
概念イメージ
"私"は ニンジン がめちゃくちゃに嫌いで、エキスすら口に入れたくありません。
さて、目の前のハンバーグを"私"は食べることができるでしょうか?
ハンバーグの材料
- ひき肉
- 玉ねぎ
- 油
- つなぎ
- パン粉
- 牛乳
- 塩コショウ
- 砂糖
- ニンニク
- ソース
- 醤油
- ウスターソース
- トマト
- タマネギ
- ニンジン (あっ!!)
- セロリ
- リンゴ
- ケチャップ
- トマト
- お酢
- タマネギ
答え:食べられない
ひき肉や油までなら把握しているけれど、ソースの材料まで把握していないですよね?
それを把握できるフォーマットを使って組織を超えた管理をしていこうぜ、というものがSBOMです。
SBOMの定義は?
それでは SBOMの要件を満たすには何を記述するか? についてです。
最小要件
SBOMの要件として、以下の3つの観点を満たす必要があります。
- データフィールド(Data Fields)
- 自動化サポート(Automation Support)
- プラクティスとプロセス(Practices and Processes)
それぞれ解説します。
データフィールド(Data Fields)
各コンポーネントに関する情報を明確化するために、以下の情報を含めます。
要するにコンポーネントを一意に特定するための情報です。
例えば「log4j2」と一口に言ってもサプライヤーがApacheかMicrosoftかNew Relicか分かりませんし、
バージョンが分からなければ対策のしようもありませんよね。
- サプライヤー名(Supplier Name)
- コンポーネント名(Component Name)
- コンポーネントのバージョン(Version of the Component)
- その他の一意な識別子(Other Unique Identifiers)
- 依存関係(Dependency Relationship)
- SBOM作成者(Author of SBOM Data)
- タイムスタンプ(Timestamp)
自動化サポート
SBOMの⾃動生成や可読性などの⾃動化をサポートするために、
SPDX(Software Package Data Exchange)、SPDX-Lite、CycloneDX、SWIDタグ(SoftWare IDentificationタグ) などのフォーマットを用いて作成すること。
これらはあとで解説しますが、とりあえず代表的なSBOMフォーマットの呼称とだけ覚えておいてください。
プラクティスとプロセス(Practices and Processes)
SBOMを利活用する組織はSBOMの要求、生成、利用に関する以下の運用方法を定義すること。
- SBOMの作成頻度
ビルドやリリースがある度に新しくSBOMを作ってね - SBOMの深さ
トップレベルだけじゃなくて間接的な依存関係も含めてね - 既知の未知
依存関係グラフが不完全な場合「これ以上ない」のか「未知なので不完全」かと明確に記してね - SBOMの共有(Destribution and Delivery)
適切なアクセス許可と役割が与えられた状態で、タイムリーに利用可能にしてね - アクセス管理(Access Control)
SBOMの一部を非公開にしたい場合、適切なアクセス制限をしてね - 誤りの許容(Accommodation of Mistakes)
発展途上の手法だから間違えても許してね☆
各フォーマットについて
SPDX(Software Package Data Exchange)とは?
Linux Foundationが開発するSBOMフォーマットです。
特徴としてはスニペット、ファイル、パッケージ、コンテナ、OSディストリビューション等の幅広いソフトウェアをサポートしているほか、コンポーネントのライセンス情報を一意に特定するための識別子のリストが用意されていることが挙げられる。
Tag-Value(txt)形式、RDF形式、xls形式、json形式、YAML形式、xml形式がサポートされている。
後述のCycloneDXではTag-Value、RDF、xls(xlsx)、YAMLがサポートされていないので、これらのフォーマットを用いる場合はSPDX採用ですね。
SPDX-Liteとは?
OpenChain Japan Work Groud(WG)によって開発された日本発のフォーマットです。
SPDXをもっともっと簡単にして手作業で作れるように簡易化されました。
日本語ドキュメントも豊富なので、とりあえず感覚を掴みたい方はここからスタートするのが手っ取り早いと思います。
ただその特徴故にどうしても小規模向けです。大規模プロジェクトであればLiteは検討の余地もありません。
難しくないよ、やろうよ。
CycloneDXとは?
OWASP Foundationが開発するSBOMフォーマットです。
セキュリティに特化したSBOMフォーマットの標準を開発することを目標とし、~~~
コンポーネントやライセンス、コピーライト等の情報が記載され、json形式、xml形式、Protocol Buffers形式がサポートされている。
SPDXではprotobuf形式がサポートされていないので、その場合はCycloneDX採用ですね。
SWIDタグとは?
ISOとIECによるソフトウェアの特定に関する国際規格です。
SPDXとCycloneDXがSBOMフォーマットの二大巨頭のようで、SWIDタグの資料は全然見つかりませんでした・・・・・・。2
どれを選べばいいの?
-
より詳細なライセンス情報を提供したい場合は SPDX
ライセンス一覧表、パッケージ依存関係といったライセンスデータを正式な表現として扱い、ライセンス情報の一貫性と明確さを確保します。 -
とにかく手軽に作りたい場合は SPDX-Lite
他の3つはツールを利用して作ることが前提となっていますが、SPDX-Liteのみ手作業で作成できるほどの手軽さを持ちます。 -
より詳細なセキュリティ情報を提供したい場合は CycloneDX
CycloneDXは対象とするソフトウェア以外にも、ソフトウェアに含まれる既知の脆弱性に関する情報、悪用可能性に関する情報を記述することも可能です。 -
SPDX-Liteで間に合わない規模のプロジェクトだけど手軽に作りたい場合は SWID
他の2つと比べてデータ構造が単純なので、データの提供や処理がより簡単になっています。
逆に詳細な情報提供には不向きです。
SBOMの最小要素に対する項目対比
ただただ記述が違うだけなのですが、普段SPDXを読んでいる人がCycloneDX読んだら混乱するだろうなと。
データフィールド | SPDX | SPDX-Lite | CycloneDX | SWID |
---|---|---|---|---|
サプライヤー名 | PackageSupplier | PackageSupplier | component/supplier/name | <Entity> @role(tagCreator) @name |
コンポーネント名 | PackageName | PackageName | component/name | <SoftwareIdentity> @name |
コンポーネントバージョン | PackageVersion | PackageVersion | component/version | <SoftwareIdentity> @version |
その他一意の識別子 | DocumentNamespaceと SPDXIDの組み合わせ ExternalRef |
SPDX Identifierと SPDX Document Namespaceの組合せ PackageSPDX Identifier |
serialNumber component/cpe |
<SoftwareIdentity> @tagId |
依存関係 | Relationshit(DESCRIVES; CONTAINS) | ----- | dependencies/dependency ref | <Link> @rel @href |
SBOM作成者 | Creator | Creator | metadata/authors/author/name | <Entity> @role(softwareCreator) @name |
タイムスタンプ | Created | Created | metadata/timestamp | <Meta> @timestamp |
SBOMを作るのに便利なツールは?
経産省の資料を見るだけでも 有償が6種類、無償が14種類 挙げられていますので、選定にも時間がかかります。
当記事はそこまで触れることはせず、ツール名の紹介にとどめておきます3 。
リンクに関しては
・ツール名 - 開発者名(リンク先は公式ページ)
・解説ページ
の構成になっています。
有償ツール
-
Black Duck - Synopsys, Inc.
→ OSS管理&SBOM管理ツール Black Duck - HITACHI -
Insignary Clarity - Insignary, Inc.
→ Insignary Clarity - HITACHI -
MEND SCA - WhiteSource Software, Inc.
→ Mend社のソフトウェアコンポジション解析ツール(旧名称:WhiteSource) -
Snyk - Snyk, Ltd.
読みはスニーク、無償版もあるそうです。利用された方のQiita記事がありました。
無償ツール
リンク先はGitHubです。
-
Augur - CHAOSS
-
Checkov - Bridgecrew, Inc.
→ 公式ページ
-
Daggerboard - NewYork-Presbyterian Hospital
-
Dependency-Track - OWASP Foundation
→ 公式ページ
-
FOSSology - Linux Foundation
→ 公式ページ
-
in-toto - Linux Foundation
-
OSS Review Toolkit(ORT) - Linux Foundation
-
SBOM Tool - Microsoft Corporation
-
Scancode.io - nexB, Inc.
→ 公式ページ
-
Scancode Toolkit - nexB, Inc.
→ 公式ページ
-
SW360 - Eclipse Foundation
→ 利用された方のQiita記事
-
SwiftBOM - CERT Coordination Center(CERT/CC)
-
Syft & Grype - Anchore Enterprise
→ 利用された方のQiita記事
- Trivy - Aqua Secutiry Software, Ltd.
最後に
くぅ疲。
もしかしたら特定の無償ツールに焦点を当てた記事を書くかもしれません。
参考リンク
-
経済産業省
第9回 サイバー・フィジカル・セキュリティ確保に向けたソフトウェア管理手法等検討タスクフォース - 経済産業省
SBOM(Software Bill of Materials)の導⼊に関する⼿引(仮称・案) - 経済産業省 商務情報政策局 サイバーセキュリティ課 -
HITACHI solutions
株式会社日立ソリューションズ OSS活用コミュニティ - Qiita
@d-morishita
日立ソリューションズに所属されており4 、特にSBOM周りの投稿が多い方です。
SBOM:Software Bill Of Materialsとは?(フォーマット、ユースケース、ツールについて)
資料ダウンロード -
その他参考にさせていただいた記事
OSS管理のベストプラクティス&OSS管理ツールの選び方 - Qiita
OpenChain Project - Qiita
深堀りしたい方はOpenChain Projectなども見ていくと良いかと思います。