May 10, 2022

Cybersecurity Coalition SBOM Position Paper


The members of the CybersecurityCoalition[1]represent several of the largest and most critical producers of software,software assurance, and security services for both the private sector and theUnited States federal government departments and agencies (USG). As such, theCoalition has a long-standing interest in standards and requirements that canimpact how software gets developed, delivered, and maintained.

This paper focuses on the current stateof Software Bill of Materials (SBOM). The Coalition wants to stress that SBOMrepresents only one part of a secure software development strategy andlifecycle. Indeed, an SBOM is a tool (one that is very much a work in progress,as detailed below) in promoting good cyber hygiene.  It is not a silver bullet, and certainly nota substitute for the comprehensive approach laid out in Executive Order14028: Improving the Nation's Cybersecurity[2](aka “Cyber EO”) to make mission-critical software (regardless of itsproprietary or open-source development model) trustworthy and resilient.  Without a focus on open and transparentsoftware management over the life cycle of a software product, as envisioned bythe Cyber EO, little progress will be made.

The promise of being able to streamlinethe vulnerability identification and mitigation process is certainly appealing.An accurate SBOM can play an important role in achieving that goal, by enablingan understanding of the inventory of the used software components. Indeed,component inventories, which are an essential first step to producing an SBOM,can support multiple assurance processes. However, these goals can be achievedmost effectively if grounded in a better understanding of the advantages andlimitations of SBOMs today, how they fit into essential software lifecyclemanagement and cybersecurity risk management practices, and where SBOMs need tocontinue to evolve. All of this requires further work before SBOMs can beeffectively utilized for procurement, security, or any other use case.

Below, we highlight the key areas that webelieve are in need of improvement before procurement requirements can beplaced on software producers and before agencies can make effective use ofSBOMs in their environments. To address these concerns, we recommend thefollowing:

●    Establish pilot programs involvingsoftware suppliers and agencies to demonstrate the effectiveness of SBOMs inimproving vulnerability management practices, based on risk metrics, morerapidly and with less effort than existing tools and processes.

●    Drive to common standards forsharing, processing, and implementation of SBOMs and infrastructure to reducepotential confusion and inconsistency in outcomes.

●    Perform additional research anddevelop pilot programs to better refine how SBOMs can and should be used incloud environments.

●    Create public/private workshops todiscuss both the technical and non-technical aspects of SBOM sharing, includingestablishment of criteria for ensuring confidentiality where desired, andavoiding liability for software suppliers.

Creation,Sharing, and Consumption

Given that SBOMs are a relatively new andoften misunderstood topic, they are not being produced routinely by manysoftware producers, and changing that will require time and effort. As such,the Coalition believes that the U.S. federal government should provide clarityon what software (either by type or specific applications) they areprioritizing so that producers of that software can prioritize their efforts todevelop SBOMs with the correct data elements, and ensure that sharingmechanisms are in place. While the National Institute of Standards andTechnology (NIST) provided guidance by defining EO-critical software, NIST alsonoted that the Cybersecurity and Infrastructure Security Agency (CISA) wouldprovide more specifics. As of this writing, these specifics have not been madepublicly available. Without this prioritization, efforts to implement the useof SBOM could be hindered by development resources spread too thin and agenciesleft expecting too much from software producers, or lacking the capabilities touse SBOMs effectively for mission critical applications. Any disconnect oneither end of that transaction will result in confusion and disappointment.

Additionally, it is important torecognize that, in the near term, there will be inconsistencies related to softwareproduced before the Cyber EO versus software produced after. This should beaccounted for in any requirements that are put into place and ensure thatagencies understand the issue well enough to discuss with software producers.

We also note that at this time, itremains unclear how departments and agencies will receive and use SBOMs oncethey are shared with them. The government has thousands of trained anddedicated Information System Security Officers who already have moreinformation than they can effectively manage in a timely manner. Thelong-standing processes they follow to identify and mitigate vulnerabilitieshave been in place largely since the introduction of the Federal InformationSecurity Modernization Act (FISMA), and we are concerned that simply addingSBOMs to the mix, without carefully demonstrating how it will streamline andimprove those processes, will result in resistance and failed implementation.

It is necessary to recognize that asgovernment and industry work collectively to mature SBOMs, the ecosystem willremain imperfect and that some protections should be afforded inacknowledgement of this. The nature of those protections will require ongoingdiscussion as SBOM matures, but our view is that SBOMs are intended to improvecommunication and facilitate risk assessment and response. In doing so, theycan help foster transparency and trust. The creation, sharing, and consumptionof SBOMs must be well understood in the context of software development,lifecycle management, and security practices.

Additionally, overly stringentrequirements related to the production and dissemination of SBOMs will requirethat resources be diverted from other activities, which for many organizationswill include meeting other requirements, such as those related to securesoftware development. The impact of this will vary from one software producerto another, but should be carefully considered so that we don’t take one stepforward with SBOM at the expense of slowing or stalling other efforts essentialto security and the development of secure software.

The Coalition encourages the federalgovernment to seek additional input and collaboration with software producersto continue capturing best practices and ensure that the use of SBOM acrossdepartments and agencies is successful. We recognize that CISA is planningworking groups designed to help accomplish this goal, and the Coalition and itsmembers look forward to participating.


The amount of software in mostorganizations, combined with how often it gets updated or replaced, creates adynamic environment that is far greater than humans can process manually.

For software consumers, introducingSBOMs, which track the tens, hundreds, or thousands of components in each pieceof software an organization manages, without improving automation will onlymake this problem worse. For SBOMs to be useful to consumers, technology andautomated processes need to be standardized, validated, and in place to receiveand/or review SBOMs, integrate their information into existing vulnerabilityand asset management systems, and enable those systems to interact with SBOMsquickly and efficiently. Robust SBOM data integrity and authenticity solutions(e.g., signatures) should be developed and adopted for organizations toautomatically validate and trust the contents of SBOMs they receive.

For software producers, a lack ofautomation could be especially problematic for complex systems that havedependencies on multiple open source and commercial components. For example,most software producers are somewhere in the middle of the supply chain andautomation is required to combine upstream SBOMs with other providers withtheir own. That same process could occur many times, by various softwareproducers before a final product and associated SBOM can be delivered. In orderfor consumers to make effective use of SBOMs to mitigate security risks,producers must be able to generate accurate, trustworthy SBOMs as a naturalbyproduct of the software build and maintenance processes. This requiresautomation to integrate SBOM creation and signing into many softwareprogramming languages, build tools and package managers.

While good progress is being made, thenecessary technology and processes are not in place at scale today,particularly between organizations (both within the supply chain and betweenvendors and consumers of software) where sharing of SBOMs is necessary for themto be effective. The utility of SBOMs is impacted by the SBOM consumer’sability to receive them, validate their integrity, organize them, associate thecorrect SBOM with the installed product version, and conduct queries as neededautomatically. There is currently a lack of standardized SBOM adoption whichmakes sharing difficult. This is especially difficult for certain environmentsin which the underlying software builds and dependencies are rapidly evolving,and where development lifecycles are happening faster.

The Coalition recognizes that this is aclassic “chicken and egg” problem. We believe that a series of pilots and testcases could be beneficial in encouraging the creation, sharing, and consumptionof SBOMs, as well as create a better understanding of the automation that isnecessary to use them effectively.

Challengesin Cloud Environments

Software is continuously being alteredduring its lifecycle. Even relatively stable software products, such asoperating systems, receive patches or new features routinely. This is only morechallenging when we take Software as a Service (SaaS) into consideration, whereupdates may be occurring on a nearly continuous basis. In practice, thisgenerally results in a net positive for users, since it standardizes thepatching process and timeline, leading to faster resolution of vulnerabilitieswhen they are discovered across all users of that software.  Given the ongoing and interactive nature ofchanges in cloud environments, effectively generating and sharing SBOMs in acloud environment poses challenges. For starters, there is a real risk of SBOMsbecoming outdated so quickly, that a false sense of security could be createdif SBOMs aren’t updated at the same pace as the code itself.

Further, clouds also pose the problem oflayered deployments.  Services depend onother services, some of which are not publicly available. How can we determinethe appropriate place for the SBOM to “start” and “end”? For example, how fardown the infrastructure stack should an SBOM go? Should it include thedependencies used to deploy and operate a cloud service and/or theinfrastructure needed to run it? Further, cloud services are highly dynamic andrequests can be routed based on all kinds of inputs (e.g. who the user is,location, cohort for A/B testing, cohort for blue/green deployment). This istrue for both the initial service call as well as all subsequent calls. Duringa service rollout, it’s also likely that different versions of a service may bein use at the same time.

These challenges are not insurmountable,but they do suggest that real-world test cases and pilots could prove valuablein addressing them.  The General ServicesAdministration (GSA) and Department of Homeland Security (DHS) arewell-positioned to be able to develop and run meaningful pilots with industryand we also believe that existing cloud certification processes, such asFedRAMP, could be leveraged in establishing SBOM related requirements andvalidation, rather than through general procurement contract clauses orregulations.


The concept of an SBOM is rooted in atraditional software publisher scenario. However, increasingly, that assumption is misplaced.  Certainly, as suggested by some, having avendor-produced SBOM could have assisted in discovery of the use of #Log4j.Indeed, this particular use case has energized many around the idea of SBOM andhas brought increased attention to implementation. However, digitaltransformation in the enterprise (and in government) means that all companiesand organizations are becoming software developers themselves. Thus, it islikely that a significant share of the deployment of Log4j was outsidetraditional vendor-provided software (or in products that were no longersupported by vendors). As such, it is likely that some portion of futurevulnerabilities will be similarly “hidden”, even with a robust SBOM ecosystemin place. This is an important reminder that even with the challenges discussedand addressed here, SBOM remains only a part of the overall solution toprocuring, implementing, and managing secure software.

The discipline needed to produce robust,resilient software-based solutions requires everyone to improve theirsoftware use and production processes as envisioned by the Cyber EO’s focus onopen and transparent software management over the life cycle of a softwareproduct.

May 2022