この記事はNTTテクノクロス Advent Calendar 2023、シリーズ2の18日目の記事です。
こんにちは!NTTテクノクロスの千歳です。
普段は、セキュリティに関する技術研究やリサーチ、開発業務に携わっています。
はじめに
本記事では、SBOM(Software Bill Of Materials)に関して、概要および実際に作ってみる方法に触れていきたいと思います。
SBOMとは?
SBOMは、例えとして、しばしば【ソフトウェアの食品成分表】と言われています。ソフトウェアや機器に含まれているソフトウェアコンポーネントにはどういったものが含まれているのか、バージョンやライセンスはどうなっているのか、などがまとめられたドキュメント(インベントリ)です。
SBOMの最小構成要素として、NTIA(National Telecommunications and Information Administration)が以下のように発表しています。
- サプライヤー名(Supplier Name)
- コンポーネント名(Component Name)
- コンポーネントのバージョン(Version of the Component)
- その他の一意な識別子(Other Unique Identifiers)
- 依存関係(Dependency Relationship)
- SBOMの作成者(Author of SBOM Data)
- タイムスタンプ(Timestamp)
昨今、ソフトウェアサプライチェーン攻撃も増加しており、Apache Log4jやSolarWinds社の製品が攻撃を受けて大きな話題にもなりましたが、ソフトウェアが利用するライブラリまで明示的に管理しているケースは少なく、影響を確認するのも一苦労でした。こういった課題に対して、近年話題になっているのがSBOMです。
SBOM動向
2021年に米国で発令された国家サイバーセキュリティに関する大統領令第14028号をはじめとして、EUのサイバーレジリエンス法などでSBOMの提供・活用が推奨もしくは義務化する流れが進んでいます。特に医療機器業界では、米国食品医薬品局(FDA)がSBOMを医療機器の市販前申請に含めるよう強く推奨しています。
日本でも、各所でSBOMに関する研究・検討が進められています。例えば、経産省では、ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引が公開されており、実証実験が進められていますし、総務省でも通信機器に対するサプライチェーンリスク対策としてSBOMの活用を検討しています。さらに、厚生労働省からは、薬機法の医療機器の基本要件基準第12条第3項の改正にて令和6年よりSBOMの提供が求められることとなっており、日本国内でもSBOMを作って利用する、あるいは提供するケースが増えていくことが予想されます。
SBOMを作ってみよう!
それでは、実際にSBOMの作り方について、いくつかご紹介していきます。
SBOMの作り方として有償ツールで作る方法と、無償ツールで作る方法があります。本記事では、自由にお試ししやすい無償ツールを使ったSBOMの作り方について触れていきたいと思います。
SBOM生成ツール
ソフトウェアを対象にSBOMを作る場合、ソフトウェアの開発言語に合わせてツールを選定する必要があります。
例えば、JavaであればMavenやGradleでも生成可否はツールによって変わります。今回は、以下4つのツールでSBOMを作ってみます。
No. | ツール | 提供元 |
---|---|---|
1 | syft | Anchore |
2 | Trivy | Aqua Security |
3 | SBOM Tool | Microsoft |
4 | GitHub SBOM Export | GitHub |
SBOM作成
では、実際にSBOMを作ってみましょう。今回は、コンポーネント解析プラットフォームであるOWASPのDependency-Track(Java)を対象に、SBOMフォーマットの1種であるSPDX形式のSBOMを作成していきます。
- GitHubリポジトリからDependency-Trackのソースコードを取得します
# get Software
$ git clone https://github.com/DependencyTrack/dependency-track.git
- Syft : バイナリをインストールし、依存関係ファイル(pom.xml)からSBOMを作成します
# install syft
$ curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin
# exec syft
$ syft file:./dependency-track/pom.xml -o spdx-json --file dependency-track_spdx.json
- Trivy : Docker Imageを利用し、依存関係ファイル(pom.xml)からSBOMを作成します
# install Trivy(container)
$ docker pull aquasec/trivy:0.48.0
# exec trivy
$ docker run -v ./dependency-track:/app:rw -v /var/run/docker.sock:/var/run/docker.sock -v $HOME/Library/Caches:/root/.cache/ aquasec/trivy:0.48.0 fs --format spdx-json --output /root/.cache/dependency-track_spdx.json /app/pom.xml
- SBOM Tool : バイナリをインストールし、ローカルプロジェクトからSBOMを作成します
# install SBOM Tool
$ curl -Lo sbom-tool https://github.com/microsoft/sbom-tool/releases/latest/download/sbom-tool-linux-x64
$ chmod +x sbom-tool
# exec Sbom-tool
$ sbom-tool generate -b ./dependency-track -bc ./dependency-track -pn dependency-track -ps ntt-tx -pv 4.11.0-SNAPSHOT
- GitHub SBOM Export : GitHubにログインし、GUIからエクスポートします
- Insights -> Dependency graph を選択し、"Export SBOM"をクリックします
実際に出力されたSBOM(抜粋)は以下の通りです。
※ 一部のツールでは整形されていないため、自前でフォーマットする必要があります
{
"name": "commons-compress",
"SPDXID": "SPDXRef-Package-java-archive-commons-compress-c05bee49fdbbcc30",
"versionInfo": "1.25.0",
"supplier": "NOASSERTION",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"sourceInfo": "acquired package info from installed java archive: /pom.xml",
"licenseConcluded": "NOASSERTION",
"licenseDeclared": "NOASSERTION",
"copyrightText": "NOASSERTION",
"externalRefs": [
{
"referenceCategory": "SECURITY",
"referenceType": "cpe23Type",
"referenceLocator": "cpe:2.3:a:apache:commons-compress:1.25.0:*:*:*:*:*:*:*"
},
{
"referenceCategory": "SECURITY",
"referenceType": "cpe23Type",
"referenceLocator": "cpe:2.3:a:apache:commons_compress:1.25.0:*:*:*:*:*:*:*"
},
{
"referenceCategory": "SECURITY",
"referenceType": "cpe23Type",
"referenceLocator": "cpe:2.3:a:apache:commons:1.25.0:*:*:*:*:*:*:*"
},
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:maven/org.apache.commons/commons-compress@1.25.0"
}
]
}
{
"name": "org.apache.commons:commons-compress",
"SPDXID": "SPDXRef-Package-747f95bec5d691f0",
"versionInfo": "1.25.0",
"supplier": "NOASSERTION",
"downloadLocation": "NONE",
"filesAnalyzed": false,
"licenseConcluded": "Apache-2.0",
"licenseDeclared": "Apache-2.0",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:maven/org.apache.commons/commons-compress@1.25.0"
}
],
"attributionTexts": [
"PkgID: org.apache.commons:commons-compress:1.25.0"
],
"primaryPackagePurpose": "LIBRARY"
}
{
"name": "org.apache.commons.commons-compress",
"SPDXID": "SPDXRef-Package-748D8C5DFA50C9CB753835F9F1DFF6F0E089469C9FE617F31C0AA113F494E434",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"licenseConcluded": "NOASSERTION",
"licenseDeclared": "NOASSERTION",
"copyrightText": "NOASSERTION",
"versionInfo": "1.25.0",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceType": "purl",
"referenceLocator": "pkg:maven/org.apache.commons/commons-compress@1.25.0"
}
],
"supplier": "NOASSERTION"
}
{
"SPDXID": "SPDXRef-maven-org.apache.commons-commons-compress-1.25.0",
"name": "maven:org.apache.commons:commons-compress",
"versionInfo": "1.25.0",
"downloadLocation": "NOASSERTION",
"filesAnalyzed": false,
"supplier": "NOASSERTION",
"externalRefs": [
{
"referenceCategory": "PACKAGE-MANAGER",
"referenceLocator": "pkg:maven/org.apache.commons/commons-compress@1.25.0",
"referenceType": "purl"
}
]
}
作成したSBOMを比較してみると、以下のような結果となりました。
ツール名/version | 出力ファイルサイズ | 検出コンポーネント数 | 検出ライセンス数 | 備考/他ツールとの差異など |
---|---|---|---|---|
syft/0.98.0 | 115KB | 51件 | 0件 | 脆弱性識別子であるCPEが1コンポーネントに複数個出力されている |
Trivy/0.48 | 62KB | 72件 | 68件 | コンポーネントの主目的(primaryPackagePurpose)が出力されている |
SBOM Tool/2.2.1 | 1,483KB | 307件 | 0件 | プロジェクトのファイル(XXX.java)やそのHASH値が出力されている |
GitHub SBOM Export/- | 43KB | 78件 | 0件 | GitHubの設定(GitHub Actionなど)がコンポーネントとして検出されている |
検出されたコンポーネント数などもそれぞれのツールで異なっており、SBOM生成ツールによって特性が異なることが分かります。SBOMを実際に利用する際には、SBOMに期待する要件や要求に合わせて、ツールの選定および合意を得る必要があります。
他のSBOM作成方法について
主にソフトウェアを対象としたSBOMの作成方法について紹介しましたが、他にもSBOMを作成する方法は多数あります。
SBOMはContainer技術とも親和性が高く、例えばDocker Scoutを利用してImageファイルからSBOMを作成する方法もあります。また、AWSでもAWS Inspectorの機能にSBOM Exportが追加されるなど、利用しているサービス側の一部機能に組み込まれるケースも増えていますので、環境やユースケースに合わせた選択が可能です。
最後に
今回はSBOMの作成に注力しましたが、SBOM作成のモチベーションには脆弱性管理やライセンス管理に利用することが考えられています。SBOMを管理するツールやSBOMをinputに各コンポーネントの脆弱性を取得するツールもOSSなどで提供されているため、興味のある方は色々なSBOMを作ってお試しされてはいかがでしょうか。
というわけで、SBOMの概要及び作り方について簡単に紹介させていただきました。
明日は、 @Yuka Kawasaki氏によるAWS troubleshootingに関する記事となります。お楽しみに!