はじめに
こんりな！Linux系Vtuberの熊ケ谷リナです！
年末進行で動画を作る余裕も無いので静止画で失礼します。
今回はITシステム全体でSBOMをどう運用したら良いかを考えてみたいと思います。
SBOMって実はたくさん種類がある？
SBOMは製造から運用まで、使用されたポーネントを集約することで、意図しないOSSライセンス違反や脆弱性リスク分析などのトレーサビリティを確保することに意義があります。
しかし、実際のソフトウェア開発では1つのソフトウェアが出来上がるまでに大量のソフトウェアコンポーネント利用されており、開発用のライブラリやパッケージなどおいては最終的な提供物には含まれないことも多く、ある特定のタイミング(たとえばシステム構築時とか)にSBOMを用意しようとするとSBOMのトレーサビリティを著しく損なう可能性があります。
NTIAのSoftware Suppliers Playbooでもpre-build SBOMやsource SBOMといった表現で開発サイクルの中で都度、(CI/CDなどと連動して)SBOMを生成することに言及しています。
これは単一製品の、統合された開発環境であればある程度は実現可能でしょう。しかしITシステムは自社開発、他者開発、OSSが入り乱れる環境が複数組み合わさって存在しており、全てに同様のプロセスを適用することは難しく感じます。
ITシステム全体でSBOMをどう考えるべきか。参考になりそうな考え方として、OWASPが推進するCyclone DXが公開しているCycloneDX BOM ExamplesではSBOMを5種類に分割して表現しています。
| 分類 | 概要 |
|---|---|
| HBOM(Hardware Bill of Materials) | スイッチやサーバーなど物理コンポーネントのBOM |
| OBOM(Operations Bill of Materials) | 運用上頻繁に更新されるコンポーネント(OSやミドルウェアなど)のBOM |
| SaaSBOM(Software-as-a-Service Bill of Materials) | AWSなどのSaas上に存在するコンポーネントのBOM |
| SBOM(Software Bill of Materials) | 自社/外部が開発、提供するソフトウェアコンポーネントのBOM |
| VEX | コンポーネントが脆弱性の影響をどれだけ受けるか紐づける拡張情報 |
同じSBOMといえど、ITシステムに含まれるコンポーネントはそれぞれの性質によってSBOMに記載される内容も変わってきます。それぞれの機能や性質に応じてどのようなSBOMが必要なのか、どのように生成・更新していけば実際の運用に落とし込めるかのヒントになりそうです。
SBOMで表現したい種類と、レベル感を定義すると幸せになれる？
たとえば、Pythonなどでプリケーションを開発しそれをウェブサービスとして提供するようなシステムを運用する場合。
フロントエンドのアプリケーション本体(Pythonのコードやパッケージ、モジュール)は開発の段階でSBOM生成や外部から提供されるSBOMの仕様を厳密に定義し、意図しないライセンス違反の予防や脆弱性が発覚した時の対応を迅速に実施できるように完全性、トレーサビリティを高めた運用を目指す。一方でバックエンドで稼働するLinux OSやミドルウェアでは日々の運用業務などで発生するマイナーバージョン以下の細かなパッケージアップデートをSBOMを追従させることを重視し、ライセンス情報など多少の情報に漏れがあっても、場合によっては許容するなど、ある種の線引も必要になるのかなとは思います。(もちろん、システム全体でトレーサビリティを高めることは重要ですし、使い物にならないSBOMが大量に発生しないように注意は必要ですが)
試しに、同じAdvent Calendarの@ykmchdさんの記事で紹介されているsyftを使って(私がよく触るディストリである)MIRACLE LINUXにインストールされている全RPMパッケージのspdxを生成してみました。
##### Package: NetworkManager
PackageName: NetworkManager
SPDXID: SPDXRef-Package-rpm-NetworkManager-b40cd84196ed6e6b
PackageVersion: 1:1.36.0-5.el9.ML.1
PackageOriginator: Organization: MIRACLE LINUX powerd by Cybertrust Japan
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
PackageSourceInfo: acquired package info from RPM DB: rpmdb.sqlite
PackageLicenseConcluded: NOASSERTION
PackageLicenseDeclared: NOASSERTION
PackageCopyrightText: NOASSERTION
ExternalRef: SECURITY cpe23Type cpe:2.3:a:miraclelinuxpowerdbycybertrustjapan:NetworkManager:1\:1.36.0-5.el9.ML.1:*:*:*:*:*:*:*
ExternalRef: SECURITY cpe23Type cpe:2.3:a:NetworkManager:NetworkManager:1\:1.36.0-5.el9.ML.1:*:*:*:*:*:*:*
ExternalRef: PACKAGE-MANAGER purl pkg:rpm/NetworkManager@1.36.0-5.el9.ML.1?arch=x86_64&epoch=1&upstream=NetworkManager-1.36.0-5.el9.ML.1.src.rpm
PackageOriginator や PackageVersion、ExternalRefにもCPE、Package URLが記載されいるのでパッケージの調査など運用上のパッケージ管理には使えそうな内容です。不足している情報はたしかにありますが、コマンド1発で全RPMパッケージのSBOMが生成できるので運用にかかる負荷は低そうです。
終わりに
現状ではITシステム全体をSBOMで定義する具体例も少なく手探りの状況ですが、どのレイヤをSBOMで記述するのか、実際の運用ではSBOMを使ってなにがしたいのかを予めしっかりと検討しておくことが重要になるのは間違いないでしょう。
ただ、実際には様々な種類のSBOMを破綻させずに管理するのか (gitなどでバージョン管理や、SPDX-Liteなどのシンプルなフォーマットで、SBOMのSBOMを作るなど現状でもやり方はありそう) 問題や 名寄せ問題などコンポーネントの一意性をどう確保するかなど課題は山積みですが、SBOMへの関心と活用が広がって行く中で、おのずとITシステムにおけるSBOMのベストプラクティスも見えてくるかと思います。本記事の内容が少しでも SBOM でお悩みの方の参考になればうれしいです。
summary
SBOM is significant in that it aggregates all the used components from production to operation to ensure traceability for unintentional OSS license violations and vulnerability risk analysis.
However, in actual software development, a large number of software components are used before a single software product is created, and development libraries and packages are often not included in the final product. Generating SBOMs only at certain times can seriously compromise the traceability of SBOMs.
NTIA's Software Suppliers Playboo also mentions generating SBOM (in conjunction with CI/CD, etc.) at each stage of the development cycle, using expressions such as pre-build SBOM and source SBOM. However, it is not realistic to apply this method to all IT systems, which are not limited to single product builds, but also include multiple mixed environments of Linux and OSS.
The CycloneDX BOM Examples published by Cyclone DX, promoted by OWASP, may be helpful in classifying SBOMs.
・HBOM(Hardware Bill of Materials)
・OBOM(Operations Bill of Materials)
・SaaSBOM(Software-as-a-Service Bill of Materials)
・SBOM(Software Bill of Materials)
・VEX
Defining requirements for SBOM by purpose may be effective for current operations, even though the integrity of SBOM may be compromised.
At the very least, it is important to carefully consider what is required of SBOM at which layer.