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:

• Requirements vs. optional fields

• Complete lack of provenance consideration

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:

1. Identify all software components used as dependencies. This is at minimum dozens and at most tens of thousands of individual software components.
2. Identify all the potential security issues. This includes a security audit of a product and all of its dependencies.
3. Investigate each potential security issue and determine ACMECorp’s response, which will range somewhere between “we have to fix this now” and “not applicable.” The resulting analysis from the software security team charged with performing this work will inevitably meander through teams of lawyers to determine exposure and risk. This is crucial, because ACMECorp will need this information to:
4. Stand up a new department to handle the barrage of inevitable questions and challenges from Clients to the responses developed.
5. Release SBOMs to Clients with as little detail as possible to protect intellectual property and limit exposure.
6. Do the entire process again for every version that is released, in perpetuity, and keep historical records.

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.

To read the complete article, visit Dark Reading.