Software bills of materials will never be a panacea for software supply chain security. Here are key trends that will deliver some welcome evolution, however.
With the growth in the widespread use of third-party and open source components in software, attackers are now squarely focused on the software supply chain — and attacks on supply chain components have surged since 2018.
So it’s no surprise that application security and SecOps teams are increasingly concerned about these emerging new security risks. One way to assess those risks — which came with a strong push from the U.S. government in the form of an Executive Order following the SolarWinds attack — is the Software Bill of Materials, or SBOM.
An SBOM is commonly compared to a list of ingredients on food items. It's a list of the components in an application or solution. The idea: If a user knows what's in the software they're using, they can better determine the risks it poses to them.
Like the OWASP Top 10 is to general application security, the SBOM is a starting point for operationalizing software supply chain security. "Generating an SBOM is a great first step," said ReversingLabs software assurance evangelist Charles Jones. "You understand what's in your software. Now you need to understand what that means as a publisher and as a consumer."
However, understanding SBOMs in practice is a concern for security teams, because they can only tell you a limited set of information – and only when you receive it, Jones said. "It's good to know what's in your food, but that doesn't tell you if an ingredient has been recalled or has been contaminated."
Jones explained that the confusion over SBOMs meant adoption was still lagging.
"There's a lack of clarity regarding not only when to generate and distribute an SBOM, but, more importantly, what to do with it when you get it. They just know it's a requirement."
—Charles Jones
SBOMs are also not a panacea for software supply chain security. Just because you know what's in your software doesn't mean you know which components that make up the software are introducing unnecessary risk into your business, such as the new class of software supply chain attacks that can carry out malware injections, software tampering and secrets exposure.
Regardless, SBOMs are a key component of developing your organization's strategy to tackle supply chain security. Here are four key trends emerging to deal with some of the limitations of today’s SBOMs.
1. Frameworks and guidelines emerge for SBOM data interchange
Several formats and frameworks have appeared to improve the interoperability of SBOMs, said Daniel Kennedy, research director for information security and networking at 451 Research.
"Having a common format when a primary use case is data interchange is always important.”
—Daniel Kennedy
Larry Maccherone, DevSecOps transformation evangelist at Contrast Security, said that when most people talk about SBOM, they aren’t talking about the general capability of a software composition analysis (SCA) tool to identify the contents.
"Rather, they are talking about the interchange format for moving that information across a toolchain and between organizations."
—Larry Maccherone
There are three prominent SBOM standards: SPDX, SWID and CycloneX. Maccherone explained that CycloneDX is one of the most prominent formats. "It has its advantages, as do SPDX and SWID, but for the most part, they all have roughly the same information. So, it matters less which format you use but more that each of your vendors and tools support at least one format in common."
Most SCA tool vendors are supporting at least two. But since it's not really a standard if there are more than one of them, there is pressure for one of them to become the de facto standard, he said.
2. SBOMs get more useful with supplemental analysis
The original focus of SBOMs was to simply identify what’s in the software. That is now being expanded to include analysis, to understand the risk of those ingredients. For example when teams can tie the components listed in an SBOM to known malware, Jones noted.
There are efforts to add vulnerability exploitability (VEX) information to the SBOM format. VEX was developed by the National Telecommunications and Information Administration (NTIA) and the Cybersecurity and Infrastructure Security Agency (CISA) to help suppliers determine if a product is impacted by a specific vulnerability in an included component and, if affected, the status of remediation.
Maccherone warned that one problem with this approach, however, is that the vulnerability landscape is constantly changing.
"If the software that you receive one day looks clean based upon the current status of known vulnerabilities, it is highly likely that new vulnerabilities will be found later. In order for analysis information to be valuable to the consumer, the SBOM will have to be updated whenever its analysis data changes, even when there are actually no changes to the contents of the software.”
—Larry Maccherone
3. More vendors are supporting SBOMs
One of the biggest trends is the number of vendors adding support — especially in the SCA space — for generating an SBOM around open source usage in real time, Kennedy noted.
Sounil Yu, chief information security officer at JupiterOne, a cyber asset management and governance solutions provider, said that while some suppliers will embrace SBOMs, others will not. He noted one explanation was the ability to produce an SBOM is highly correlated with the modernity and maturity of a company's software development practices and technology stack.
"Just having the ability to easily produce one gives a customer a higher level of confidence that a supplier's software development practices are modern and mature enough to counter a wide range of common issues related to vulnerable or poorly maintained software."
—Sounil Yu
Yu said that most SBOMs now being generated by suppliers were for private use. "There aren't too many examples of voluntary, public sharing of SBOMs," he said.
Rick Holland, chief information security officer and vice president for strategy at Digital Shadows, a digital risk protection solutions provider, said that sharing SBOMs can present challenges to technology vendors.
"An SBOM without context can create more work for both the buyer and the vendors. SBOMs could be interpreted differently by different customers, resulting in many questions from customer third-party risk teams."
—Rick Holland
4. Automation helps SBOMs keep pace
Automation is essential for successful software supply chain security, said Abhay Bhargav, Founder and Chief Research Officer at AppSecEngineer, a training service. Noting the changing nature of the vulnerability landscape, he said SBOMs need to be generated, tracked and managed automatically to be up to date.
"Vulnerabilities in libraries are being constantly discovered. This means that a library that was considered safe yesterday, suddenly is subjected to a massive zero-day flaw that allows an adversary to arbitrarily execute code on your server-side environment."
—Abhay Bhargav
The average application contains more than 500 open source components, according to Synopsis’s 2021 Open Source Security and Risk Analysis Report. Because of the dynamic nature of modern application development, software packages must be continually evaluated throughout their development, delivery and use lifecycle to ensure the security risk associated with existing, modified, or newly added components is understood, Jones said.
“Because of the volume of components which exist in an average software package, and their propensity for change, this is a near impossible feat without automation solutions."
—Charles Jones
Software supply chain security is a journey
With the swirl of new standards, guidelines, and publications around general software supply chain security, it is hard for software teams to keep up, Jones said.
"There are so many guidelines and frameworks and standards imposed across the supply chain that it's creating complexity and confusion.”
—Charles Jones
SBOMs are currently only a requirement for companies that do business with the federal government. Holland said that buyers need to vote with their dollars if they want to force SBOM adoption across the industry.
"In a world where vendors don't report or aren't even aware of all the software used in their solutions, defenders must fall back on detection and response.”
—Rick Holland
Bhargav stressed that software security and SecOps teams also need to acknowledge that SBOMs are not a cure-all for software supply chain security.
"A lot of folks see SBOMs as a comprehensive solution to supply-chain security issues, where they are actually just the beginning of a long and continuous journey into supply-chain security.”
—Abhay Bhargav
All Stories
Software Supply Chain Security
Dev & DevSecOps
CI/CD Security
Container Security