Share your software bill of materials safely with Meterian and RKVST SBOM Hub

26 Jan 2022

We’ve been a little busy with some forward thinking security SBOM-meisters over at Jitsuin in recent months. If you’ve not heard of them, they came up with the clever idea to provide a secured system that lets software producers and consumers share software bills of materials (aka SBOMs). Not only does this make it easy to lookup any particular component that has gone haywire or needs to be summoned for review, it also enables fast and easy sharing of such information with your trusted parties. The major benefit of their service is that this adds to the trust and transparency of shared systems. Think about those moments when a critical vulnerability is announced and you need to alert the team (inside/outside your organisation) to find it asap, or when you have to complete an audit. It’s a big benefit in time saved for the effort needed to take action quickly. Searching and trumpeting attention through the software supply chain of interconnected devices and systems will be simpler with your software bills of materials stored on RKVST SBOM Hub.

Learn more about how to create your SBOM on Meterian and get in touch to benefit from the Meterian and RKVST SBOM Hub integration.

Video of automated creation of software bill of materials and safe storage for secure sharing

Abridged press release below.

Jitsuin and Meterian integration automates production and secure distribution of SBOMs

Partnership an early success of Cyber Runway Accelerator launched in November 2021

London, UK and Santa Clara, USA. 26th January 2022. Jitsuin Inc, a pioneer in continuous assurance of critical assets, and Meterian, a leader in software automation and vulnerability detection, have teamed up to offer software publishers automated creation and secure distribution of Software Bills of Material (SBOMs). 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 their SBOMs in public or private.

Meterian’s BOSS Scanner is a vulnerability detection and risk management system that delivers comprehensive component licensing and security control while automatically generating SBOMs. Jitsuin’s recently launched RKVST SBOM Hub is the first shared repository for publishers and subscribers to find and fetch the SBOMs they need. The integration of these two products allows software publishers to easily store, retrieve, publish and distribute SBOMs with full governance.

  • Developers, InfoSec and Governance Risk & Compliance teams can collaborate to mitigate vulnerabilities.
  • Authorized SBOM consumers can automatically retrieve the latest updates with full provenance and immutable history.
  • SBOM consumers can act fast on the latest data knowing it is trustworthy.

View source version on: https://www.businesswire.com/news/home/20220126005697/en/Jitsuin-and-Meterian-Integration-Automates-Production-and-Secure-Distribution-of-SBOMs

Share your software bill of materials safely with Meterian and RKVST SBOM Hub

An introduction to the world of SBOMs

3 minute read

We are sure many of you have been hearing about SBOMs. Nowadays, software include some components with code written by your own developers, but 80-90% of the code is typically from third-party developers. How can you know who produced what and when it absolutely needs to be replaced? Since Meterian has been managing SBOMs for awhile, we’re happy to share our know-how so you can consider a comprehensive strategy to manage your open source software supply chain. 

Photo by Raymond Rasmusson on Unsplash

What is an SBOM?

SBOM is an acronym that means Software Bill Of Materials. The concept originates from the manufacturing industry, where a bill of materials lists dependent components in machinery. A SBOM lists all third-party components present in your application. A good SBOM also lists the licences used by each component and, when possible, the specific copyright attribution. An excellent SBOM can also provide further information, such as possible relationships between those components to better understand any supply chain risk. You may have encountered SBOMs in the past, known as “third party notice” documents created to manage legal requirements, such as the one in the image below. 

Altova Third Party Software License Notice

However, modern SBOMs are “machine-readable”.  They follow a strict specification that can be understood by a computer. 

What machine-readable formats are used to publish SBOMs?

The most commonly used formats to define a SBOM are:

  • CycloneDX, a lightweight open-source standard designed for use in application security context and supply chain component analysis. This originated from within the OWASP community.
  • SPDX, an open source format with origins in the Linux Foundation, slightly more complex, and recently approved as ISO/IEC standard in version 2.2.1 as ISO IEC 5962:2021.
  • SWID, another ISO/IEC industry standard used by various commercial software publishers.

All these formats support a variety of use cases, but the first two (CycloneDX and SPDX) are the most versatile. Due to SPDX’s complexity, we think CycloneDX has an edge at this time, but only time can tell which of these formats will be the winner. To learn more about these formats you can also read the official NTIA publication, which drills down into the matter.

Why are SBOMs important? And how are they useful?

As a consumer of software, the main reason why you want to have access to the SBOMs of the systems you are using is to manage risks. When a very commonly used software component becomes vulnerable: how do you know what you need to patch and which subsystems are at risk? This is exactly what happened with the recent Log4Shell debacle. The logging library called Log4j, was suddenly exploitable with a very simple and repeatable attack. How do you know where it is? Which one of the systems you are using is suddenly at risk?  With a correctly managed archive of SBOMs, getting this information reduces to a very simple lookup task. Without it, it can be a real nuisance —a time consuming information hunt that disrupts everyone’s work flow.

As a producer of software, instead, you want to preserve and maintain an archive of all the SBOMs of the system you produce so that you can create and distribute timely patches to your customers. Having a systematic and comprehensive analysis of your most commonly used software packages would be useful indeed. Some companies were very fast in releasing patches to their customers, while others were extremely slow, mostly because they did not have the information.  You probably want to be in the first group of companies 🙂

Governments are also mandating the need for use of SBOMs, realising that software security needs to be regulated.  The U.S. Executive Order 14028 that mandates all federal agencies to require SBOMs from their suppliers.  This not only impacts the companies that have direct sales to the US government but also their own software suppliers.  As so many systems and devices have been connecting to the Internet to send and receive information, consequently our digital world relies on a software supply chain.  This “ripple effect” will be significant for many industries. 

It’s important to consider how software products you produce can meet basic security requirements and how the associated software security information is produced and managed in your organisation.   Similar legislation has already been proposed in Europe since the publication of  “Guidelines for securing the IoT” by ENISA (hint: SBOMs are required) and the ETSI EN 303 645 global standard for consumer IoT security, which is based on the UK government’s Code of Practice.  See also the recently published Product Security and Telecommunications Infrastructure (PSTI) Bill and more to come from the UK government to improve the UK’s cyber resilience.

How should SBOMs be handled?

Very carefully :), because an SBOM contains the full list of the “ingredients” of your system or application. While open-source projects happily share this information to the world, the same does not apply to private companies. In fact, a malicious actor that gets hold of the SBOM of your system can then check if you are using any vulnerable components. There are public vulnerability databases, such as the NVD, which are very popular. Someone can simply browse in there and compose a list of possible attacks, try them, and maybe get lucky.  Probably 9 out of 10 vulnerabilities affecting components in your system won’t be exploitable, but having the ability to go through the whole list, certainly makes the task of finding an exploit much easier. 

There’s no need to keep SBOMs a complete secret, however, as long as a few simple principles are kept in check:

  • SBOMs need to be shared securely,
  • they need to be accessed only by the authorised parties, across organisational boundaries, and
  • they should not be tampered with.

In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.  

Why bother with SBOMs now?

In summary, it is essential to produce a precise SBOM, and it is just as vital to share it and maintain it securely with the correct (trusted) third parties.  In our hyper connected world, comprehensive coverage of components is important for preventative strategies and threat detection in supply chain attacks.  Therefore, implementing SBOM management proactively now will be worth something to your organisation when the next critical vulnerability appears and stand your organisation in good stead. All good collections are worth organising. How valuable is your collection of software?

Photo by Susan Q Yin on Unsplash
An introduction to the world of SBOMs