Press Release
Last Updated on January 4, 2024
A software bill of materials (SBOM) has multiple benefits for vendors, their clients, and other stakeholders. This post highlights some of the biggest.
Benefits for developers
Tim Mackey, Head of Software Supply Chain Risk Strategy at Synopsys, points out that an SBOM can help developers reduce business risk by flagging three major classes of problems in the code:
- Security vulnerabilities
- Code quality concerns
- License compliance issues
As a developer, you need to verify that any third-party code you’re choosing reflects the latest versions of properly maintained components that don’t have any outstanding security issues, and whose licensing aligns with your organization’s standard/policy for approved license types to use.
You want something that’s new, not six versions behind. Otherwise, updates might entail a lot of functional changes on top of patching a CVE.
An SBOM can also alert teams to how many different versions of the same components they may be using. This can be a real wakeup call, according to Tim.
Licensing risk
What is licensing compliance risk with open source? All software has some form of license associated with it, which specifies user rights and obligations. Rights can be things like the types of apps you can use the code in, and what kinds of things you can do with it in your apps.
With license obligations, just because it’s on the internet doesn’t mean it’s free of costs or restrictions. For example, some component licenses require you to publish all the source code for the entire application that uses the component. This might be OK for some Dev teams, but not for an org trying to leverage intellectual property within a software product.
“Are the various elements compatible with each other across all of the dependencies in the application so there are no encumbrances on the end result?” emphasizes Tim. It’s a robust SBOM that lets you determine this, and potentially keep you out of legal trouble.
SBOM benefits for users
Software users can think of an SBOM as enabling technology. It puts a line in the sand to say, “This is what an application looked like at the point of its release” in terms of dependencies and license information.
When vulnerability data is available alongside the SBOM data, users can answer important questions about whether an application was adequately tested for security. Are the libraries the latest versions? Are there a lot of developer downloads in the code? Is the code suitable for use in a regulated and/or high-risk environment, like financial services or critical infrastructure? Was it created in a way that fits the user’s overall compliance profile, such as within the US by “US persons” for certain defense or other import restricted programs?
“When you start dealing with governmental scenarios, you might have scary companies or scary countries or scary individuals who shouldn’t be contributing code to this type of application,” Tim explains. “So, you can start to do a lot of analysis around what’s happening in that application and the type of security practices that are employed by the entity that produced the SBOM.”
“In terms of how well suited is this application to run in my environment with my context, that’s something you can do really well when you have a robust SBOM that is truly comprehensive and accurate,” Tim adds.
Another great benefit of robust SBOMs for users is the ability to know quickly and with assurance which applications in your environment are subject to a particular vulnerability attack, like Log4Shell exposure. SBOMs could cut identification time for risky code from weeks of parallel effort to a few hours.
What’s next?
For more guidance on this topic, listen to Episode 116 of The Virtual CISO Podcast with guest Tim Mackey from Synopsys.
