Software Transparency: Software Bill Of Materials (SBOM) and SPDX

Bumped into the SBOM concept via this HN discussion. Defined by OWASP it is a method to help with Software Transparency:

Software Bill of Materials (SBOM)

Multiple efforts between government and industry are attempting to define Software Transparency. Some of these efforts will lead to increased compliance or regulatory requirements. Software Transparency is often achieved through the publishing of software bill of materials. An SBOM is synonymous to the list of ingredients in a recipe. Both are an implementation of transparency.

There are multiple SBOM standards including OWASP CycloneDX and SPDX, each having their own strengths and use-cases they were designed to solve. Evaluating SBOM standards to determine which are applicable to an organizations requirements should be part of an overall C-SCRM strategy.

Many of its uses relate to monitoring the security aspects of a project. OWASP offers a well-known open source project

OWASP Dependency-Track is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain. Dependency-Track takes a unique and highly beneficial approach by leveraging the capabilities of Software Bill of Materials (SBOM).

Dependency-Track is an open source platform that allows organizations to operationalize the use of SBOM. It’s intended use cases are for:

  • DevSecOps
  • Procurement
  • Monitoring & Analytics

The Software Package Data Exchange® (SPDX®)

SPDX is an open source project and ISO standard managed by the Linux Foundation. From the About page:

SPDX is an open standard for communicating software bill of material information, including provenance, license, security, and other related information. SPDX reduces redundant work by providing common formats for organizations and communities to share important data, thereby streamlining and improving compliance, security, and dependability. The SPDX specification is recognized as the international open standard for security, license compliance, and other software supply chain artifacts as ISO/IEC 5962:2021.

Guiding principles:

  • SPDX represents data in formats that are both machine- and human-readable.
  • SPDX focuses on collecting and communicating facts; and provides a framework to make assertions about those facts.
  • SPDX makes no legal interpretations (of licenses or license compliance).
  • SPDX facilitates the efficient exchange of metadata in the supply chain.

SPDX Introduction

Companies and organizations (collectively “Organizations”) are widely using and reusing open source and other software packages. Accurate identification of software is key for many supply chain processes. Vulnerability remediation starts with knowing the details of which version of software is in use on a system. Compliance with the associated licenses requires a set of analysis activities and due diligence that each Organization performs independently, which may include a manual and/or automated scan of software and identification of associated licenses followed by manual verification. Software development teams across the globe use the same open source packages, but little infrastructure exists to facilitate collaboration on the analysis or share the results of these analysis activities. As a result, many groups are performing the same work leading to duplicated efforts and redundant information. With this document, the SPDX workgroup has created a data exchange format so that information about software packages and related content may be collected and shared in a common format with the goal of saving time and improving data accuracy.

SPDX v2.2.1 Ontology

The SPDX specification defines a Linked Data (RDF) ontology to describe software artifacts:

SPDX Open Source Tools

There are many community-created Open Source Tools that support SPDX. Specifically worth mentioning is this match with the FSDL:

1 Like

I added Software Transparency to the wiki post brainstorming components of the FSDL.