Building the Software Bill of Materials, or “SBOM” — alongside the software itself — is a good practice for monitoring zero-day vulnerabilities or meeting regulatory and compliance needs.

‍SBOM is also ready for the software transparency requirements emerging in well-regulated areas such as Financial, Healthcare, and Federal Agencies.

‍Commercial and open-source tools exist for building SBOM for software projects in most software ecosystems and from application binaries and firmware.

‍However, a typical commercially available software product or connected device is built as a collection of software and hardware projects assembled from multiple hardware components, libraries, services, or even the direct distribution of executables.

‍

For examples:

• A mobile App includes third-party libraries for marketing, authentication, or advertising purposes — all from third-party vendors.

• A medical device might include programmable components from various vendors, each with its own versions and upgrade cycles.

• A desktop application can with some third-party executables that it calls into for specific functionalities.

In these cases, SBOM for projects and libraries can be built with the project but combining them into the final product SBOM requires a deeper understanding of SBOM formats and limitations.

Building a final product SBOM by combining the project SBOM solves several problems, including:

• Delivering a single product SBOM instead of many project SBOM

• Tracking product version against specific project versions

• Tracking the final product with a single SKU in SBOM management systems

• Mapping newly disclosed vulnerabilities to specific projects