Are you looking to better understand a Software Bill of Materials (SBOM) and why it’s essential for your organization? Then you’ve come to the right place!
Delan Elliot sat down with Oscar van der Meer – the Co-Founder and CEO of MergeBase. Oscar is an expert in protecting the software supply chain, and SBOMs are vital to that. In his chat with Dylan, he explains the fundamentals of SBOMs, outlining their importance and providing guidance on where organizations can turn for more information. So if you’re ready to learn about SBOMs, let’s start!
Explore MergeBase’s free trial to create your SBOM easily and efficiently.
Don’t wait until it’s too late! Start taking control of your software’s security with a Software Bill of Materials (SBOM). Gain transparency into your application’s components, identify vulnerabilities, and reduce risk.
All about SBOMs - Video Transcription
Delan: Let’s start by asking what is an SBOM, what it stands for, and why are they important?
Oscar: In short, it is a very simple file format that lists the bill of materials. A bill of materials is a century-old concept. It’s used in construction and manufacturing. If you build a house, you know what the components are that the house is made with. But for software, it’s a new thing. So, a software bill of materials (SBOM) tells you all the components of an application. Knowing what all the components are is essential from a risk management perspective.
Delan: What kind of companies have we seen recently using software build materials?
Oscar: The SBOM wave is just starting and is going through regulation. Different regulatory bodies in the US, Canada, and other countries are developing regulations requiring organizations to use SBOMs. The US federal government is a big proponent of SBOMs. If you want to deliver services to the US government, you must have an SBOM. For example, the Federal Drug Administration (FDA) will require an SBOM for medical devices by October 1st this year.
Software supply chain attacks have increased tenfold over the last two years. This has triggered many other organizations to expand their software supply chain risk management.
Delan: You mentioned the term software supply chain. So it’s essential to discuss the differences in the supply chain of software versus conventional industries. What makes software so different, and what makes securing its supply chain important?
Oscar: We need to start on the basis that many software components tend to be free because it’s open-source software. Why is that important? If you look at the traditional risk management frameworks that, for instance, financial institutions and a lot of other industries are using, are built on the fact that the guy who’s at the top of the food chain, for example, General Motors who probably manufacturers 20% of the car components themselves while 80% comes from suppliers.
They have close relationships with, for instance, an airbag manufacturer. So General Motors can enforce its standards, policies, procedures, and quality criteria onto the supplier. Through that, it can effectively offload much of its risk management and effort onto its suppliers. It all starts with the fact that General Motors is paying these suppliers; it gives them tremendous leverage.
Not in software. What happened so far; you used to have software commercial components that people would buy, like libraries in the Microsoft build environment. That has increasingly been replaced by open source. Now, 80 to 90% of an application consists of open-source components without leverage over the supplier. You can’t go to them and say; we’re not going to pay you if you don’t meet our standards because it’s free; you lost the leverage. That’s why there are many issues, and many companies with a traditional risk management mindset need help to figure out how to apply safety standards to open source.
Delan: If I’m a user who wants to get started creating an SBOM, maybe because I realize now the importance of it or I am working in an industry which will be regulated soon, how do I get started?
Oscar: There are several open-source tools that you can use to create a software bill of materials. For example, MergeBase has a free trial. With a free trial, you can quickly start playing around with it. That is what many organizations are doing.From a contractual perspective, you can ask your supplier for an SBOM. You also can review the terms and conditions in your vendor management area.
Some organizations don’t specify precisely what an SBOM needs to look like at first, but then later, they will standardize the format. Organizations that start using an SBOM are seeing an immediate lift because they now have transparency in their software built, vulnerabilities are flagged, and developers can immediately fix vulnerabilities and reduce the company’s risk.
Delan: There are many reasons to use SBOMs. Is it difficult procedurally to get started, or is it something that you can do easily within your organization?
Oscar: There are two sides to the SBOM market. Some software vendors that produce an SBOM, and the buyers that buy different software packages and require SBOM. If you’re a software vendor, it’s easy to start producing an SBOM because you have a few applications. You can integrate a tool like MergeBase into your build pipeline, and every time you build an application, you generate an SBOM. That is straightforward.
As a software vendor, you want to make sure that you have backup support because there might be vulnerabilities that are not in the development of your application, and so having a backup gives you the ability to understand the impact of these vulnerabilities better. MergeBase can identify which vulnerabilities are not impacting the security of your application.
If you are a buyer, you must deal with the different maturity levels and standards of their suppliers. Some suppliers can quickly provide you with an SBOM, but others might not or provide it in formats that are difficult to digest for the buyer. Buyers tend to have a longer journey to make the SBOM process effective.
Ultimately it is all about the buyer because it’s their risks that we’re trying to reduce.
Delan: you mentioned that there are multiple standards of SBOMs, and there’s also something called VEX. Can you talk about the different standards of SBOMs and their differences?
Oscar: There are several different standards. The two dominant ones in the market currently are Cyclone DX which is supported by OWASP and is the de facto organization for applications. The other format is SPDX, which has become an ISO standard. ISO is the leading global standard.
We’re seeing that organizations that actively use SBOMs right now go beyond just collecting them. They are analyzing them and working with them. They often use Cyclone PX tools. Some organizations take a longer-term view and have a multi-year process to wrestle this problem to the ground and, in a step-by-step managed fashion, get to where they want to be from a risk management perspective. Those companies often favor SPDX.
Delan: What does it mean to have VEX-enabled access?
Oscar: VEX provides annotation on a small scale. You have one component list and VEX adds information about vulnerable components. That gives you insight if a vulnerability affects an application. Perhaps because there’s a compensating control or a component where it is located can’t be abused. An excellent example of this is encryption libraries. Encryption libraries often have encryption algorithms, and you might be using one that is perfectly fine and does not affect the application. But there can be a vulnerability with another algorithm in that same library that does harm your application. So it’s good to use it as part of the internal risk management as if you’re using it actively.
For the vendors, it’s essential to have VEX because it reduces their effort to eliminate vulnerabilities. There are scenarios that it doesn’t make sense for them to eliminate that vulnerability in, for example, a specific crypto library because they’re not using that part. Buyers are often skeptical, and they want to do their analysis.
Delan: Should you wait to adopt SBOMs until there is a global ISO standard or until the Cyclone DX format matures? Or should you get started immediately?
Oscar: The earlier you start, the better. The earlier you start, the better, as you gain a deeper understanding. Having two standards is a pretty good situation. Both ISO and Cyclone DX standards are good to work with. Cyclone DX is a little bit more developed; the company has tighter specifications. This market will mature quickly, and it probably doesn’t matter which standards you’re going with. There are many areas where there are multiple standards. For instance, APIs, there’s SOAP and REST, etc. That didn’t stop people from developing API’s, right?
Delan: Is it problematic to make SBOMs public?
Oscar: There are different views on that. Some organizations are very cautious with what they publish because they think that if they disclose what libraries make up their application, they relinquish some IP or make it easier for hackers to attack their software. I’m not sure about the IP, but I think you could make a case for making it easier for hackers. But we are kidding ourselves to believe that attackers don’t have the capability of analyzing these applications themselves already. Making the SBOM public and effectively creating transparency is a much more powerful tool.
Transparency is a much more powerful tool to help reduce risk than disclosing secretive information because it’s not so secret. It’s relatively easy for adversaries to get that information anyway. So it’s more powerful to manage the risks for your potential buyers. There might be limited exceptions to this, like in security services.
Delan: Do you expect to see SBOMs become mainstream across various industries, or do you expect that it will continue to be limited to sectors where regulations are essential?
Oscar: It’s already applied in industries beyond regulation. It will play an essential part in the B2B markets but not as much in B2C. If consumers buy a gadget, they are not looking for a software bill of materials. But if a company purchases an application that substantially impacts its risk level, they want tools to manage that risk.
Delan: Why did SBOMS come about?
Oscar: There is a gap from a risk management perspective where, traditionally, software vendors would ship their software and have license agreements that say they are not liable for virtually anything. The buyer who gets that application is exposed to the risks of the vulnerabilities in the software but doesn’t have information about what’s in the application. They had no tools to manage their risk and gave up. The result is that nobody managed risk, causing a tenfold increase in software supply chain attacks over the last two years. Adversaries are massively exploiting the gap. That is the main reason we need to close that gap.
Delan: So, the trend closing that gap is due to events like the solar winds attack.
Oscar: Yes, this attack impacted global security a few years ago. US national security interests pushed this to the forefront for many people—60 or 70% of B2B companies who want to use SBOMs over the next few years. Beyond those requiring regulation, big industries also want to use SBOMs to minimize their risk.
We needed regulations because there’s much reluctance for software vendors to move in this direction. After all, they don’t want to take any liability, and they also don’t want to disclose what is in their application. Regulations are needed because they force software vendors to disclose information and become a common practice.
Delan: Oscar, thank you for talking to me today. We’ve learned a lot about SBOMs and how they are helping us make well-informed decisions about critical software security measures.
