When only one SBOM will do, consider these formats

A software bill of materials (SBOM) is a tool designed to share detailed information on code components in a standardized way. The SBOM has become an increasingly important tool for both application security purposes and governmental compliance. 

To minimize inconsistencies and encourage greater transparency, three primary SBOM formats have emerged, each of which allow companies to generate, share, and consume supply chain data. Before you choose, it’s important to understand what the current SBOM format options are and how they are best suited to you.

Here, we’ll explore all three formats – SPDX, CDX, and SWID – share their attributes and weaknesses, and offer guidance to help you find the perfect match. 

First, let’s discuss why there are so many different formats. The simplest reason is that guidance around the use and requirements of SBOMs is still quite new. While SBOMs have been around for a while, it was less than two years ago that the software bill of materials was advanced by NIST in accordance with the Biden administration’s Executive Order on Improving the Nation’s Cybersecurity. Since then, government agencies have released guidance that increasingly requires SBOMs. That, combined with ever-expanding use of open source software components, will drive increased SBOM adoption and subsequently greater demand for a standardized format. Until that time, organizations have three predominant formats to choose from.

Software package data exchange (SPDX)

What is it? SPDX is a data exchange format created to easily share information about software packages and related content including components, licenses, copyrights, security references, and other metadata. It is intended to save time and improve data accuracy in support of supply chain transparency.   

What are its origins? SPDX is authored by the SPDX workgroup, a community driven project supported by the Linux Foundation. 

What are its best features? Using a standardized, machine-readable format ensures consistency across different organizations and reduces the need to reformat information, makes it easier to share, and consequently improves compliance and security efficiency. 

Its size and capacity make it a particularly flexible option. One of its biggest strengths is the ability to provide a detailed big picture of your software supply chain, components, and dependencies.  SPDX identifies the software package, package level, file-level licensing, and copyright data, and also shows the file creator, and when and how it was created. This allows for a multiplicity of annotations and the most detail of the three formats. 

Of the three main SBOM formats, SPDX is the largest and most robust and is the only format with an ISO (International Organization for Standardization) accreditation. 

Potential weaknesses: There aren’t really any notable weaknesses with this all-inclusive format. 

Best suited to: Primarily designed to improve license compliance, SPDX is typically used by large, complex organizations. Linux users naturally tend to adopt SPDX, and it is preferred by those that build commercial software or operate enterprise software. SPDX adoption is growing significantly as the use of open source projects increases. 

CycloneDX (CDX)

What is it? CycloneDX is a full-stack bill of materials standard.

What are its origins? CycloneDX is backed and maintained by the OWASP Foundation. 

What are its best features? A main differentiator of CDX is its broad support of various specifications including SBOM, Software-as-a-Service Bill of Materials (SaaSBOM), Hardware Bill of Materials (HBOM), Operations Bill of Materials (OBOM) and VEX use cases. The format identifies BOM metadata, components, services, dependencies, compositions, vulnerabilities, and extensions.

The CycloneDX format provides standards in XML Schema, JSON Schema, and protocol buffers. The project also supports various community-supported tools and extensions that target specialized or industry-specific use cases. 

Like SPDX, there is strong community direction and development. Additionally, the involvement of the OWASP Foundation provides educational support opportunities which help to ensure continuous development and advancement of SBOM.

Potential weaknesses: CDX offers many of the same attributes and capabilities as SPDX but is not quite as robust. 

Best suited to: Preferred by nimbler organizations and by teams that use open source heavily, CDX is more agile and easier to use than SPDX. 

Software Identification Tags (SWID) 

What is it? SWID is an industry standard that allows organizations to track the software inventories installed on managed devices with a simple, easy-to-use format. SWID tag files contain descriptive information about a specific release of a software product, including an end tag to define the product lifecycle. There are four types of SWID tags: 

1. Primary Tag: Identifies and describes a software product installed on a computing device. 
2. Patch Tag: Identifies and describes an installed patch that has made incremental changes to a software product installed on a computing device. 
3. Corpus Tag: Identifies and describes an installable software product in its pre-installation state. It can be used to represent metadata about an installation package or installer for a software product, a software update, or a patch. 
4. Supplemental Tag: Allows additional information to be associated with another SWID tag to ensure Primary and Patch Tags provided by a software provider are not modified by software management tools, while allowing these tools to provide their own software metadata.

What are its origins? SWID was created and is maintained by the National Institute of Standards and Technology (NIST).

What are its best features? Because SWID’s primary purpose is inventory, it is far less complex than SPDX and CycloneDX and therefore is faster and easier to use. 

SWID is widely used by standards bodies such as the Trusted Computing Group (TCG) and the Internet Engineering Task Force (IETF). 

Potential weaknesses: Its capabilities are limited, and it doesn’t provide details such as vulnerability information, annotations, or license information. 

Best suited to: For organizations that want to create an inventory of software components and dependencies quickly and easily, SWID is a good option. 

Which SBOM will you choose?

Each of these three formats serve the purposes of an SBOM though some offer additional capabilities that go beyond those requirements. Before making your choice, consider your organization’s specific needs. For example, organizations in highly regulated fields, e.g., financial services or healthcare, and most government agencies require a greater level of granularity and detail than may be available with the SWID format. This may also be the case in an M&A situation. However, a simple format may be enough to provide peace of mind to a prospect or customer.

No matter which format, or combination of formats, you choose, there’s no doubt SBOMs will play an increasingly important role in the development and security of software and the software supply chain. To ensure your organization is ready, it’s important to get started with an SBOM today.

 

The post When only one SBOM will do, consider these formats appeared first on SD Times.

from SD Times https://ift.tt/dWhUBrZ