It’s been a year since US President Joe Biden issued Executive Order 14028, “Improving the Nation’s Cybersecurity”, published after the SolarWinds attack (one of the worst data breaches in the last decade). The executive order provides a set of requirements as well as a timeline for strengthening the security of the apps built and used by federal government agencies. It puts cybersecurity front and center.

There are various measures and dimensions to improving cybersecurity posture, but one aspect that the executive order focuses on is better preventing attacks on software supply chains. Like physical supply chains, the software supply chain is the process by which the essential materials or building blocks of modern software come together to create the applications that we rely on today–and much of that relies on open-source, third-party software, and packages. In order to know just how secure we are, we have to learn “how the sausage is made.” This means knowing about the complex network of dependencies that your software runs on, and then, if you want to be comprehensive about it, knowing just what dependencies the dependencies have–because that just might be where the weakest link is. 

President Biden’s executive order mandates that if you are working with federal agencies, you have to provide them with a Software Bill of Materials (SBOM), a critical tool for improving software supply chain security. The SBOM, like the nutritional labels that you find on food and drink items at the supermarket, is a thorough inventory of all your software dependencies–all the “ingredients” that comprise your applications and products. And per the executive order, you have to disclose this type of information to the purchaser directly, or else publish it online for those that should have access to it. 

But the SBOM is more than just a list of software packages.  Critically, the SBOM has to make it clear what vulnerabilities exist in your applications or products. If we are to be more efficient at identifying and remediating vulnerabilities, we need to know exactly what problems exist, and where they might be found. And if we are going to really rely on SBOMs, this necessitates that SBOMs have to be machine-readable, as well as support automation and tool integration. That is, it has to be integrated into the software development lifecycle, rather than being a tedious afterthought.

So what, exactly, goes into the SBOM? The US Dept of Commerce released a list of baseline components that have to be in the SBOM for it to be considered a legitimate SBOM file. This includes data such as the SBOM authors’ names, the various component names, version strings for all the various packages, relationships between the various packages in the software (dependency relations), and a timestamp for the generation of the SBOM.

That’s the basics. But for this to work well, we not only need this data, but we need “predictable implementations and data formats” for the data. Currently, there is no one SBOM format to rule them all, but perhaps the closest we’ve come so far is the Software Package Data Exchange (SPDX) format, which, as of August 2021, is now an official standard (as ISO/IEC 5962).  Being official bodes well for the global adoption and promulgation of SPDX–it goes without saying that software knows no borders, just as it goes without saying that having varying standards and formats can be the bane of digital existence when it comes to communicating and exchanging vital information.

Still, there are other formats and documents in this space–such as OWASP’s Cyclone DX, as well as other SBOM-like concepts, such as the  Vulnerability Exploitability eXchange (VEX) document.  The US Cybersecurity & Infrastructure Security Agency (CISA) defines VEX as “an attestation, a form of a security advisory that indicates whether a product or products are affected by a known vulnerability or vulnerabilities.” But to make sense of VEX, we have to consider what problem it’s trying to solve. 

An SBOM can tell you what vulnerabilities exist in the code, but it doesn’t tell you in any kind of real-world way which of those vulnerabilities might affect the functionality of your software or the safety of your digital assets and data. It is entirely possible for a vulnerability to exist but not affect anything mission critical in your code or infrastructure–in other words, it’s a false positive, and too many of those affect the speed and motivation of those tasked with remediating vulnerabilities. 

VEX documents are just statements to this effect; they classify vulnerabilities into categories, such as those that are “known but not affected”–meaning that we know it’s there but it doesn’t affect the product–or “known affected”, meaning that it’s there and yes, it could very well affect the product or the infrastructure, and you might need to do something about it.

You can think of the VEX as a remediation-centric “companion artifact” to SBOMs that “conveys the degree of exposure or exploitability”, i.e. the real-world risk of using this particular software or application. 

RKVST 

For all of us whose business runs on a bevy of applications and technologies–and that’s increasingly, most of us–having more governance and visibility into the components that comprise that critical software is no longer a luxury. It is not just the US government that has to worry about identifying, evaluating, and remediating software vulnerabilities before the cost becomes prohibitive or the damage irreversible.  

Yet the prevalence of SBOMs is still startlingly low. 

SOOS Core SCA (Software Compositional Analysis) finds and reports the open source vulnerabilities in your applications, while SOOS DAST finds vulnerabilities that exist in a live, running application–simulating the kinds of the real world threats we face from hackers and other malicious actors. However, we recognize that improving the security of the software supply chain is a cooperative and collective effort, which is why we make it easy for SOOS users to generate SBOMs in a variety of formats. Still, we need to be able to store and share these SBOMs as widely as possible, with as few bureaucratic hurdles (and clicks) as possible. 

That’s where RKVST comes in. The RKVST SBOM Hub is a free service that makes it “easy to discover, store, and publish SBOMs to meet the foundational requirements of the executive order.” And now, the SOOS partnership with RKVST means that you can publish and share your latest SBOM data directly to RKVST from right inside the SOOS app. 

At a recent Open Source Software Security Summit in Washington, DC, the Linux Foundation and Open Source Security Foundation (OpenSSF) came up with a mobilization plan that, among other things, sums up the importance of SBOMs to our cybersecurity future:

“The more ubiquitous SBOMs are, the more valuable they can be to the industry. Generally, we believe that SBOMs should be produced automatically via well-vetted tools every time that software is built or distributed… To get to the point where SBOMs are ubiquitous in software distributions, we need to remove all friction for adoption.”

We couldn’t agree more.