オープンソース製品とソフトウェア部品表

Between eighty and ninety percent (80%-90%) of a modern application is assembled from open source software components. An SBOM accounts for the software components contained in an application — open source, proprietary, or third-party — and details their provenance, license, and security attributes. SBOMs are used as a part of a foundational practice to track and trace components across software supply chains. SBOMs also help to proactively identify software issues and risks and establish a starting point for their remediation.

Importantly, the culprit was not the developers of the code but the company that failed to implement a patch that promised to prevent the very thing that happened. Many observers complain that Equifax has suffered little consequence for its negligence, highlighting weak oversight and accountability structures.

これに対し、最近では連邦取引委員会が Log4Shell の対応パッチの適用が遅い企業を強制措置をかますなど、政府がオープンソースのセキュリティ問題に介入する姿勢を見せつつある。著者はその一環としての SBOM（Software Bill Of Materials：ソフトウェア部品表）を評価するが、それだけでは不十分と断じる。

An SBOM is simply a list of the ingredients, or codebases, that comprise software you purchased. It does not provide a list of vulnerabilities nor does it impose any minimum security requirements on the vendor generating the SBOM. Comparable to a list of ingredients on a snack or medication you purchase, the information is only as useful as your ability to parse it.

To operationalize an SBOM, a company must be able to read it, which is a challenge as there is no mandated standard format for an SBOM, and actually use it to check databases such as the National Vulnerability Database (NVD) for new vulnerabilities found in the software components the SBOM lists. These activities are costly and cumbersome. While Google and Intel might have the resources and security maturity to demand machine-readable SBOMs and regularly scan databases for new vulnerabilities that impact their systems, there are countless small businesses using open source that cannot.

著者は、もはや公共財の性質を持つオープンソースを維持する制度的構造を構築する必要があると訴える。そして、それ自体は目新しい主張ではない。それには効率的な資源配分を確保し、最低基準を課すことが必要になるが、果たしてそれをオープンソースプロジェクトに適用するのはうまくいくかねというのがワタシの感想になる。

Snyk integrates with a wide range of different package managers and developer tools to help identify vulnerabilities in the software components used. In doing that we need to build up a SBOM under the hood, normalising the list of software and augmenting that list with additional metadata from other sources. The Snyk tooling mainly focuses on presenting that information alongside information about vulnerabilities, but Snyk customers can access that raw SBOM via our built-in reporting or powerful API.

In fact, you can think of Snyk client tools like the CLI and CI/CD plugins as generating an SBOM, while Snyk’s backend takes an SBOM and returns vulnerability data, or provides automation around that data to help you fix issues. It’s this extensive experience that leads to our interest in emerging standards in this space.

具体的には、ソフトウェア名やライセンス、作成者、バージョン、個々のファイルのハッシュ値などの情報を、SBOMのフォーマットとしての標準の1つである「SPDX」（Software Package Data Exchange）形式で出力してくれます。

また、ビルドの対象となるソフトウェアにSBOMが用意されている場合、新たに生成されるSBOMにはそのSBOMの情報をきちんととりまとめて生成することが可能。