In a previous post, we discussed whether a Software Bill of Materials (SBOM) can really make a difference from a cybersecurity standpoint, and the answer is a resounding “yes.” However, while an SBOM provides lots of the information organizations need to know about the components of the software products they buy and use, such a list by itself is not enough. For the SBOM to be really effective, they need to have context as well. Not all software products or vulnerabilities are equal.

We’re hearing more and more about a Software Bill of Materials (SBOM) as a vital tool for increasing software security. With the federal government pushing the idea, there’s no doubt it will remain newsworthy. One of the key questions about SBOMs is will they really make a difference? And how will they make a difference?

Jitsuin met Meterian in the NCSC Cyber Runway Accelerator launched in November 2021. What we quickly realized is that automated generation and permissioned sharing of SBOMs would save valuable time in vulnerability discovery and mitigation. So we moved fast to fix things! The integration between Meterian’s Boost Open-Source Software Scanner (BOSS) and Jitsuin’s RKVST SBOM Hub enables software publishers to automatically generate, store and distribute SBOMs in public or private.

The whole point of an SBOM is lost if you keep it a secret. Here we reveal our secrets of the ideal SBOM exchange. Let us know if we’ve missed anything in RKVST SBOM Hub. SBOMs are made for sharing and are the gifts that keep on giving, but only if they get to the right place at the right time to drive the right critical decision. The first critical decision, or moment of truth, is whether to buy a vendor’s product.

Just like you’d find all the ingredients on a package of food, a software bill of materials is a list of all the components contained in a software product. Vendors typically create these bills to describe what the components are. In addition, a Software Bill of Materials also includes information about these components’ dependencies and their hierarchical relationships.

The timing of CISA’s SBOM-a-rama today and tomorrow coincides with the fallout from the “vulnerability of the decade” gifting the industry with yet another example of why scaling and operationalizing the widespread use of SBOMs is so vital. Log4Shell is a 10/10 vulnerability in a hugely popular Java logging library – Log4j – used in virtually every online service. For two decades it was considered harmless, that is until last week when somebody found it wasn’t.