In the past few years, people have become increasingly aware of the inherent risks of using open-source components in their software. Considering that most software is a mix of open source and proprietary logic, knowing what ingredients were imported from the outside, directly or transiently, is essential for proper risk management of the final software product. Since the days of tracking ingredients using complicated spreadsheets are long gone, and woefully inefficient to boot, the main way to accomplish such tracking is by utilizing an SBOM – a software bill of materials. Like other bills of materials, it’s essentially a list of the software ingredients the software is built from with the addition of the relationships between different ingredients with a special focus on what components are dependent on each other.
There are two major SBOM formats used in the market today: SPDX and CycloneDX.
Software package data exchange (SPDX) is an open-source, machine-readable SBOM project by the Linux foundation. The latest version of the SPDX was designed in line with the NTIA’s standard for ‘Minimum Elements For a Software Bill of Materials.’ It lists the components, copyrights, licenses, and security references of a piece of software.
CycloneDX (CDX) is also an open-source and machine-readable SBOM format developed by the Open Web Application Security Project (OWASP) community. As a BOM format, CycloneDX has other applications beyond the preparation of software bills of materials. It can also be used to compile components, vulnerabilities, and services of hardware and cloud systems.
Why is SBOM important?
The SBOM is extremely useful to software development teams, purchasing organizations, and end users. Using it can help guarantee that open-source and third-party components are up to date, and offers visibility into what project dependencies have known vulnerabilities that might be exploitable in your software. Software buyers, on the other hand, can utilize SBOMs to analyze the risk inherent in a product through vulnerability assessments.
Organizations would be better served by collaborating with their vendors to ensure that they have access to correct and up-to-date information on the project components that are implemented into systems and/or products. They should also evaluate their SBOMs regularly to help minimize the risks of utilizing open-source and third-party components.
SBOM samples
Depending on the SBOM format you utilize, there might be differences in the components of the SBOM. depending on the size and complexity of your project an SBOM JSON file can easily get to thousands of lines or more. Since looking at a thousand-line file isn’t very informative, let’s use existing, simpler, examples to see what each SBOM format includes. We’ll take a closer look at samples from the two major formats on the market today.
SPDX
The SPDX SBOM sample we’ll be following can be found here.
The JSON starts with general information about the file itself – metadata.
After that, we get the metadata about the software we’re examining:
Notice the checksum and its value. Each section of the SBOM includes the encryption and result of the part in question so that people examining the file can be sure that the software or component mentioned is identical to the one they are looking at.
Without that guarantee, you could easily find multiple copies with the same name of components or software and you’d have no idea which of these versions was checked or included in the software or the SBOM describing it.
Following the description of the software checked we can start seeing the components:
You can see multiple fields included to describe the license of a component, its homepage, version, full name, etc.
One other thing you can find in an SPDX format is annotations – additions made at a later time to a section and include more information and sometimes even free text:
To learn more about this format and its capabilities, you can visit the SPDX page of the Linux Foundation.
CycloneDX
The CycloneDX SBOM format can be described in a JSON file, an XML file, or in protocol buffers. To keep things even and simple we’ll follow a simplified CycloneDX JSON example. The example described can be found here.
The JSON starts with general metadata information about the file.
Then the metadata on the software examined:
After that the software components and their dependencies:
Bear in mind that this is a simplified example and that the format may include a lot of other information. For a more comprehensive look at various use cases, you can check out the OWASP CyclonDX use-cases page here.
Here’s an example from that page demonstrating the build of a list of dependencies:
And here’s a more overreaching description of the various components of this format taken from the OWASP BOM capabilities page:
How to use an SBOM
Don’t feel bad if you can’t follow along with the file examples seen here. Even though JSON files are eminently readable by humans, they are far more suitable to be machine readable so that specialty-made software can ingest the information and spit out the results the analysis provides.
You can use a list of software components to check that it includes no unwanted open-source licenses (line GPL3.0 or MPL1.1). You can check a list of dependencies regularly to see if there are any available updates, or check the package names against vulnerability databases to know what problematic dependencies your software includes.
It may sound complicated to ingest an SBOM and get all that information back but remember that you don’t have to do it all yourself. Services like the Scribe Security platform can remove a lot of the headaches and offer far more benefits. Feel free to check out our platform and see how else you can manage your risk using our continuous monitoring system over your development lifecycle and final products.