Perhaps the most apt way to describe the recent publication from the U.S. Department of Commerce (NTIA) on the guidelines for the minimum elements for a Software Bill of Materials (SBOM) is to say that there really aren’t many surprises in it.
The NTIA guidance primarily directs software vendors to ensure that – whatever format they’re using for their SBOM – the output needs to be machine readable so that it can be fed into a much larger database. This standardization of format may prove to be a technical challenge. For a variety of reasons (which we outline below), it will likely be very difficult to create one (or even several) standards for the entire universe of software.
We can begin with an overview of the guidelines themselves.
Technical summary of the NTIA Minimum Elements For an SBOM:
- SBOMs must show, for each software component: supplier, component name, version, any unique identifiers like CPE SWID or PURL, dependency relationship, and the author of this information along with a time/date stamp when it was generated
- The guidance also recommends that the SBOM have: a hash, LifeCycle phase (which is when the SBOM was built (i.e., pre-build, build, or post-build), license Information, and Other Component Relationship which is intended for non-dependencies but that have a relationship. (Their example of another component relationship is a component that is ‘derived from’ another component.)
- SBOMs must support automatic generation and machine-readability
- SBOMs MUST be generated every build/release, INCLUDING a simple update for a component or dependency.
- SBOMs need to show, at minimum, all top-level components and their immediate transitive dependencies. This includes the primary level and one level down. Note this must show the relationship per the first bullet. Note that they pretty strongly recommend going deeper, however this is the minimum
- If there are no dependencies, the SBOM must state “no dependencies” (rather than just leaving this condition blank/unknown).
Some noteworthy particulars on the recommended implementation of SBOMs:
The biggest departure from previous SBOM guidelines is that you not only have to produce an SBOM, but that SBOM must be accessible.
“SBOMs that live on endpoints can store the SBOM data on disk with the compiled code, whereas embedded systems or online services can have pointers to SBOM data stored online.”
Closely following accessibility is access control. Vendors, usually in license or contract terms, will have to specify who can access the SBOM data and how they can do so. SBOMs access control and method of access:
” … must be specified, including specific allowances and accommodations for integrating SBOM data into the user’s security tools.”
Interestingly, the guidance pulls up just shy of requiring digital signatures. In fact, they’re so highly suggested that we’re not sure why isn’t not required at this point. We think they are very likely to be required not too far down the road.
“Those supplying and requesting SBOMs are encouraged to explore options to both sign SBOMs and verify tamper-detection. Such a mechanism should allow the signing of each component of a given piece of software and allow the user to determine whether the signature is legitimate. Integrity and authenticity are a priority for many government agencies, especially in the national security domain. Some users of SBOM data may insist on requiring digital signatures for SBOMs today.”
The guidance also strongly encourages a “Vulnerability Exploitability eXchange,” or VEX. In the future, we might also see this as a requirement, perhaps on a case-by-case basis down.
“This is straightforward, linking of a piece of software (the vulnerability in question) and the status of that vulnerability.”
The challenges of standardizing SBOM format
In order to make SBOM formats accessible and machine readable, the formats must be standardized. The first (and perhaps most obvious) challenge in doing this is that the seemingly simple act of creating an SBOM is actually a difficult thing to do. There are many ways to create an SBOM, and the minimum components listed by the NTIA are just that: minimums. In all likelihood, vendors will have to go above and beyond the requirements listed when selling to certain departments or agencies within the Federal government.
Fortunately, in terms of formatting, NTIA lists the three major interoperable SBOM formats currently in use (SPDX, CycloneDX, and SWID) as examples. That being said, anyone who is delivering SBOMs will either have to pick one or support all three—and each format has its own quirks and challenges.
Finally, it may be obvious, but if you are a vendor who ships devices or firmware, you should make sure that your SBOM includes all of the software components that you’re shipping. Firmware images themselves contain operating systems, drivers, etc., in addition to code. So if you’re shipping all of those components as a package, your SBOM should include all of those components.
A big unknown: verification of testing
There is one key open question that NTIA still needs to address with respect to the SBOM: verification and validation of testing. Procurement officers need to have some way of verifying that testing required has not only been done, but done effectively. This presents a huge challenge: how will testing be validated and by what standard?
We could see this happening one of three ways:
First, NTIA could follow in the footsteps of the Department of Defense’s Cybersecurity Maturity Model Certification (CMMC). In order to be certified under the CMMC, a defense contractor must have its security systems reviewed by an independent third party that has been accredited to conduct the certifications. While this seems to be a reasonable process in theory, in practice it has proven to be a far more arduous task than anticipated. Thus far, only one entity has been accredited to conduct certifications, and there are approximately 300,000 organizations vying for certification.
A second option would be to outline a series of requirements that everyone can measure against. But again, that comes with its own set of difficulties:
Even if you think you have met the requirements, how do you verify that you have captured everything in your SBOM? What do you compare it against? You can either manually test (which is labor intensive, inefficient, and requires specialized skills) or you can use specific tooling. In the latter case, both the SBOM and the tooling used to create the SBOM would need to be verified/certified by both the organization producing the SBOM and the organization receiving the SBOM. This would need to be done via select manual testing.
A third option would require an independent third party that can verify the SBOM and provide assurance to both the organization producing the SBOM as well the organization receiving it.
Final takeaways
As you can see, while there aren’t any big surprises in what NTIA has rolled out thus far, there remain a few key details and technical challenges that need to be worked out before final requirements can be released and implemented. It’s also important to keep in mind that these recommendations are the minimum for what we expect to see for the EO’s final requirements, so we expect that some areas will have additional requirements, above and beyond what NTIA has produced thus far.
About the Authors
Finite State General Counsel Eric Greenwald previously served in the Obama White House as Special Assistant to the President, where he focused on protecting critical infrastructure as Senior Director for Cybersecurity on the National Security Council (NSC). Before his selection to the NSC, Eric was the Principal Deputy Director of the FBI’s National Cyber Investigative Joint Task Force and the Deputy Director of Operations at U.S. Cyber Command. Formerly an associate producer for CBS’s “60 Minutes” and for National Public Radio, Eric is a graduate of Yale University with a law degree from the University of Michigan Law School.
Vice President of Product Jeff Martin is an experienced product leader who spent the last decade delivering software that enabled enterprises to understand and mitigate their risks. Over his career, Martin managed products in the medical device industry before shifting his attention to product leadership within the software quality industry, where he focuses on developer-centric solutions.
