top of page

Software Bill of Materials: Build Trust Through Transparency


What is a SBOM?

A Software Bill of Materials (SBOM) is a formal and machine-readable comprehensive inventory of components, libraries, and dependencies used to create a software application. A well defined SBOM includes both the supplier / manufacturer developed components and third-party components (including purchased software and open-source software), and the upstream software dependencies that are required/depended upon by proprietary, purchased, and open-source software.

A SBOM helps facilitate risk management processes by providing a mechanism to identify software and devices that might be affected by vulnerabilities in the software components, both during development and after it has been deployed.


It includes information on origin, versions, licenses, and other attributes and is a key transparency component in securing the software supply chain.


SBOM benefits for software and device suppliers

  1. Regulatory Compliance: As an example, FDA recommends that premarket submissions include SBOM documentation. Executive Order 14028 is mandating SBOMs for software being sold to the US Government.

  2. Visibility: Easier for developers to understand dependencies across components and deliverables.

  3. Easier to monitor for vulnerabilities: Reduces detection and remediation time. This means quicker response to zero-day vulnerabilities.

  4. Decrease license compliance risk: Manage software licensing (including constraints on use) for included components.

  5. Mitigate component risk: EOL implications, Build “Reject” / “Allow” list of components.

  6. Facilitates open source software usage: Reduce anxiety about using OSS, Increase speed of development, decrease risk.

SBOM benefits for software and device consumers

  1. Addresses reporting and compliance requirements

  2. Risk based decision making

  3. Quicker identification and mitigation to zero-day vulnerabilities

  4. High Assurance: Understand provenance of software components


20 Questions to consider as you build your Software Bill of Materials initiative:


Design

  1. What is the driver of your SBOM program as a software producer?

  2. Baseline inventory of your software dependencies

  3. Customer requirement

  4. Validation of software integrity

  5. Regulatory compliance

  6. License compliance

  7. Vulnerability monitoring and management

  8. All of the above (recommended)

  9. What is the driver of your SBOM program as a software consumer?

  10. Check for “SBOM drift” – Unexpected changes in the contents due to malware

  11. Legal and license compliance

  12. Security analysis

  13. Policy compliance

  14. Customer requirements

  15. Regulatory compliance

  16. When do you generate your SBOM as a producer?

  17. During Build (recommended)

  18. After build process using binary analysis

  19. Not sure

  20. What is the format of your SBOM?

  21. SPDX (most common)

  22. CycloneDX

  23. SWID

  24. Text file

Create

  1. Do you produce SBOM for each product identifying component dependencies?

  2. Yes, for all (recommended)

  3. Only for on-premise software

  4. Only for on-premise and cloud based software

  5. Have not determined the product type scope for SBOM generation process

  6. What dependencies are included as part of the SBOM creation?

  7. Direct dependencies only

  8. Transitive dependencies (recommended)

  9. What is the included as part of your SBOM generation process?

  10. Libraries

  11. Frameworks

  12. Third party components

  13. All of the above (recommended)

  14. Is your SBOM compliant with NTIA minimal requirements for data to be included in the SBOM? (The requirements are higher for FDA pre-market approvals)

  15. Yes (NTIA requirements)

  16. No

  17. Not sure

  18. Do you request SBOMs from suppliers or generate it yourself?

  19. Generate it internally

  20. Request from supplier

  21. Do both (recommended)

  22. Neither

  23. Is SBOM generated automatically as part of your DevOps toolchain?

  24. Yes (preferable)

  25. No

  26. Possibly in the future

  27. How do you validate that SBOM is complete?

  28. Which tool do you use to generate the SBOM as part of the build process?

  29. Microsoft

  30. CycloneDX Maven Plugin

  31. Kubernetes BOM

  32. SPDX SBOM

  33. Syft

  34. Other

  35. Don’t generate SBOM as part of build process.

  36. Which tool do you use to generate the SBOM as part of the post build process?

  37. Synopsys BlackDuck

  38. Jfrog Xray

  39. Snyk

  40. Contrast

  41. FOSSA

  42. MergeBase

  43. other

Manage

  1. Do you have a central repository to manage and store all SBOMs (supplier, internal and externally delivered) across your organization for visibility and compliance purposes?

  2. Yes

  3. No

  4. In process of building

  5. Possibly in the future

  6. What resource do you use to map SBOM components to known vulnerabilities?

  7. Open Source Vulnerability (OSV) database

  8. Github advisory database

  9. NVD

  10. Are you hesitant to share SBOM with your customers due to proprietary information concerns?

  11. Yes

  12. No (industry resistance is declining)

  13. Not sure, still evaluating

  14. Do you generate SBOMs for each build and compare for differences to identify possible tampering?

  15. Yes (Recommended for Malware detection)

  16. No

  17. Possibly in the future

  18. Which tool do you use to consume the SBOMs from your suppliers?

  19. Cybeats

  20. Rezilion

  21. Anchore

  22. How do you securely deliver your SBOMs?

  23. Signed SBOMs (recommended)

  24. Use a decentralized service like SCITT or OSF?

  25. Email

  26. Not sure

Customer Transparency

  1. Do you include exploitable vulnerability information with your SBOM?

  2. Include VEX file (in early stage of adoption)

  3. No

  4. Sometimes


bottom of page