Not knowing what’s in your food can have consequences. The same is true for software. That’s why you need a software bill of materials (SBOM) to minimize software security risk.
Countless studies and articles have documented the health dangers lurking in America’s fast food culture. Cheap, convenient meals, like a Big Mac, fries and a Coke contain something close to an adult’s daily ration of fat, carbohydrates and sodium. But, until recently, critical information like that wasn’t readily available to diners. The result has been an epidemic of obesity, memorialized in the 2004 documentary Super Size Me!, in which documentary filmmaker Morgan Spurlock ate nothing but McDonald’s for an entire month — a period during which he gained 24 pounds, saw his cholesterol levels soar and developed fatty liver disease.
For health and nutrition experts, the answer to the problem of food-borne risks was legislation. The November 1990 Nutrition Labeling and Education Act (NLEA) provided everyday Americans with detailed information on processed and packaged foods by mandating the use of a nutrition label. Subsequent to that, the Federal Food, Drug, and Cosmetic Act (FD&C Act) was amended to require chain restaurants and retail food establishments to post calorie and other nutrition information on menus, menu boards and signs for all standard menu items. These laws and regulations have empowered U.S. consumers to make informed decisions about the food they are buying in grocery stores and restaurants — including fast food chains.
[ Get a free SBOM and full supply chain risk analysis report ]
Software quality is anyone’s guess
Alas, software developers and software development organizations find themselves in a similar place to fast food diners these days. Even a modest software application might contain hundreds- or thousands of discrete components from a number of sources: internally developed, commercially licensed and open source. Data from the firm Synopsys suggests that applications are becoming more complex, also. The average number of components in an application almost doubled between 2018 and 2021, increasing from 298 to 528 during that time.
Despite that, the same level of transparency doesn’t exist for software developers as shoppers and diners, even though the risks lurking in the software supply chain are well-documented. In 2014, for example, the so-called Heartbleed bug in the OpenSSL library affected around 17% of the Internet's secure web servers (more than half a million systems) were vulnerable to attacks that could enable theft of the servers' private keys and users' session cookies and passwords. In the years since, incidents involving software supply chain risk have become regular occurrences. The 2020 hack of SolarWinds or the 2021 Log4j vulnerability or the compromise of CodeCov have led to a reckoning in the industry to bolster software security.
While there has been no legislative response to these attacks, the Biden Administration published an Executive Order on Improving the Nation’s Cybersecurity in May 2021, which specifically targets software supply chain security and calls upon federal agencies to take steps in establishing software security best practices. Afterwards, the National Institute of Standards and Technology (NIST) released their Secure Software Development Framework. In it, it calls for the use of Software Bills of Materials (SBOMs) - a kind of nutrition label in order to minimize software supply chain attack risk.
SBOM: A nutrition label for software
Similar to the iconic black and white nutrition label we see on food packaging today, an SBOM enables those dependent on software to understand what exactly is in the applications they’re using. This gives both software developers and users a better sense of the risks associated with their applications.
By directly comparing the nutritional food label to an SBOM, software practitioners can see why their use is of the utmost importance for securing the software supply chain.
Software bills of materials come in many forms, but almost all contain a few, key elements:
- Product/Component Name: Designation typically defined by the original publisher.
- Publisher Name: The name of an entity that creates, defines, and identifies components.
- Product/Component Version: Identifier used by the supplier to specify a change in software from a previously identified version.
- File Name: Serves as an additional identifier within a larger package of software
- Software License: Indicates how open-source components can be used, modified and/or shared.
- Dependencies: Identifies other sub-components that are included within the component.
Similar to an ingredients list, an SBOM offers a complete picture of what a software application consists of: third party software, open source software, statically linked packages, and other dependencies that run complicated and deep in an application.
An SBOM also provides insight into the complexity of a piece of software by documenting the variety and number of components it uses, including version numbers. Just like consumers can spot ingredients in a food product that are harmful, such as high-fructose corn syrup, software purchasers or development organizations can interrogate SBOMs for known-dangerous components like vulnerable versions of libraries like Log4j. Minimizing a list of components or ingredients, to only what is truly needed and is safe, can reduce unhelpful bloat (literally and figuratively).
Like a nutrition label, a good SBOM will hold software development organizations accountable for tracking and documenting exactly how an application has been made. Not all SBOMs show this bigger picture, namely those created from build manifests. Generating an SBOM just at this stage doesn’t list key components that arise during installation, which can cause developers to overlook vulnerabilities and tampering. This is why an SBOM must show “software as delivered,” meaning it includes the binaries and the packaging that went into an application’s deployment, providing developers with an extra security standard.
Having a list of software ingredients is a great start, what’s even better is expanding an SBOM with risk analysis of each component that detects malware, software tampering, exposed secrets, actively exploited vulnerabilities, etc. and determines the level of deployment risk posed by each component. This is akin to a nutrition label’s “daily value percentage” for each food group, which provides the context of what share of daily intake the portion would constitute. Prioritizing items listed in a SBOM by the level of the risk helps development and security teams understand how their software supply chain contributes to their applications’ risk profile. In comparison, an SBOM, enhanced with risk analysis, enables development teams to see which software publishers are delivering secure code and to assess whether the risk of using a component outweighs the “reward” it offers.
SBOMs: There’s still work to do
While the use of SBOMs is not mandated by the U.S. government, the software industry is becoming more open to their benefits, with 78% of organizations expecting to either produce or consume SBOMs in the future. However, the majority of the software industry has yet to get on board the SBOM train. A recent survey conducted by Dimensional Research found that only 27% of software development organizations generate and review SBOMs. This lack of usage of SBOMs enhanced with risk analysis leaves an organization’s software supply chain vulnerable to many types of attacks.
As the community continues to understand software supply chain risk, more and more threats to software security are discovered. For example, ReversingLabs researchers and others have established a proof-of-concept that dependency confusion attacks via NPM, a popular package repository site, are capable of attacking critical infrastructure. Also, ReversingLabs Reverse Engineer Karlo Zanki found that packages in the PyPI repository pose the risks of releasing secrets, plus overpowered PyPI plugins can be detrimental to development teams.
These growing risks are all the more reason why software publishing organizations need SBOMs. A good SBOM will provide transparency into the build, installation, and deployment processes, similar to how a nutrition label will shed light on how a food was made, and with what ingredients.
Software teams need to go beyond vulnerabilities
For software teams to stay vigilant on software supply chain security risks, they need to expand their approach to securing software beyond vulnerabilities. In Dimensional Research’s survey, 9 in 10 software professionals cited that the difficulty to create and review SBOMs is increasing, reasons being that organizations lack expertise, and they aren’t adequately staffed to review and analyze SBOMs.
