This document “OpenChain Telco SBOM Guide” aims to outline certain requirements related to how an entity creates, delivers, and consumes Software Bill of Materials (SBOM), so that entities that produce and/or consume SBOMs that conform to this guide can ensure repeatability and streamlining of tools and processes for generating and consuming SBOMs. Please Note that this guide does not require a conforming entity to adopt OpenChain (in any version) but doing so is greatly encouraged.
This guide is designed to work on a per SBOM level: an entity can use it as its sole way of delivering SBOMs but it is the individual SBOM that the guide refers to, not the entity that provides the SBOM. An SBOM using this guide can be called “OpenChain Telco SBOM Guide Compatible.”
Releasing SBOMs that match the requirements outlined in this guide does not preclude an entity from also delivering SBOMs for the same software in alternate ways or formats.
This guide is licensed under Creative Commons Attribution License 4.0 (CC-BY-4.0).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Data Format means the data format of the information in the SBOM. Possible Data Formats include SPDX, Cyclone DX, SWID, or other proprietary formats.
Entity shall mean the legal entity (for profit, non profit, or natural person) that distributes software to third parties (e.g., other organizations or individuals). Entity does not include other group companies, or companies under common control of the Entity.
A Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of various components used in building software.
An SBOM can be of one of the following types:
- Design,
- Source,
- Build,
- Analyzed,
- Deployed,
- Runtime.
The definition of these types can be found in the CISA document.
SPDX (Software Package Data Exchange) is the ISO standard (ISO/IEC 5962:2021) for exchanging SBOM for a given software package, including associated license and copyright information. The standard was created by the Linux Foundation's SPDX project.
OpenChain means OpenChain ISO/IEC 5230:2020, the international standard that specifies the key requirements of a quality open source license compliance program in order to provide a benchmark that builds trust between organizations exchanging software solutions that incorporate open source software. The OpenChain standard is produced by the OpenChain project of the Linux Foundation.
Transitive dependencies are all components that are necessary for the software to run. They include any dependency of the package that is not a direct dependency.
Package URL (PURL) is a de facto standard to uniquely identify software packages.
An OpenChain Telco SBOM Guide compatible document SHALL adhere to the version 2.2 of the SPDX Data Format as standardized in ISO/IEC 5962:2021, or to the version 2.3 of the standard, and as further described below with respect to the included elements.
- ISO/IEC 5962:2021 Information technology — SPDX® Specification V2.2.1
- SPDX Specification V2.3
To ensure simplified handling and streamlining of tooling and competences in the telecommunications supply chain, both for suppliers and consumers of software, OpenChain Telco SBOM Guide Compatible documents shall adhere to the SPDX Data Format as standardized in ISO/IEC 5962:2021. By harmonizing on the use of this standard SBOM Data Format in an organization's external interfaces, the complexities for organizations supplying and consuming software are simplified, as only one set of unified requirements will be applicable.
As clarification, an entity is free to use alternative Data Formats for internal use, or deliver SBOMs in alternative Data Formats to organizations that so request or on its own initiative. The OpenChain Telco SBOM Guide is a SBOM-level specification to adhere to, and not an organizational specification to adhere to. There are no conforming entities, only conforming SBOMs, delivered by entities that have implemented the OpenChain Telco SBOM Guide.
The following elements are REQUIRED.
Document creation information
- SPDXVersion: mandatory in SPDX
- DataLicense: mandatory in SPDX
- SPDXID: mandatory in SPDX
- DocumentName: mandatory in SPDX
- DocumentNamespace: mandatory in SPDX
- Creator: mandatory in SPDX
- Created: mandatory in SPDX
- CreatorComment: to be able to put “SBOM Build information”
Package information
- PackageName: mandatory in SPDX
- SPDXID: mandatory in SPDX
- PackageVersion: needed by “NTIA SBOM Minimum elements”
- PackageSupplier: needed by “NTIA SBOM Minimum elements”
- PackageDownloadLocation: mandatory in SPDX
- PackageLicenseConcluded: mandatory in SPDX 2.2
- PackageLicenseDeclared: mandatory in SPDX 2.2
- PackageCopyrightText: mandatory in SPDX
One of the two attributes PackageChecksum or PackageVerificationCode is RECOMMENDED: recommended by “NTIA SBOM Minimum elements”
A package SHOULD be identified by a Package URL (PURL).
If the PURL is present, it SHOULD be put in ExternalRef field, e.g.
ExternalRef: PACKAGE-MANAGER purl pkg:pypi/[email protected]
Relationships between SPDX elements
- Relationship: at least DESCRIBES and CONTAINS, needed by “NTIA SBOM Minimum elements”
NTIA minimum elements
Recognizing the Telco industry need for harmonization and special requirements, the “OpenChain Telco SBOM Guide” is proposed to ensure predictability to the industry as to the elements of an SBOM that is expected.
“Component Hash” is recommended, but not required by the “NTIA SBOM Minimum elements”.
In SPDX, it maps to PackageChecksum or PackageVerificationCode. Most SCA tools have the capability to produce hashes.
The CISA document "Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Third Edition" https://www.cisa.gov/resources-tools/resources/framing-software-component-transparency-2024 allows both, see table in section 2.5.
Package URL (PURL) is a de facto standard to uniquely identify software packages.
An OpenChain Telco SBOM Compatible document SHALL include, at a minimum, SPDX in one of the following machine readable formats: Tag:Value or JSON.
Tag:Value and JSON formats are described here:
- in SPDX 2.2 https://spdx.github.io/spdx-spec/v2.2.2/conformance/#44-standard-data-format-requirements
- in SPDX 2.3 https://spdx.github.io/spdx-spec/v2.3/conformance/#44-standard-data-format-requirements
There are 3 majors formats for SBOMs: SPDX, CycloneDX, and SWID. These 3 formats are the ones recommended by NTIA document "The Minimum Elements For a Software Bill of Materials (SBOM)" (see References section).
The reasons for selecting SPDX as data format of the OpenChain Telco SBOM Guide include the following:
- SPDX is an ISO standard,
- SPDX has more features than CycloneDX for license compliance,
- SPDX has a human-readable format (CycloneDX has only JSON and XML),
- SWID is more a software identifier than a fully fledged SBOM format.
To facilitate a simplified toolchain, a machine readable version of the SBOM needs to be included. To ensure repeatability and harmonization a conformant SBOM must be in Tag:Value or JSON format. An entity can release additional machine readable formats but they are not required to conform to the Guide.
Tag:Value is the most human-readable format, and there are converters between the various SPDX formats (e.g. https://tools.spdx.org/app/convert/). JSON is a format produced by several tools.
An OpenChain Telco SBOM Compatible document SHALL include, at a minimum, the SPDX in one of the following machine readable formats: Tag:Value or JSON.
Tag:Value and JSON formats are described here:
- in SPDX 2.2 https://spdx.github.io/spdx-spec/v2.2.2/conformance/#44-standard-data-format-requirements
- in SPDX 2.3 https://spdx.github.io/spdx-spec/v2.3/conformance/#44-standard-data-format-requirements
As the Tag:Value format is also human readable it has been chosen so that both the requirements for a standardized machine readable and human readable version can be met using one file. An entity can release additional human readable formats but they are not required to conform to the OpenChain Telco SBOM Guide.
SBOMs conforming to the OpenChain Telco SBOM Guide MUST contain information as when they were created (using the SPDX Created field) and to which version of the software they were created (using the SPDX CreatorComment field).
The Creator field MUST:
- contain a line with the
Organizationkeyword; - contain a line with the
Toolkeyword; in this line we MUST have after theToolkeyword the tool name and the tool version.
The tool name and the tool version SHOULD be separated by hyphen ("-"), no other hyphen SHOULD appear on the line.
SBOMs conforming to the OpenChain Telco SBOM Guide MUST provide their SBOM Types as
defined by CISA
in the CreatorComment field.
SPDX standard
It is important to know which tool and which version of the tool have created the SBOM.
The SPDX standard gives "toolidentifier-version" as an example, but it is not mandatory to have this syntax.
For example, there is a tool that outputs:
Creator: Tool: sigs.k8s.io/bom/pkg/spdx
We have also:
Creator: Tool: scancode-toolkit 32.3.0
and
Creator: Tool: SCANOSS-PY: 1.18.1
where the name contains an hyphen, and the tool name and tool version are not separated by an hyphen.
So we cannot require a precise syntax.
The CreatorComment is a free text field. We use it to store the CISA SBOM Types, as there is no specific field for that in SPDX 2.2 and 2.3, but any other information can of course be put in it also.
We do not require a specific format. We only require that at least one of the words “Design”, “Source”, “Build”, “Analyzed”, “Deployed”, “Runtime” is present, regardless of the case.
So, the following possibilities are all valid:
CreatorComment: Analyzed
CreatorComment: CISA SBOM Type: Deployed
CreatorComment: This SBOM was created during build phase.
The SBOM SHALL be delivered no later than at the time of the delivery of the software (in either binary or source form).
“NTIA SBOM Minimum elements”, section “Distribution and Delivery”
To ensure that the receiving entity can ingest the software and its SBOM, it shall be delivered no later than at the delivery of the software. An SBOM may be delivered before the software if an adopting entity so elects, but the software delivery must nevertheless be accompanied by the corresponding SBOM to ensure compliance with the Guide.
The SBOM SHALL be embedded into the software “package” where technically feasible. If it is not technically feasible to embed the SBOM into the software “package” being delivered, such as in the case of space-constrained embedded systems, the supplying party will supply a web hosted version of the SBOM that is available for at least 18 months and SHALL NOT in any way restrict recipients’ ability to copy and store these locally for their own use. Such restrictions MAY NOT be placed on the recipient in additional confidentiality agreements.
“NTIA SBOM Minimum elements”, section “Distribution and Delivery”
Other options of SBOM delivery such as webhosting are less stable and access is not guaranteed over time; however “embedding” may not be technically feasible. Thus, in scenarios where it is not possible on technical grounds to include the SBOM in the software delivery, publishing the SBOM online is permitted provided that the SBOM is accessible for the recipients of the software for 18 months. This duration is in line with the OpenChain specification requirements on recertification.
The SBOM SHALL contain all open source software that is delivered with the product including all of the transitive dependencies. The SBOM SHOULD contain all commercial components.
If some components are not included, they MUST be reported as “known unknowns.”
“NTIA SBOM Minimum elements”, section “Known Unknowns”
It might not be possible, advisable or feasible to have the commercial component information in the SBOM. However, it is advisable that the SBOM should be as complete as possible.
As the OpenChain Telco SBOM Guide is only applied on the SBOM level, there is no requirement on an entity that have elected to supply an OpenChain Telco SBOM Compatible document for some or even all of its software deliveries to also provide this for its SaaS offerings. However, an entity may elect to apply the OpenChain Telco SBOM Guide also to its SaaS offerings and thus also deliver the open source software used in the SaaS offerings with their transitive dependencies as an SBOM.
There is currently no consensus in the industry on what an SaaS SBOM should contain.
SBOMs for containers SHOULD include all open source components delivered in the container. This includes the packages installed into the container, components copied or downloaded to the container and dependencies used to build the compiled components in the container.
Every open source component delivered should be part of the SBOMs.
It is RECOMMENDED to provide a digital signature of the SBOM in order to guarantee the integrity of the SBOM.
Sigstore https://www.sigstore.dev/ is an example of such capability.
While the verification of SBOMs is an important topic, OpenChain Telco defers this work to other initiatives for the moment and intends to revisit this topic in future iterations of this document.
SBOMs following this Guide can be built from several SBOM files with a well-defined relationship to each other using the relationship definition features in SPDX.
There exist tools to merge several SBOMs into one, e.g. https://github.com/interlynk-io/sbomasm
It is often easier when dealing with a large software product to provide individual SBOMs of its parts than a single SBOM.
SBOMs MAY be subject to confidentiality agreements. A conformant SBOM MUST NOT, however, be subject to any confidentiality agreements that would prevent a recipient from redistributing the parts of the SBOM applicable to software that such recipient has a right to redistribute.
“NTIA SBOM Minimum elements”, section “Access Control”
Some open source software licenses enable any recipient to redistribute the software. In these situations, the recipients should be also able to redistribute the relevant parts of the SBOMs.
To indicate that the software has a conformant SBOM available, you MAY use the following statement: “This software is supplied with an SBOM conformant to the OpenChain Telco SBOM Guide v1.0, the Guide is available at https://github.com/OpenChain-Project/Telco-WG/blob/main/OpenChain-Telco-SBOM-Guide_EN.md”
You MAY at your choosing use the following statement in your Telco Guide conformant SBOM “This SBOM conforms to the OpenChain Telco SBOM Guide v1.0 https://github.com/OpenChain-Project/Telco-WG/blob/main/OpenChain-Telco-SBOM-Guide_EN.md, it is provided to the recipient free of charge, and the recipient is free to redistribute this SBOM to any third party that they distribute the corresponding software to, provided that they have all the necessary right to distribute the software to such third party”
The following statement MAY be used as statement in the RFP document, order document, or contract document when requesting an RFP, purchasing orders, or outsourced development orders from a software vendor or telco system suppliers. “When releasing software, it is REQUIRED to provide an SBOM compliant with the OpenChain Telco SBOM Guide v1.0 for all software released. This Guide is available at https://github.com/OpenChain-Project/Telco-WG/blob/main/OpenChain-Telco-SBOM-Guide_EN.md”
- SPDX (ISO/IEC 5962:2021)
- OpenChain (ISO/IEC 5230:2020)
- The Minimum Elements For a Software Bill of Materials (SBOM) a.k.a. “NTIA minimum elements”
- Framing Software Component Transparency: Establishing a Common Software Bill of Materials (SBOM), Third Edition
- Package URL (PURL)
The following updates of the Guide have been made in version 1.1.
- Both PackageChecksum and PackageVerificationCode are allowed as package hash.
- The package hash is RECOMMENDED instead of MANDATORY.
- ExternalRef is RECOMMENDED instead of MANDATORY.
- FilesAnalyzed is no longer MANDATORY.
- Examples are provided for the CISA SBOM Types.
- sbomasm is a better example of SBOM merge tool.
- Add reference to new CISA document.
An SBOM that conforms to version 1.0 of the Guide will also conform to version 1.1 of the Guide. The reverse is not true.