Organizations want and need to clean up their software supply chains in the constantly rippling wake of cyberattacks, hacks, and ransomware.
In this regard, businesses are increasingly turning to a valuable visibility tool: the software bill of materials (SBOM).
SBOMs have emerged as a key building block in software security and software supply chain risk management, as noted by the Cybersecurity and Infrastructure Security Agency (CISA).
What is the definition of a SBOM?
If you have ever worked in engineering or manufacturing, you may be familiar with a bill of materials, or BOM, which specifies all the components required to produce a given product, from raw materials to subcomponents and everything in between, along with quantities of each one needed for a finished product. An SBOM, then, is a software component.
SBOMs should include a complete, formalised, machine-readable list of these components, as well as libraries and modules necessary to develop the software, their supply chain relationships, and their respective vulnerabilities, according to the US Department of Commerce.
When it comes to SBOMs, Biden's Executive Order on Improving the Nations served as a wake-up call of sorts for federal software providers. They must now execute them and adhere to the minimum requirements therein.
Many industry experts are increasingly urging private software suppliers to do the same.
Why do you need to have them?
Developers test code theyve written to ensure there are no logic errors or coding mistakes in todays applications. A single application, for example, may be a cocktail of dozens of such components.
However, this third-party commercial and open-source software can be limited in visibility. Attackers are increasingly exploiting this by targeting weaknesses that organizations are unable to uncover due to inadequate visibility. Such as the Log4j vulnerability and the SolarWinds software supply chain incident.
A Syopsis Cybersecurity Research Center annual survey of 2,409 codebases revealed that 97% of them contained open-source components. It also revealed that 81% of these codebases had at least one known open-source vulnerability and that 53% contained license conflicts.
According to Gartner's 2022 Innovation Insight for SBOMs Report, companies are looking for solutions that not only help to mitigate product security risk and supply chain risk, but also shorten time-to-market, automate incident response, and assist with compliance requirements.
According to report authors Manjunath Bhat, Dale Gardner, and Mark Horvath, SBOMs are a critical first step in de-risking the vast amounts of code they create, consume, and operate.
According to the study, SBOMs improve the visibility, transparency, security, and integrity of proprietary and open-source code in software supply chains.
The supply chain toolbox is a must have.
According to the Linux Foundation Research team, improving software quality helps organizations fight adversarial attacks.
According to Linux research, there is also a link to this:
According to Bhat, Gardner, and Horvath of Gartner, they are an indispensable tool in your security and compliance toolbox. They help maintain software integrity and alert stakeholders to security violations.
Explained use case
The first question to answer about an SBOM is why does it need that information, according to Tim Mackey, the company's senior security strategist. Often the answer is that they do not want to be the victim of a Log4Shell style attack.
So, that simple patch management statement implies that there is a way to go through all software for Log4j usage and then map that usage back to a database of vulnerable versions of Log4j. If a version of Log4j is discovered to be vulnerable, a notification is sent to programmers, and,ideally, the problem is resolved.
If any software was not discovered, if the vulnerability database is outdated, or if there is a problem in the mapping of identified versions to vulnerable versions, he said, this entire workflow will be ruined.
Mackey emphasizes the fact that an SBOM is required for any organization that cannot be certain that its patch management policies cover all software.
Ohne such information, he added, any organization would be unable to defend itself against cyberattacks targeting third-party software components.
A new business strategy is forming.
According to Gartner, 60% of organizations that are developing or procuring critical infrastructure software will require and standardize SBOMs in their software engineering practice by 2025. That is an increase of roughly 20% over 2022.
The Linux Foundation Research team predicted that 78% of businesses would produce or consume SBOMs in 2022, up 68 percent from 2021. Additional industry consensus and government policy are expected to help accelerate SBOM adoption and implementation.
Anchore, Mend, Rezilion, Aqua, and Synopsys are among the new providers assisting businesses in constructing SBOMs.
SCAs have an increased likelihood of generating additional income.
However, following Bidens' order, SBOMs have been widely used in the software composition analysis (SCA) security marketplace for years, according to Mackey. Vendors in the market utilize SBOMs to identify open-source vulnerabilities.
SCA tools often include the SBOM workflow, according to Mackey. The SCA market is a mature one with many vendors.
Although there is a lot of emphasis on the concept of an SBOM, it is not always understood that an SBOM is simply a file listing all of the components that make up an application.
It doesn't include information about vulnerabilities, functionality, serviceability, or the component's age. It needs to come from other sources uncovered by tools such as SCAs, and it must also be supported by workflows.
Simply put, without those sources and workflows, an SBOM isn't more effective than telling someone who doesn't know they need to change their oil in their vehicle regularly the chemical composition of motor oil, according to Mackey.