Dear CEO and BOD Member: An SBOM Primer From Your CTO

Julia Fleenor Avatar

Your business may depend on this four-letter acronym in the next few years. Here’s a quick guide to SBOMs, why they matter so much for the integrity of your digital supply chain, and what we as a business need to do about them.

Dear CEO:

As your Chief Technology Officer, I wanted to bring your attention to an important concept called Software Bill of Materials (SBOM). I’ll explain what it is, why it matters for our business, and the steps we should take to ensure we are implementing it effectively. This should be a top priority because customers are starting to ask for it and in the near future, companies that can’t produce an SBOM will be considered security risks. Are you paying attention now? 🙂

An SBOM is a comprehensive inventory of all the software components, dependencies, and libraries used within a software product. Imagine if the software we use to run our business was a car, made up of components from many suppliers. And each of those suppliers has its own suppliers and so on and so on. The nesting might even go six levels deep!

In the car business, car companies closely track who makes anything that goes into their vehicles because, well, people could die if something went wrong. In the software business, that has not been the case. Until now. And that’s where the SBOM comes in. In May 2021, the U.S. Government posted an Executive Order with a number of big asks for national cybersecurity. That order set a strict timetable for some conditions that will be required of any company doing business with the government. Among those steps are “…providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website;” In other words, the clock is ticking.

You might ask, don’t we already have one of these SBOM things? The answer, most likely, is, not really. In survey after survey, CTOs have copped to the reality that they don’t know or can’t provide an inventory of every software dependency in their technology stack. That’s because it’s super messy and complicated, and constantly moving. Imagine if that car was made up of parts that are constantly changing even as the car is on the road, with the manufacturer switching out old parts for new parts and old suppliers for new suppliers constantly. That’s the challenge of building an SBOM. Yes, my team (and our developers) made efforts to understand what was in our software. But it is a grinding, manual process finding all the details (versions, licenses, dependencies) of every single software component.

Why the SBOM Matters

The good news is there is rapidly improving tooling that will at the very least automate the discovery process for what software we run, so we won’t be flying blind. As a CEO, I also wanted to make sure you understood the business reasons why an SBOM matters, beyond the fact that we will need one to sell to the U.S. government. 

  1. Security: An SBOM allows us to identify and track any vulnerabilities in our software components. If a security issue is discovered in a specific component, we can quickly assess whether we are using that component and take appropriate action to fix it.
  2. Compliance: SBOM helps ensure that we are in compliance with various regulatory and legal requirements. By having a detailed inventory of our software components, we can verify that we’re using only licensed, approved, and secure components.
  3. Risk management: Understanding the dependencies and relationships between software components helps us manage potential risks. If we know that a particular component has security issues or is no longer being maintained, we can replace it with a safer alternative.
  4. Transparency: Providing an SBOM to our customers demonstrates that we prioritize transparency and security. It builds trust with our customers and partners, as they can verify that we’re using secure and reliable components in our software.

SBOM Action Items

I wouldn’t bring this to you if I didn’t have some sort of plan in mind. We are already testing a few tools to make it easier to generate and track SBOMs. That said, we need to codify the SBOM as a critical initiative and vehicle for our technology governance and guidance going forward. I would like to elevate this to report at the Board of Directors level and also to send you regular reports on our SBOM progress. To break it down into baby steps, I propose the following:

  1. Implement an SBOM process: We need to establish a formal process for creating, maintaining, and updating our SBOM. This includes documenting all software components, their versions, and licensing information to the best of our ability with the goal of a fully automated SBOM generation process that we can run at any time.
  2. Educate our team: We should provide training to our development and security teams, ensuring they understand the importance of SBOM and their responsibilities in maintaining it. Most know a bit about it but many are not deeply educated. If they understand it, they will be able to reduce our risks and use the SBOM to better understand how their actions impact our security posture.
  3. Integrate SBOM into our development lifecycle: We should make the SBOM an integral part of our software development process. This means updating the SBOM whenever there’s a change in our software components or dependencies and running the SBOM as part of our regular work in building software. 
  4. Monitor for vulnerabilities: Establish a system to monitor our software components for any known vulnerabilities or security issues. This will enable us to act promptly when a security issue arises. Of course, we are doing this at a higher level using various code security tools. But doing this at the SBOM level means embracing a different level of granularity and complexity that maps dependencies and components all the way back to their molecular unit
  5. Communicate with our customers: Inform our customers about our commitment to transparency and security by providing them with our SBOM. Trust me — many of them will ask for it very soon. Having one ready helps build trust and showcases our dedication to delivering secure and reliable software.

I hope this explanation clarifies the importance of implementing an SBOM in our organization. I’m confident that by taking the necessary steps, we’ll not only improve our software security but also strengthen our business viability and improve our ability to grow revenue in what is likely to be both an increasingly competitive and risky environment. Let me know when you are ready to discuss this further.

Best regards,

Your CTO

Tagged in :

Julia Fleenor Avatar