SBOM Advice to Software Vendors: Keep it simple

Anyone that is reading the “bare specs” covering SBOM formats could be easily lead down a path to over engineering their SBOMs to the point where a consumer will be unable to reap the real benefits that can be achieved and the vendor will become frustrated trying to get their SBOMs right. Here is my advice to software vendors that will keep them from over engineering their SBOM’s and save time, money and frustrations in the implementation of SBOM, while delivering SBOMs that customers will find useful.

These axioms are germane to SBOMs that are used by software customers to perform software integrity verification checks for NERC CIP-010 and NIST CSF C-SCRM risk assessments on a software package before installation, to satisfy Executive Order 14028 and H.R. 4611 requirements.

1. If you are new to SBOM, read this two-page introduction to SBOM from NTIA
2. Decide on an NTIA supported SBOM format for your SBOM. SPDX and CycloneDX are the most popular choices. Then decide on the particular representation you wish to produce, i.e. TagValue is the most popular for SPDX and XML is the most popular for CycloneDX. JSON is supported by both SBOM formats.  I’ve used both SPDX and CycloneDX and find they are both easy to use and have vibrant, responsive community support. Pick one or pick both, you can’t go wrong.
3. Limit your SBOM content to the NTIA list of 7 minimum elements and any other required elements needed to construct a valid SBOM, based on the format chosen, SPDX or CycloneDX
4. Create your SBOM components list based on the final software installation package that will be delivered to customers. Don’t bother creating an SBOM for a source code tree, this won’t help your customer perform an effective risk assessment, which largely depends on NIST NVD search results at the compiled/delivered binary component file name and version number.
5. Follow the NTIA Framing Group recommendation to use the “primary component” as the means to identify the “Product Name”. The primary component is the first component to appear in an SBOM.
6. If you are unable to provide data for an NTIA minimum element or other required element, you must include the minimum element in your SBOM and set the value to NOASSERTION
7. There are ample tools available to construct and consume SBOMs in SPDX and CycloneDX format; these tools are the most efficient method to build/consume and maintain SBOMs
8. It may be difficult to produce an SBOM for some legacy applications using the modern SBOM tools that are available. In this case, create a single directory and place all of your compiled components from a software installation package into this single directory, ensuring that the primary component appears first in the list. Now zip up this folder and run the zip file through a tool that can generate SBOM’s from zip files, which you can deliver to customers. This is not a replacement for SBOM generation as part of a modern SDLC process, but it will produce a valid SBOM that can be used in a NIST C-SCRM risk assessment.
9. Validate your SBOM using available tools for SPDX and CycloneDX, before sending to a customer. Address any identified issues until receiving a successful validation
10. Digitally sign your valid SBOM
11. Produce a Vulnerability Disclosure Report (VDR) that lists the NIST NVD search results for each component listed in your SBOM. An open-source, free to use Vulnerability Disclosure Report XML schema format is available online.
12. Digitally sign your VDR
13. Make your SBOM and VDR downloadable from an access-controlled customer accessible portal to prevent unauthorized access
14. Provide customers with the information needed to download the SBOM and VDR files; an open-source, free to use, Vendor Response File (VRF) XML schema format is available for this purpose; a sample VRF is available here, which should be downloadable by customers from a software vendors, access-controlled website. Vendors need to provide customers with the download locations for all three artifacts: SBOM, VRF and VDR
15. Keep your SBOM and VDR files up to date; VDR files can change more frequently than an SBOM file due to the discovery of new vulnerabilities on already delivered software components.
16. Stay in the loop on SBOM by following Allan Friedman on Twitter @allanfriedman

Beware, there are people claiming SBOM to be immature or too complicated. Neither is true; follow the guidance above and engage with the SBOM community of your choice, SPDX or CycloneDX and you’ll see that SBOM is indeed available to use now. Hope you find this guidance useful and will help make your SBOM experience more pleasant and successful.