The Linux Foundation | 15 February 2022
The Linux Foundation recently published findings on The State of Software Bill of Materials (SBOM) and Cybersecurity Readiness, conducted in late 2021. Jason Perlow, LF editorial director, spoke with Stephen Hendrick, vice president of Research, who led the empirical study and quantitative analysis to understand the extent to which the world was implementing cybersecurity standards and what actions need to be taken now.
JP: For those new to SBOMs, what are they? Can you unpack the concept for the absolute beginner?
SH: A good analogy for this would be when you go to the supermarket and shop for food products. Because we have a Food and Drug Administration in the United States, food manufacturers must follow food packaging and labeling regulations. In our most recent webinar that we held on Feb 1, one of our panelists, Allan Friedman, illustrated this example with a Twinkie snack cake sitting on his shelf.
Original Image: “Hostess Twinkies” by Evan-Amos, CC0, via Wikimedia Commons
A Twinkie has a list of ingredients printed on it, over 35 in all if you look at the food label on Hostess’ website. Now, imagine if you were allergic to one of those ingredients, such as the eggs, or one of the flours. Or, if you were vegetarian, the Twinkie contains beef fat (tallow).
You’d want to know those things, wouldn’t you?
The same goes for software that may be running in your enterprise – based on their “ingredients”, components, or packages that are used to make up the software composition of those environments; an SBOM can tell you which of those components you are running may have vulnerabilities your organization may need to address.
JP: So, what many people want to know is, why do we care about SBOMs? What is the context for SBOMs as they relate to software supply chains, why is the Linux Foundation researching it, and why is it all happening now?
SH: Cybersecurity has been top of mind across government, enterprise, and the open source community. For this reason, research into this topic was a top priority for the Linux Foundation. Much of the interest in SBOMs specifically was driven by 2020’s SolarWinds software supply chain attack and even before the US Executive Order on Cybersecurity. The EO specifically named SBOM as a recommendation for improving cybersecurity. The Apache Log4j vulnerability was disclosed late last year, further accelerating interest in SBOMs.
For the last several months, the Linux Foundation surveyed enterprises and quantitatively determined their sentiment about SBOMs and their level of adoption, maturity, and progress. Now we have those results.
JP: I get that an SBOM tells you what components are in a software package – whether it’s open source or closed source. How did SBOMs start as an open source initiative, and why has the open source community been at the forefront of this push for supply chain transparency?
SH: Early on in the enterprise adoption of open source, companies were concerned about licensing and ensuring appropriate license compliance. It was an open source effort at the time, primarily because they were exposed to these open source licenses that didn’t come through traditional procurement processes. So the open source community embraced the SBOM concept to provide transparency about which components are used in a package and what licenses were attached to them.
Over time, however, the openness that an SBOM provides became helpful in other contexts. An organization that requires SBOMs is likely ahead of the game when a new security vulnerability comes out. Log4j has been in the news but imagine you’re an organization with tens or hundreds of thousands of servers, and how do you find and patch all the log4j instances? SBOMs enable you to do that much more easily.
JP: There was a global response to this survey, with 98 percent of organizations expressing concerns about their software security. Virtually all of those organizations are considering implementing changes to their environments, including adopting SBOMs. Were you expecting that sort of drastic response before reviewing the data?
SH: This was a global, multilingual survey, and as such, we received completed surveys from 412 senior IT respondents worldwide. A total of 44% of the respondents came from the Americas, 39% from EMEA (Europe, Middle East, and Africa), and 17% from Asia Pacific (India, China, Russia, Japan, and Australia).
Because this survey focused on cybersecurity and SBOMs, one of the first questions we asked was how concerned the respondent’s organization was about the security of the software it uses.
We observed from the data that the Americas and EMEA show a distribution of concerns that peaks at 49% for the Americas and 55% for EMEA being “very concerned.” Worldwide, 98% of organizations have a level of concern about cybersecurity.
The European Union (EU) has been increasing its cybersecurity footprint considerably in the last decade with the introduction of the General Data Protection Regulation (GDPR) in April of 2016 – this begat efforts with the NIS Directive on Security of Network and Information Systems and the EU Cybersecurity Act in 2019, so this has been brewing outside our country for some time.
In Asia, the distribution for overall cybersecurity concerns is significantly different from that of the Americas or EMEA. Security concerns in the Asia Pacific gradually ramp up, with 15% “slightly concerned,” 18% “concerned,” 31% “very concerned,” and 35% “extremely concerned.” Nearly twice as many organizations in the Asia Pacific region are “extremely concerned” than EMEA, and 67% more than in the Americas. The reason why software security angst is higher in the Asia Pacific region is explained throughout the report. In summary, it appears that the organizations in the Asia Pacific region have invested less to date in security-related roles, functions, and activities, so now they are trying to catch up.
JP: In the report, you spend a fair amount of time talking about organizational activities and plans for SBOM adoption. Could you summarize what you found?
SH: I spent thirty years as an industry analyst focused on application development and deployment. During these years, I never once heard the term SBOM. When designing this survey, I worried it might be difficult to find much production use of SBOM tools. To address this, the survey contained questions about SBOM familiarity, readiness, and use of tools for SBOM production and consumption.
I was surprised to find that 47% of organizations produced or consumed SBOMs in 2021. In many cases, this meant using SBOMs in a few or some segments of their business. But a surprising number of organizations were using SBOMs across nearly all of their business segments or had implemented SBOMS as an organizational standard. It was also exciting to see that 41% of organizations plan to use SBOMs beginning in 2022 or 2023. This allowed us to forecast the organizational growth of SBOMs.
By 2022, SBOM organizational growth will be 66%, increasing SBOM penetration across organizations from 47% to 78%. Growth will taper off to 13% during 2023 but still drive an increase in penetration to 88%. This means that 2022 will be the year of the SBOM. This also means that 2022 will be a great year for vendors selling SBOM production and consumption tools.
JP: Given the amazing growth that could take place in 2022, what benefits do organizations expect to see from their increasing use of SBOMs?
SH: There are many benefits from the use of SBOMs. Let’s focus on the consumption of SBOMs because that’s what most end-user organizations will be doing. Overall, 53% of organizations said that the primary benefit would come from the ability of SBOMs to provide information about components to support their compliance and reporting needs.
At the same time, 53% of organizations also said that SBOMs provide information to make better decisions about risk. Another feature of SBOMs is their ability to link to registries that identify known component vulnerabilities. This is also why the third benefit listed here at 49% is the ability to understand new component vulnerabilities and whether the organization is at risk.
The chart above is also segmented by the maturity of organizations in their use of SBOMs. This is where SBOM innovators help identify best practices because they have a much deeper experience in using SBOMs and are better positioned to provide an experienced perspective.
JP: While it seems that organizations are clear on the benefits of SBOM adoption, it also looks as if a large number are concerned about the industry’s commitment to them as a whole. Why do you suppose that is? Do you think that has to do with a perceived lack of an established standard or a lack of guidance and best practices for what they need to contain, overall? How do we get past this industry confidence problem in SBOMs, given that there seems to be heavy operational involvement by organizations as a whole?
SH: The first thing to recognize is that SBOMs are expected to be exchanged between participants in the supply chain, and the software supply chains are global. We need to see the industries adopt standards that the international community has formally reviewed for confidence to emerge. This is why SPDX, after 8 years of being a de facto standard, undertook the step to go through the review process to become an ISO-approved standard. It went to the ISO after incorporating the guidance that had emerged from the NTIA multistakeholder process as to what minimum elements for an SBOM should be.
Since most software today is built on open source, it makes it easy for open source ecosystems to generate SBOMs for their parts, removes some of the lift for organizations, and adds on the parts they modify. A whole software development ecosystem needs to adjust, not just the companies that ship products, which will take time.
JP: Thank you, Steve, that was very informative.