VIA EMAIL: SBOM_RFC@ntia.gov
Attn: Evelyn L. Remaley
Acting NTIA Administrator
National Telecommunications and Information Administration
U.S. Department of Commerce
1401 Constitution Avenue NW,
Washington, DC 20230
The Cybersecurity Coalition (“Coalition”) submits this paper in response to the National Telecommunications and Information Administration’s Request for Information on “Software Bill of Materials and Considerations,” posted on June 2, 2021.
The Coalition is composed of leading companies with a specialty in cybersecurity products and services, who are dedicated to finding and advancing consensus policy solutions that promote the development and adoption of cybersecurity technologies. We seek to ensure a robust marketplace and effective policy environment that will encourage companies of all sizes to take steps to improve cybersecurity risk management.
As we begin our comments, it is important to recognize SBOMs are not commonplace today in the vast majority of delivered software. SBOM development is very much a work in progress. There are no specifications defining the business and operational rules of an SBOM. Government agencies are discussing and considering requiring SBOMs as if they are real and exist today. In fact, the definition of SBOM found in Section 10 of the EO is not a real-world definition of on-the-market-today solutions beyond research, proof-of-concept, and demonstration projects.
(j) the term “Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software. Software developers and vendors often create products by assembling existing open source and commercial software components. The SBOM enumerates these components in a product. It is analogous to a list of ingredients on food packaging. An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software. Developers often use available open source and third-party software components to create a product; an SBOM allows the builder to make sure those components are up to date and to respond quickly to new vulnerabilities. Buyers can use an SBOM to perform vulnerability or license analysis, both of which can be used to evaluate risk in a product. Those who operate software can use SBOMs to quickly and easily determine whether they are at potential risk of a newly discovered vulnerability. A widely used, machine-readable SBOM format allows for greater benefits through automation and tool integration. The SBOMs gain greater value when collectively stored in a repository that can be easily queried by other applications and systems. Understanding the supply chain of software, obtaining an SBOM, and using it to analyze known vulnerabilities are crucial in managing risk.
The SBOM definition in this section of the EO is aspirational. That said, we believe this vision is the direction for the software industry should take, in the critical context of promoting secure software supply change management practices more broadly. We are highly supportive of SBOMs in general. There is, however, still a great deal of work required to define and document what SBOMs are and to make SBOMs prevalent within commercial software. The U.S. Government should not be considering requiring vendors to produce something before real specifications are documented, as to what is required, how they work for specific use cases, and generally understood by government, those required to provide them, and those that would use them on the customer side.
The Coalition believes SBOMs can provide the solid foundational capability for critical future software supply chain functionality to address asset management, vulnerability, and software naming issues, at a minimum. There are many potential use cases that could benefit from software information published in an SBOM. They include:
These use cases could all benefit from an SBOM. However, much work remains to develop a cohesive, practical, and widely accepted approach (much less a specific implementation). As such, we strongly urge NTIA to keep its recommended minimum requirements simple.
One of the extremely hard challenges the software industry has been trying to address is around product naming. Software creators/publishers/vendors have multiple ways to name their software. They create product names for families of software, they create individual product names, and they create different naming for marketing purposes. Sometimes version information further complicates product naming. Often a product is known in the market by three or four “common” names. Combine that with the varying ways that product versioning is done across the market, and we have a significant challenge stemming from how to definitively denote which assemblage of software is being referred to at any given date and time.
Efforts around producing consistent naming for software products have produced solid standards for syntax and usage. The assumption with those standards was that vendors would use them to name their products. It was hoped that vendors would supply “official” names for their products that industry could use and recognize. This has never happened in a universal way valuable to the marketplace. The NIST Common Platform Enumeration (CPE) was seen as the way forward at one point in hopes of solving the naming problem. What NIST and industry discovered was without software vendors supplying their official product names, we still had the same problem. It is critical that the responsibility for proper product naming rests in the hands of the vendors. Only they can designate an “official” product name.
The product name specified in SBOM files must be understood moving forward as being the “official” name for the product the SBOM file is associated with. Using SBOM files to allow the producing organization to define this for industry-wide usage is vital to properly addressing the product naming issue. If SBOMs are widely adopted, and the SBOM files are generated as an automatic part of the build process, this would allow vendors to indicate an official name without having to specify it “out-of-band” as was required by efforts such as CPE. This becomes just an artifact of the SBOM generation at build time. We believe this is the proper way to address the naming issue and do so as a natural outcome of the use of SBOMs.
Additionally, names are not permanent. Acquisitions of companies and corporate carve-outs can cause products to be renamed. It would be useful to have an optional data field for those products that have had their name officially change. An “alias” or similar field could be specified so as to allow the previous official name to be recognized for use in inventory, vulnerability or procurement use cases.
The use of software bill of materials should be focused on what a traditional Bill of Materials has been in the past. It is a description of an “as built” delivery of the package. In this case the package is software. Construction of software today quite often incorporates third-party open-source projects and its related components into the proprietary software package. Transparency is important for emerging procurement requirements and providing the means for network staff to be able to quickly identify vulnerable software that needs to be updated or mitigated. Being able to see what third party components are included in software provides the ability for the customer community to be able to know the true security posture of their deployed software.
The Depth discussion and subsequent question in the RFC violate the keep it simple approach. Tracking all dependencies for the sake of tracking all dependencies at all levels should not be included in each and every SBOM. Product SBOMs should indicate the third-party component(s) incorporated into the product. There is no real value to the producer or purchaser to clutter up an SBOM with massive amounts of information that is not relevant to the specificity of what is a direct part of the product. It will rarely be completely possible to accurately list every single dependency at all levels for every open-source project all the time. If this is required, every SBOM will have a statement “Known unknowns” in the SBOM. Dependency information could be provided on request of the product vendor or third-party commercial or open-source project if there is a need to see all the dependencies of dependencies at all levels. Otherwise, the only thing this accomplishes is to make the SBOM files nearly unreadable and massive in size. Many commercial products use the same open-source projects. How many sets of “openssl” dependencies should one network have to be burdened with? This type of dependency information should be stored once on a network to be queried if desired. It should not be incorporated directly into every single product SBOM for every product the organization owns and uses. Additionally, requiring this type of massive dependency information in an SBOM, makes automatic SBOM creation during the build process highly problematic. This type of requirement is better suited for additional tooling, not an SBOM.
SBOMs harbor a real change for the software industry. These are not something the industry has provided with software in the past. Anytime you introduce something new that causes a great deal of change to how companies produce their products, it can take a bit for a real understanding of what is needed and what needs to change to make that change successful. For that reason, we request NTIA to not try and solve the entire software supply chain issues in a SBOM and confine its guidelines for the purpose of the EO to the minimal data fields suggested for the SBOM, while leaving other key questions of delivery, SBOM communication and the like, for further discussion and standardization efforts. Questions in the RFC seem to indicate NTIA staff are considering such a path. For example:
e. Threat model: While many anticipated use cases may rely on the SBOM as an authoritative reference when evaluating external information (such as vulnerability reports), other use cases may rely on the SBOM as a foundation in detecting more sophisticated supply chain attacks. These attacks could include compromising the integrity of not only the systems used to build the software component, but also the systems used to create the SBOM or even the SBOM itself. How can SBOM position itself to support the detection of internal compromise? How can these more advanced data collection and management efforts best be integrated into the basic SBOM structure? What further costs and complexities would this impose?
SBOM's are NOT a security assurance in and of themselves. They are an information source describing the software as built with some additional meta-data.
We urge NTIA to keep its approach to SBOMs simple. Trying to do too much, too quickly with potential regulations requiring immediate change is a recipe for disaster. Not all companies creating software are big companies. Many software vendors are small companies and as such are constrained by resources and staff. The costs that these changes are leveraging on the product development community could have unintended consequences. Starting in a focused manner and evolving as use cases and needs become apparent will have more of a chance for successfully changing the overall software development environment.
We strongly agree with NTIA, as stated in the RFC, that SBOMs can ride on ‘existing mechanisms’ and such delivery can ‘reflect the nature of the software as well’.
The Coalition believes that work on defining, and documenting SBOMs in support of specific use cases must continue. There is a real need for documented practices and standards to be developed in order to properly define SBOMs. This is vital work if the overall longer-term goal is to mature secure software supply chain practices. But note, an SBOM will not solve the issue of software supply chain by itself. It is just one piece of the puzzle, a valuable one, but simply a piece. Keeping SBOM development focused on agreed to use cases will allow it to become more useful in less time.
The Coalition thanks the NTIA for allowing us to contribute our thoughts and recommendations to the dialog. As the conversation around this topic continues to evolve, we would welcome the opportunity to further serve as a resource on both technical and policy questions to ensure that SBOM incorporation into the software development industry is successful in driving consistent, effective cyber risk management practices.
The Cybersecurity Coalition