Software bills of materials (SBOMs) have moved to the forefront of the battle to protect software pipelines, advanced by heightened awareness of the need for software supply chain security, as well as a nudge from the federal government and industry standards bodies. However, creating SBOMs needs to be more than a checkbox exercise if their full value is to be realized.

It’s a losing proposition to generate SBOMs just to land a federal contract or meet an industry requirement, without analyzing and acting on the SBOM data to improve software security. “An SBOM can reveal a lot about a software product’s components, including potential vulnerabilities and outdated libraries,” said MJ Kaufmann, an author and instructor with O’Reilly Media.

“When organizations treat the SBOM as just another item to check off a list, they may fail to act on this critical information, such as patching vulnerabilities or updating components.”
—MJ Kaufmann

Here’s why your organization needs to go beyond checkbox software security with actionable SBOMs.

[ See Special: Go Beyond the SBOM with Deep Visibility and New Controls for Your Software ]

The SBOM in the age of supply chain security

Charles Wallen, an information and infrastructure security analyst with the Software Engineering Institute’s CERT division at Carnegie Mellon University, said checkbox security may provide a false sense of comfort and potentially lead to negative outcomes. “Often such efforts are directed at compliance without appropriate consideration of risk,” Wallen said.         

Sean Wright, head of application security at the fraud prevention firm Featurespace, said that when controls and processes are viewed as purely checkbox exercises, there is little to no value in doing them. “The original purpose of those controls or processes is lost, hence being of little value,” he said. SBOMs as a security tool are no different, Wright said.

“The purpose of this process and tooling is to ensure that organizations know what they are using and where they are using it. So those who are viewing it as a checkbox exercise may only produce the SBOMs and do little else with them rather than using these artifacts to help drive their security and perform tasks such as updating dependencies and components quickly and effectively for high-risk vulnerabilities.”
—Sean Wright

Pass/fail test that always fails

The problem with checkbox security is it makes the SBOM a pass/fail test for whether a system is secure, said Jeff Williams, CTO and co-founder of Contrast Security. “Unfortunately, almost every SBOM is going to show that some components contain known vulnerabilities, so everything fails,” he said.

The reality is that 90% of those vulnerabilities are unexploitable in the deployed system, Williams said. Over 60% of the time, the component with those vulnerabilities is inactive — that is, never actually invoked — and therefore poses no risk. Other vulnerabilities require a specific configuration or conditions to make them exploitable, he said.

“Used correctly, SBOMs can create visibility and dramatically improve an organization’s risk posture. But it’s more complex than a simple checkbox exercise.”
—Jeff Williams

Nevertheless, many companies treat SBOMs as a checkbox exercise, said Shane Fry, chief technology officer at RunSafe Security. They simply generate an SBOM to say they have done the work, not following up by analyzing that SBOM to dig into the supply chain risks that are present in their software, Fry said.

“That doesn’t even get to the high percentage of organizations that are generating SBOMs and then refusing to ship them to their customers, which means customers can’t use them to secure the assets in their infrastructure.”
—Shane Fry

Getting proactive requires modern tooling

To maximize the benefits of their SBOMs, organizations need to be proactive. That starts with generating SBOMs throughout software development. “SBOMs are most valuable when they are part of the software development lifecycle in key stages, such as major releases, updates, and patches. This allows teams to monitor and resolve vulnerabilities before committing code to the wild,” O’Reilly’s Kaufmann explained.

Michael Skelton, vice president of operations and hacker success at Bugcrowd, recommends that organizations adopt a structured approach to generating and maintaining comprehensive SBOMs. “This includes conducting regular software inventories and employing automated tools to ensure accuracy and efficiency,” Skelton said.

Continuous monitoring and updating of SBOMs are crucial to reflect any changes or new additions, and collaboration with vendors is essential to obtain detailed SBOMs for third-party software and firmware, ensuring timely updates and patches, Skelton said.

“By following these steps, organizations can maintain a comprehensive understanding of their software components, reducing the risk of vulnerabilities and improving their overall cybersecurity posture.”
—Michael Skelton

Automation will be a critical part of that process. Trying to do this manually is going to be ineffective and likely will lead to failure to do it correctly, Featurespace’s Wright said. “Thankfully, there is a wealth of tooling available, with some excellent open-source solutions as well.”

“So with the cost no longer a significant factor, it now largely comes down to having the appropriate tooling correctly implemented and having a structured process around that tooling to produce current, up-to-date SBOMs.”
—Sean Wright

Making data insightful is key

What is more important than maintaining SBOMs for everything is working on how to operationalize them, said Menachem Shafran, a senior vice president of strategy and innovation at XM Cyber.

“Just knowing all the components doesn’t help. It’s about understanding how to use it to reduce risk. Understanding how to turn data into something insightful that can be used is the real challenge.”
—Menachem Shafran

Automation is key to gaining insights from that data, said Georgia Cooke, a research analyst with ABI Research. Software supply chains have become much more complex and will continue to be so, she said.

Some leaders say effective analysis of the entire software supply chain is not possible, Cooke said. But to counter the scale and complexity of the problem, organizations should seek effective routes of automation, shaping their data to enable machine-learning querying, which is an approach supported in the new Cyclone DX 1.6 standard.

Ensuring that vendors supply SBOMs in a manner compliant with automated tools will reduce the time spent by analysts on validating and reviewing the information, Cooke said.

“You cannot use SBOMs on their own; they provide little value. It’s much like having a warehouse inventory and then simply filing that list somewhere, not to be used again. You need to do something with it.”
—Sean Wright

And one of the most important things that you can do from a security perspective is to understand what security vulnerabilities are associated with the components that you have within your environment, Wright said. Then you can leverage that information to ensure that you assess the risk of those vulnerabilities and put the appropriate mitigations or remediations in place to eliminate or reduce the vulnerabilities that you deem to present a risk to your organization.

Wright said that having all your SBOMs centrally managed is also important because that makes it far more efficient for your team to manage these dependencies across your environments.

A layered approach is key to effective coverage

Chris Wysopal, chief security evangelist at Veracode, recommends incorporating advanced application security (AppSec) tools and SBOM generation directly into the CI/CD process for continuous visibility into supply chain risk.

“Even if you aren’t being asked to share SBOMs today, this will give early visibility into what customers will eventually see,” he explained.

It is also useful to quantify security debt by examining the scope and impact of vulnerabilities that affect the product as a result of all of the software components being used, he said.

“No software supplier is going to want to hand over an SBOM that shows them using libraries that are years out of date with dozens of critical vulnerabilities, so get ahead of it now by understanding how much work will be involved in reaching a clean bill of health.”
—Chris Wysopal

Timothy Jarrett, Veracode’s group vice president for product management, explained that SBOMs are a point-in-time representation of the composition of a piece of software, which may not contain all the information needed to manage risk in that software, such as vulnerability, license, and malicious package data.

“It also may not be complete without information about other technology in which the software is deployed or distributed,” he continued. “A good software supply chain tool can supply both the supplemental data and the redaction and collation capabilities needed to support these, as well as make the SBOM ‘living’ by keeping supplemental data updated.”

By combining SBOMs with modern software supply chain tools that provide artifact scanning, secrets scanning, and such, the user gets a full picture of their software supply chain risks, said Katie Teitler-Santullo, a cybersecurity strategist with OX Security.

“If users are only scanning at certain intervals and at different stages of the SDLC, they only get that slice of their risk posture, so they must incorporate all of these elements — across the entire software chain — and correlate the data to truly understand where there are urgent issues.”
—Katie Teitler-Santullo

Unknown threats can also be problematic for SBOMs. “SBOMs are best at identifying known problems quickly but are not valuable in identifying unknown problems without supplementary tools such as source code analysis or container security tools, which dynamically test for runtime vulnerabilities,” ABI’s Cooke said.

“Supplementing SBOMs with these tools provides a much more robust picture of the dependencies and vulnerability landscape of a product, increasing confidence that threats are likely to have been identified,” she added.

Idan Plotnik, CEO and co-founder of Apiiro, pointed out that software supply chain security tools can support SBOM automation. Software supply chain security tools can perform the automation for you, making it much more convenient and efficient to add automation to the SBOM’s document generation, he said.

“An SBOM will evolve as more libraries and software are added to your infrastructure, so automation makes the process much more efficient and reduces the risk of mistakes or oversights.”
—Idan Plotnik

SBOMs can be a powerful tool for securing the software supply chain. By moving beyond checkbox compliance and supplementing SBOMs with software supply chain security tools, organizations can significantly improve their security posture, reduce risk, and enhance transparency.

Modern software threats require modern tooling

Saša Zdjelar, chief trust officer at ReversingLabs, recently said while introducing RL’s Spectra Assure SAFE Report in his blog that a major problem with how software supply chain security (SSCS) is managed is that key stakeholders responsible for different aspects of the supply chain lack truly effective tools. Software developers, cybersecurity teams, and risk managers all are working without comprehensive tooling that identifies all SSCS threats — something that SAFE solves for. 

For those needing to secure their software development processes, traditional application security (AppSec) tools — static and dynamic application security testing (SAST/DAST) and software composition analysis (SCA) — have been the go-to approach. But while these tools have proved their value in traditional AppSec, they are focused largely on open source and therefore do not detect and mitigate all the kinds of threats facing software supply chains, Zdjelar wrote. 

And while SBOMs will continue to be essential for software producers and consumers that want a transparent view into the components of a software product, they fall short for SSCS because they can’t spot malicious tampering or behavioral differences in software versions.

Likewise, organizations purchasing commercial software products have had to rely on processes such as vendor security questionnaires, but non-vetted self-assessments can gloss over key threats. And tried-and-true legacy technologies such as antivirus, endpoint protection platforms, and penetration testing work well for cybersecurity but can’t thwart a software supply chain attack. 

Matt Rose, a former field CISO at ReversingLabs, said the reason to look beyond source code-based security is that it is not realistic to think that a third-party vendor will send code for you to inspect for supply chain risks. That’s because no vendor is ever going to say, “My software is riddled with holes.” 

“Software supply chain security mechanisms need to be implemented in a way that is not cumbersome, complex, or disruptive to existing CI/CD and release processes. NIST’s Secure Software Development Framework is the best standard right now, but there are others as well.”
—Matt Rose

The complexity of modern development calls for modern tools to manage risk across the software development lifecycle, Rose wrote recently.

“While legacy AppSec testing (technologies such as SAST, DAST, RASP, and SCA) focuses on application source code, packages, and an application at runtime, what you receive from vendors is binaries — which is why binary analysis of the compiled packages is where you should be looking to identify risks.”
—Matt Rose

With complex binary analysis, organizations can evaluate all of the software they produce and consume, including third-party commercial software. The Enduring Security Framework, a public-private working group led by the National Security Agency and the U.S. Cybersecurity Infrastructure and Security Agency, recently stepped up its software supply chain security guidance with a call for complex binary analysis and reproducible builds, Rose noted.

*** This is a Security Bloggers Network syndicated blog from ReversingLabs Blog authored by John P. Mello Jr.. Read the original post at: https://www.reversinglabs.com/blog/sbom-go-beyond-checkbox-software-security