Communicating the Value of Your Company With SBOMs

A Software Bill of Materials (SBOM) is a detailed, machine-readable, nested list of all of the third-party components and their dependencies that compose a modern software product. SBOMs have particular importance in the health, finance, critical infrastructure, and military sectors, and in mergers and acquisitions, but all industries and applications can benefit from them. SBOMs have been around for over a decade but they’ve gained serious traction in the wake of the SolarWinds breach. Governments are already requiring them from their contractors and corporations are following suit. If you haven’t been asked to hand one over yet, you will be.

But even if no one was asking you for an SBOM, knowing exactly which components are in your software is a major benefit to the security of your organization. When the next zero-day vulnerability hits, you won’t be scratching your head wondering where an affected package sits in your codebase, what applications it affects, or whether you even have that package in the first place. Sure, there’s more to staying secure and understanding your code than just generating an SBOM, and an SBOM is not the same as an inventory, but it’s a step in the direction of having clear visibility into your product.

Your customers deserve that clarity, too. Handing over an SBOM, especially in these still-early days of adoption, sends a strong signal that your organization is transparent, responsible, and secure, and it reassures customers and regulators that you are actively managing risks. Here is some advice on how to deliver that message.

Be secure

This one is basic but it has to be said. Simply handing over any SBOM isn’t going to communicate that your company has a serious and mature security program if you have major outstanding security debt. In fact, it will give your customers visibility right into your vulnerabilities, and if things are really bad they may, and rightly so, decide not to buy from you after all. So you need to actually be secure to show that you’re secure. There’s no way around it. Transparency is the whole point.

If you’re a little behind the curve here, the fastest way forward is to implement a software composition analysis (SCA) tool that will make a detailed map of all of your open-source components, give you a scored and prioritized list of your vulnerabilities so you can remediate quickly in a worst-first fashion, and automatically generate an SBOM for you. Again, there’s more to security than any one tool or process, but when it comes to managing vulnerabilities and SBOM generation, SCAs give you a lot of bang for your buck.

Be early

Take the carrot before you get hit with the stick. Get your company’s SBOM program going now, even if it’s not yet required, to show your organization is dedicated to security and compliance and get the kudos you deserve for strong leadership. You’ll spend a lot more money getting that infrastructure in place at the last minute, and you may lose money if customers go to a competitor who is already prepared to demonstrate their transparency.

Do it now, even if you’re not required to, because eventually you will be. And if SBOMs are already required for your industry, maybe you can’t be early but you can at least be on time. And you can go above and beyond by following our next piece of advice.

Don’t send an SBOM alone

By itself, an SBOM is unlikely to give a complete picture of your strengths or the true state of your vulnerabilities. When your customer scans your SBOM for vulnerabilities and licensing issues, they will probably get results that look bad on the surface but aren’t of any actual concern. They don’t know your software like you do, so it’s important that you include other materials that fill in the knowledge gaps. 

One such supplement is a list of your open source licenses, particularly dual licenses that you have purchased the commercial license for. Your customers won’t know that you have commercial rights to use open source licensed components unless you tell them.

Vulnerable doesn’t necessarily mean exploitable. Another document to include is what the NTIA calls a “companion artifact” to the SBOM, the Vulnerability Exploitability eXchange (VEX) file. Created exactly for this purpose, VEX allows you to provide context for the vulnerabilities in your software and communicate that you are aware of them and have investigated whether or not they are actually exploitable.

To sum it all up…

In this age of increasing digital complexity and heightened security concerns, the adoption of SBOMs is not just a trend but a necessity. True, governments and corporations have begun to demand SBOMs, but the advantages they offer extend beyond compliance requirements; they fundamentally enhance the security, transparency, and trustworthiness of your organization.

Moreover, embracing SBOMs sends a powerful message to your customers and signifies that your organization is committed to transparency, responsibility, and security. Being early in adopting SBOMs earns you recognition for strong leadership. Delaying may cost your organization more in the long run, both financially and reputationally.

But again, merely generating an SBOM is not enough; you have to back it up with genuine security. Transparency is meaningful only when it reveals a robust and mature security program. Address your security debt and take proactive measures to secure your software and the SBOM you send will sing your praises.