皆さんは Software Bill of Materials 通称：SBOM というものをご存知でしょうか？ 私自身は、チームメンバーがDevelopers Summit 2022 で聞いた話を聞いて初めてその存在を知りました。 昨今 DevSecOps という言葉があるように、DevOps のなかで Security も担保してソフトウェアを作っていくことが重要だとされています。 DevSecOps を聞いたときは、Securityテストとかも自動化した方が良いなぁなど、テストを自動化することくらいしか、Actionを起こせていませんでした。 しかし、 SBOM の存在を知り、ぜひ自分達でも取り組んでみたいと思い、調べたので残しておこうと思います。
SBOMとは？（概要）
Software Bill of Materials (ソフトウェア部品表) は、ソフトウェアの一部に含まれるコンポーネントのリストです。 ソフトウェアを構築する際に、ほとんどの場合、 OSSおよび商用ソフトウェア コンポーネントを組み立てることになります。 このときに、コンポーネント同士の依存関係や利用しているコンポーネントを把握するのは非常に困難になります。 SBOM を利用することで、コンポーネント同士の依存関係を素早く把握できたり、コンポーネントが最新の状態であることを確認し、新しい脆弱性に迅速に対応できるようになります。
SBOM に含まれるもの
SBOMがソフトウェア部品表だとわかったけど、実際にはどんなものが含まれているのか？具体的には以下の通りです。
- Supplier Name（サプライヤー名）
- Component Name（コンポーネント名）
- Version of the Component（コンポーネントのバージョン）
- Other Unique Identifiers（その他の固有識別子）
- Dependency Relationship（依存関係）
- Author of SBOM Data（SBOMデータの作成者）
- Timestamp（タイムスタンプ）
SBOMのフォーマット
上記で述べているSBOMの記載情報ですが、これらを記載するにあたっていくつかのフォーマットが存在するようです。
Software Package Data Exchange (SPDX)
Linux Foundationが運営するプロジェクトで、SBOMに記載されている情報の共有・利用方法を標準化することを目的としています。 SPDXには、コンポーネントの出所、ライセンス、セキュリティなどに関連するデータが含まれています。
なお、この仕様はISO/IEC 5962:2021 として公開され、セキュリティ、ライセンス コンプライアンス、およびその他のソフトウェア サプライチェーン成果物に関する国際オープン標準として認められています。
Microsoft、VMwareなどは、すでにSPDXを使用してポリシーやツールでソフトウェア部品表 (SBOM) 情報をやりとりし、グローバル ソフトウェア サプライチェーン全体でSPDXに準拠した安全な開発を行えるようになっているようです。
Software Identification (SWID) Tags
ソフトウェア製品の構成要素を識別するための標準化されたXMLフォーマットです。 SWIDタグには4つのタイプがあり、ソフトウェア開発ライフサイクル（SDLC）の異なるポイントで使用されます。
- Corpus Tags
インストール前の状態のソフトウェアコンポーネント（プレインストールソフトウェア）を識別し説明するためのタグです。
- Primary Tags
インストール後のソフトウェア製品を識別し説明するためのタグです。
- Patch Tags
パッチを識別し説明するためのタグです。さらにパッチタグには、他の製品やパッチとの関係についての関連情報を含めることができます。
- Supplemental Tags
SWIDフォーマットでは、タグ作成者のみがコーパスタグ、プライマリータグ、パッチタグを修正することができます。補足タグは、ソフトウェアユーザーやソフトウェア管理ツールに、ライセンスキーなど、関連情報を追加する機能を提供します。
CycloneDX
OWASPコミュニティに起源を持つCycloneDXコアワーキンググループによって アプリケーションのセキュリティコンテキストとサプライチェーンコンポーネント分析での使用のために設計された軽量のソフトウェア部品表(SBOM)規格です。 アプリケーションを構成するソフトウェアコンポーネントに関する重要な情報を提供することで、SPDXやSWIDなどのSBOMフォーマットと同様の目的を達成することを目的としています。
SBOM Example
今回は Nodejs のプロジェクトから CycloneDX形式のSBOMを作成する方法を見つけたので、試しに出してみようと思います。 github.com
適当なNodejsのプロジェクトにCycloneDXのモジュールをインストールします。
$ npm install -g @cyclonedx/bom
ヘルプを表示すると詳細な使い方がわかります。
$ cyclonedx-node -h Usage: cyclonedx-node [options] [path] Creates CycloneDX Software Bill of Materials (SBOM) from Node.js projects Arguments: path Path to analyze Options: -v, --version output the version number -d, --include-dev Include devDependencies (default: false) -l, --include-license-text Include full license text (default: false) -o, --output <output> Write BOM to file (default: "bom.xml") -t, --type <type> Project type (default: "library") -ns, --no-serial-number Do not include BOM serial number -h, --help display help for command
今回はSBOMを json形式で出力してみます。
$ cyclonedx-node -o bom.json
bom.jsonが出力され、中身を確認すると BOMのメタ情報の部分が作成されました。
今回はサンプルにしたアプリケーションの Dependenciesがなかったため、components部分は空になっていますが
アプリによっては表示されるようです。
{ "bomFormat": "CycloneDX", "specVersion": "1.3", "serialNumber": "urn:uuid:6d9779f3-30dc-4b43-99f9-3d1cc02f2585", "version": 1, "metadata": { "timestamp": "2022-03-07T09:47:42.247Z", "tools": [ { "vendor": "CycloneDX", "name": "Node.js module", "version": "3.5.0" } ], "component": { "type": "library", "bom-ref": "pkg:npm/example-contentful-theExampleApp-js@0.0.0", "name": "example-contentful-theExampleApp-js", "version": "0.0.0", "description": "[](https://circleci.com/gh/contentful/the-example-app.nodejs)", "purl": "pkg:npm/example-contentful-theExampleApp-js@0.0.0" } }, "components": [] }
SBOM の活用事例
調べてみると非常に便利そうではあるのですが、実際に活用事例も見つかりました。 国内外で活用されているようで、幾つかリンクを載せておきます。
経済産業省の取組み
米国のNTIAにおけるNTIA Software Component Transparencyの取組み
今後やること
今回はSBOM の概念と簡単なツールを使って作成してみました。 この他にも、さまざまなツールもあるようなので、システムの品質を高めるためにも有用なものだと感じます。 特にCLIで実行できるパターンは CIなどに組み込んで自動化に組み込んでいこうと思います。
参考情報
デブサミでSBOMに出会った発表 speakerdeck.com
