This Will Be the Year of the SBOM, for Better or for Worse

Companies are facing two major truths this year: More cybersecurity regulation and fewer resources.

For the former, it's about time. Cybersecurity needs baseline requirements and government regulations can be a useful forcing function. It's encouraging to see a renewed focus on areas that need real attention, especially software supply chain security. Considering the latter, it means companies are facing a steep climb ahead to implement these new regulations in a year of economic uncertainty. Nonetheless, regulations are here, more regulations are coming, and companies need to adapt.

In a recent article, I discussed a few issues with the software bill of materials (SBOM) format as a standard, which includes:

But this year, the biggest hurdle will be adoption.

The Software Vendor Adoption Problem

ACMECorp is an example of a company that produces software products. We'll refer to one of its products as "Anvil" and its customers as "Clients."

Clients want ACMECorp to release its SBOMs for Anvil so Clients can understand if they're affected by software supply chain issues, vulnerabilities, or license risks. Clients also want to be able to understand quickly if they're affected as new issues arise.

Regulatory bodies want to require ACMECorp to release SBOMs so Clients can be better informed. ACMECorp may very well want to provide this information to Clients as well, but this is a massive undertaking.

For all software products, ACMECorp will now need to:

It's a heavy lift, but ACMECorp will need to have a version of the above (or at least a start to it) that it expects Clients to accept.

The Client Adoption Problem

Clients that wish to consume Anvil's SBOM (and hundreds or thousands of other SBOMs) now have a huge additional workload to adopt any technology.

Companies already have a vulnerability management problem, and this will multiply the burden. As SBOM is a self-reporting mechanism, Clients will not be inclined to simply rely on an SBOM as an authoritative source of truth. Instead, they will require their already overburdened application, product security, and legal teams to find ways to validate ACMECorp's SBOMs after each release.

Let's Aim for the Better

I'm bullish on the goals of SBOMs. We must have a complete, up-to-date inventory of components used in a software product. We must understand the implications of security events and issues and how they affect companies, governments, and users. My hope is that we can work together to build a far better process than we have with the current iteration of SBOM.

First, we must release ourselves from the idea that simply sharing data from vendor to customer will solve the challenges SBOM hopes to address. As I outlined above, it is guaranteed only to make additional work. Instead, we should think about how we can share attestations on software supply chain data.

Vendors want to show customers their products' security posture is well-defended. Customers want to have assurance that the security posture of third-party products and services aligns with their threat model and risk tolerance. These goals are achieved by interpreting the software supply chain data and answering questions relevant to the goals. The context around the data is key to these outcomes.

A huge amount of the security goals vendors and customers hope to answer can be codified, then constructed into policies that can be agreed upon by vendor-to-consumer relationships. The tests or attestations for these policies can be open source, with collaboration from both the security and development industries. This will allow open understanding of the value of the attestations, and their weaknesses that can be improved upon. It can give us a shared framework to interpret software supply chain risk.

Groups of attestations in the form of a policy can be quickly tested as vendors develop software to plan for the end-state requirements. Customers can use this to rapidly understand the software supply chain risk of a vendor's product. That might mean opting for an on-premises version hosted in a controlled environment, or contract requirements to better meet the needs of the customer, but it gives vendors and customers a common taxonomy to better align with each other.

Attestations and policies allow us to effectively build compliance directives in a way that vendors can manage through the product and software development life cycle. Changes to attestations can be scheduled and road-mapped without piles of meetings to coordinate individual issues. These compliance directives can be rapidly evaluated to understand regulatory impact, which we know to be on the horizon anyway. These attestations can extend to show transparency and provenance of the vendor data provided as input. Overall, this gives us the required common ground to build trust.

Finally, an enormous part of this process can be automated. We can much more effectively focus the time of our security and development teams where it's needed, instead of preparing and consuming a never-ending stream of SBOM data dumps.

Cheers to the year of the SBOM. We're all in this together.