Lessons Learned during SBOM Implementation and Adoption

Since 2018 I have been working on principles and practices to improve software security and trustworthiness for critical infrastructure operations and developing software to implement best practices based on NIST Guidance. More work remains, but some valuable progress and knowledge has been gained in these 7 years. Here I share my findings and experiences with SBOM implementation and adoption and the various “messages” you will hear about SBOM.

Don't dive into the deep end of the pool, start with a small product/project with a supportive vendor that wants to see you succeed
An authoritative, valid SBOM can only come from one party, the original software producer that creates a software product
SBOMs created by a software producer may not contain perfect knowledge about each component used in a product
Software producers may use components from multiple sources which they do not control; every effort must be made to ensure the most trustworthy components are used when constructing software products, i.e. Secure by Design practices in the CISA Software Acquisition Guide
Software producers should list every component that is delivered in a "software package" that the customer receives for installation and use of a software product
People who refuse to use SBOM’s for risk management until they are “perfected” will lose the benefits that SBOM’s provide today with visibility into software risks
Some people claim that SBOM is immature implying that it’s not ready for use today; in fact there are numerous useful tools available to implement SBOM today which can assist both software producers and software consumers with risk management; SBOM has implementation traction and a vibrant community of developers, implementers and supporters with experience.
There are two well defined, mature SBOM standard formats available with a proven, mature track record today, CycloneDX and SPDX. Both standards have ample tools available and skilled people to implement these tools at both the software producer and software consumer level. JSON is the preferred format for all SBOM artifacts.
There are people that oppose SBOM and those that support SBOM speaking publicly. Be careful who you believe. The best answer is to check for yourself to see if SBOM is useful to you today.
There are mature, proven implementation guidelines available to help parties implement SBOM using tools and practices with years of experience; https://cisa.gov/sag
An SBOM containing NTIA minimum elements is sufficient for performing a NIST NVD keyword search needed to identify vulnerabilities in software. Like all NIST NVD searches a false positive result may be reported under certain circumstances
People who acquire SBOM’s from anyone other than the original software producer should not expect the SBOM to be accurate or complete or even valid. Only the original software producer can produce a valid, authoritative, trustworthy SBOM for a product.
SBOM is useful today to search for software vulnerabilities; SBOM does not need VEX to be useful
SBOM's are becoming essential artifacts to conduct a software supply chain risk assessment following best practices in the EU CRA and across US Government Agencies to identify trustworthy products which are listed in a "Trust Registry", i.e. US Coast Guard approved products list. "(1) Develop and maintain a list of approved hardware, firmware, and software that may be installed on IT or OT systems. Any hardware, firmware, and software installed on IT and OT systems must be on the owner- or operator-approved list;"
SBOM's are a defined artifact within the CISA RSAA portal used by software suppliers to submit secure software attestations and related artifacts to Government Agencies conducting supply chain risk management practices to identify trustworthy products
SBOM data is solely the domain and control of the original software producer, they decide what goes into an SBOM, making it “valid”. Consumers need to accept an authoritative SBOM as a “best case” understanding of product contents when provided by the original software producer.
The SBOM data content model could be improved by agreeing on the content model for supplier identification to uniquely identify software suppliers and SBOM Authors. The product name and version are under the control of the original software producer and must be accepted as “valid” by consumers, when the SBOM is provided by the original software producer. There is no better source of trustworthy SBOM data than the original software producer of a product.
SBOM is a relatively new technology with a defined, mature set of format standards and minimum data elements needed to create a valid SBOM used for risk assessment purposes.
SBOM, like all technologies continue to advance and improve and SBOM tool vendors need to “keep up” with changes.
Everyone needs to make their own decision about using SBOM. Just like flying, I will fly in a commercial jet liner but I won’t take flight in a hang glider. It’s a personal choice based on a risk/reward calculus.
What’s the risk with using SBOM today to monitor for software risks in your digital ecosystem?
What’s the risk with NOT using SBOM today to monitor for software risks in your digital ecosystem?
Risk always exists, but trust does not always exist. Always ask to see the product trust score before buying a product.
Decide for yourself if SBOM is sufficiently useful today for your risk/reward calculus.