Today, we’re seeing more businesses start to prioritize the use of software bill of materials (SBOM). Unfortunately for many, SBOMs are primarily generated as a check-box item, dropped in Google Drive – never to be seen again.
This misses an important opportunity to integrate SBOM insights throughout the software development lifecycle (SDLC). With the right steps, organizations can leverage SBOM data to understand and manage a variety of risks, including software supply chain security and open source license compliance.
In this blog, I’ll cover tooling, processes, and strategies that we at FOSSA have seen help organizations use SBOMs to manage risk throughout the software development lifecycle.
Note: This post is based on a webinar I recently hosted: How to Get Value from SBOMs Throughout the SDLC. If you’re interested in this topic and would like more information, we’d recommend you view the on-demand version, which is linked below.
SBOM During Planning and Defining
The planning and defining stages of the software development lifecycle are when product and engineering teams put their heads together to decide what will go into the next version of the software: features, feature definitions, and acceptance criteria. This is also a great time to make sure you have the right SBOM tooling for your product.
There are a lot of SBOM tools on the market today, and many are very good at supporting specific parts of the SBOM lifecycle. It’s harder to find a solution that does everything you need to surface and use first- and third-party SBOM data and gain real security benefits.
The goal is to find tools that enable you to get maximum, almost mechanical coverage of the languages and technologies you use. What I mean by mechanical is that if you have to create SBOMs in one way for a particular ecosystem or language and a different way for another language or ecosystem, you’ll get inconsistent and possibly inaccurate results.
I’d also note that a lot of today’s SBOM discussion focuses on first-party software— software that you and your organization are creating. But the nature of the software supply chain is that you’re also using a lot of software that other companies are creating. So, we’re seeing more and more organizations prioritize tooling that can import a third-party SBOM into a system where you can understand and manage license compliance and security.
Other tooling considerations include:
- What SBOM formats and specifications, such as SDPX or CycloneDX, do you want to use?
- How do you want to deliver SBOMs? Do you want to check the SBOM into source code as part of the build process? Or include it when an actual delivery artifact or release goes out the door?
Ultimately, your answers to these questions will go a long way toward helping you determine the best SBOM tooling for your organization’s needs.
SBOM During Designing and Building
The designing and building phases are when we really see product and engineering stakeholders working together to make sure that as software is being developed, you understand risks associated with using certain components.
The worst-case scenario is if you spend, say, six months building something that relies on a certain open source dependency — only to later find out that there is a critical vulnerability or license risk that makes it untenable to use that component. Doing this sort of check on every commit ensures you have a fast feedback cycle to rip and replace or consider other options much earlier in the process.
This is a big reason why we recommend generating your SBOMs during the build process. If you’re running an SBOM report immediately after the build has completed, you’re getting the most accurate, up-to-date list of dependencies as those dependencies are being resolved.
Once you have that list of dependencies, you can start to analyze them. This is where tooling like FOSSA can be really helpful. FOSSA provides a number of different types of dependency metadata, and we flag licensing issues and security vulnerability issues based on our analysis of your SBOM data.
SBOM During Deployment and Testing
You’ve set up your SBOM program, generated an up-to-date list of dependencies, and flagged security and licensing issues. Now, it’s time to activate the process gates that will safeguard against shipping software with serious vulnerabilities or license compliance risks out the door.
These process gates are generally the result of conversations between legal, security, and engineering stakeholders on topics like:
- Should we allow the use of copyleft-licensed components in a given product? How is that product being distributed?
- If there are security vulnerabilities — and there are in every piece of software that goes out the door — which do we need to address right now? And which can we leave until the next version?
Bringing these process gates to life is easiest with a tool like FOSSA, which allows organizations to automate implementation. For example, if your legal and engineering teams have agreed that a certain SaaS product can’t have any AGPL-licensed code, FOSSA can automatically flag the issue and fail CI builds until you’ve replaced the AGPL component.
This is where an SBOM can provide the most value — you know what’s in your software and the risks those components pose, so you can take appropriate action to reach the SLAs your organization has implemented. Given that modern applications can have hundreds of open source dependencies, it’s critical to use automation to quickly find the riskiest needles in this haystack.
This process is equally relevant to third-party application SBOMs: A little over a year ago, many organizations were dealing with the Log4Shell vulnerability and urgently trying to determine whether (and where) these applications were using Log4J.
Tooling that supports importing third-party SBOMs allows you to analyze those SBOMs in the same way you would our own code — and, in the case of a critical security vulnerability like Log4Shell, take prompt action, including alerting your vendors, to upgrade to a safe version.
Additional Resources: Maximizing the Value of SBOMs
If you found this blog useful and are interested in more SBOM-related content, I’d invite you to check out these recent webinars:
