Version History

  • Version v1.0 (2023-04-06): Published on SPDX GitHub Pages

  • Version v0.3 (2023-04-05): Completed Part 5

  • Version v0.2 (2023-04-05): Completed Parts 1-4; publishing via GitHub Pages

  • Version v0.1 (2023-03-28): First interim draft

1. Introduction

1.1. Background

The past several years have demonstrated the ever-growing need for software distributors to make available Software Bills of Materials (SBOMs). Executive Order 14028 on Improving the Nation’s Cybersecurity, issued on May 12, 2021, drove home the importance of SBOMs in protecting the software supply chain.

Pursuant to the Executive Order, the National Telecommunications and Information Administration (NTIA) released the "Minimum Elements" for an SBOM. These are the data fields which, together with "automation support" and "practices and processes," the NTIA has designated as being the

minimum elements that will enable basic use cases, such as management of vulnerabilities, software inventory, and licenses.
— NTIA Minimum Elements p. 3

The NTIA Minimum Elements envision that the data contained in SBOM data fields should be expressed in "predictable implementation and data formats" (p. 10) in order to enable support for automation.

SPDX, the Software Package Data Exchange, is a standardized format for expressing SBOM data. It has been developed transparently over the past 10+ years in an open source, multi-stakeholder community and is recognized as an international open standard (ISO/IEC 5962:2021; also available at https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html and https://spdx.dev/specifications/). The SPDX specification defines the structure and format of an SPDX Document, including the particular fields and data values to enable interchange of software metadata in a format which is both machine-readable and human-readable.

SPDX is a flexible language for expressing a wide variety of metadata that handles many use cases. Among these use cases is support for expressing the NTIA Minimum Elements.

While version 2.3 (released in November 2022) was the first version of the SPDX specification to explicitly describe how to express the NTIA Minimum Elements in an SPDX Document, SPDX’s support for the NTIA Minimum Elements actually dates back to its version 2.0 release in 2015.

This HOWTO describes how SPDX 2.x supports the NTIA Minimum Elements for an SBOM, and demonstrates several different example methods for how to create an SPDX SBOM that complies with the NTIA requirements.

1.2. Overview of this HOWTO

This HOWTO covers the following topics:

  • Key terms and concepts applicable to SPDX SBOMs expressing the NTIA Minimum Elements

  • Understanding the contents of an SPDX NTIA Minimum Elements SBOM

  • Multiple examples of creating an SPDX NTIA Minimum Elements SBOM, including:

    • manual creation of a text file

    • manual creation using the SwiftBOM tool

    • automated creation using tooling

These topics are followed by links to a few additional resources for further reading.

1.3. Source Documents and License Information

The source documents for this HOWTO are written in AsciiDoc and are available at https://github.com/spdx/spdx-ntia-sbom-howto. Issues and pull requests may be submitted to that repository.

This HOWTO is Copyright 2023 Steve Winslow, and is licensed under a Creative Commons Attribution 4.0 International License (CC-BY-4.0), available at https://creativecommons.org/licenses/by/4.0/legalcode.

All SPDX metadata examples in this HOWTO, including the template and sample SPDX documents, are made available under CC0 1.0 Universal (CC0-1.0), available at https://creativecommons.org/publicdomain/zero/1.0/legalcode.

SPDX and Software Package Data Exchange are registered trademarks of The Linux Foundation.

2. Key Terms and Concepts

The following is not a full overview of the SPDX data model and format, nor of SBOM concepts generally. But understanding a few concepts regarding SPDX’s terminology is helpful in being able to create an effective SBOM.

As mentioned in the introduction, the following terminology refers to the 2.x versions of the SPDX specification, with a specific focus on the latest release, version 2.3.

2.1. SPDX Documents

An SPDX Document is a document that contains SPDX metadata about software. While an SPDX Document can convey a variety of different types of information, if it includes the minimum necessary elements to describe software, then it is an SBOM.

An SPDX Document is represented on disk as a single file in one of the following supported formats: JSON, YAML, RDF/XML, tag-value, and spreadsheet. Documents can be interchanged between formats using the official SPDX tools (Java, Golang, and Python, with the Java and Python tools currently having the greatest degree of conformance and support). The SPDX Online Tools Convert utility can also be used.

In this HOWTO, we will focus on SPDX’s tag-value format. It is a simple text file format which is both machine-parseable and human-readable, and can easily be created by hand, using text templating software, or SPDX-specific tools.

In a tag-value SPDX Document, each line of data consists of (1) a tag defining the data field; (2) a colon separator; and (3) the corresponding data value. For instance, the following line defines the name of an SPDX Document:

DocumentName: My Awesome SBOM

For some text fields, multi-line text can be enclosed in <text>…​</text> tags. Lines consisting of whitespace, and comment lines beginning with #, are ignored.

2.2. SPDX Elements

The SPDX data model represents software as a collection of linked elements. Each SPDX element has a unique identifier (described in Part 2.3 below).

In SPDX, there are three primary types of elements that can be used to represent software:

  • Package: represents any unit of content associated with a distribution of software; typically composed of one or more Files

  • File: represents a file on disk, as typically understood by most operating systems

  • Snippet: represents a portion of a File

However, although it is possible to represent software down to the File or Snippet level, it is not required to do so. SPDX is unopinionated: it defines a vocabulary of nouns, along with adjectives to describe them. The SPDX Document creator is free to use those nouns and adjectives to describe a distribution of software to a greater or lesser degree of specificity.

The NTIA Minimum Elements for an SBOM only require describing software at the "component" level. In SPDX terms, this corresponds to a Package. So for the SPDX Documents we’ll be looking at in the rest of this HOWTO, we will only be talking about Packages, and we can disregard the File and Snippet element types.

Finally, note that the SPDX Document itself is also an SPDX element, and therefore has its own identifier as well. The purpose for this will become clear as we proceed.

2.3. SPDX Identifiers

As mentioned above, each SPDX element has its own SPDX identifier. An element’s SPDX identifier is its unique address: a mechanism by which other SPDX fields can reference it, such as in Relationships (described in Part 2.4 below).

An element’s SPDX identifier is actually made up of two components:

  • the Document Namespace of the SPDX Document in which the element is defined; and

  • the Local Identifier for the element, which is unique within that namespace.

The Document Namespace is defined once for each SPDX Document, in the Document Creation Info section (at the beginning of a tag-value Document). Although a Document Namespace enables powerful abilities to link between SPDX Documents and reference elements defined in another Document, doing so is not necessary for creating an NTIA Minimum Elements SBOM. So for purposes of this HOWTO, just be aware that the SPDX Document will have a unique Document Namespace URI defined in the intro section, but otherwise we can ignore this.

The Local Identifier must begin with the prefix SPDXRef-, followed by a unique set of letters, numbers, . and -.

Each SPDX element in a Document must have its own unique Local Identifier. In this HOWTO, this focuses on each Package information section defining a corresponding unique SPDX identifier to reference that package. Although several of the examples used in this HOWTO for Packages begin with SPDXRef-Package-, this is solely for illustrative and readability purposes; the Package- portion of the identifier is not required.

The SPDX Document itself always has the Local Identifier SPDXRef-DOCUMENT, defined explicitly in the Document Creation information section at the beginning of the tag-value file.

Finally, note that SPDX identifiers are a separate and different concept from SPDX license identifiers—​the unique identifiers used to refer to licenses and exceptions that are on the SPDX License List. You may have encountered SPDX license IDs in package metadata or source code. While those license identifiers work in a similar manner to SPDX element identifiers, we won’t be discussing them further here.

2.4. Relationships

Finally, the existence of SPDX elements with unique identifiers enables us to specify Relationships between elements.

The SPDX specification defines a broad vocabulary of Relationship types. For instance, it is possible to use Relationships to express that one file is derived from another; or that a source code file is compiled to create an object code file; or that two files are dynamically or statically linked together.

However, for an NTIA Minimum Elements SBOM (and therefore for purposes of this HOWTO), there are only two Relationship types that we need to know about.

2.4.1. DESCRIBES Relationship

The first key Relationship type, DESCRIBES, tells us which Package(s) are the ones that the Document is primarily describing. In talking about a piece of software, there is the software itself, and then the tree of dependencies that it contains. The Package at the top of the tree is the one that would be specified in the DESCRIBES Relationship.

If that top-level Package has the SPDX identifier SPDXRef-MySoftware, for example, then the following line in a Document would specify that it is the top-level, primary Package:

Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-MySoftware

2.4.2. CONTAINS Relationship

The other Relationship type we care about here, CONTAINS, tells us that one Package contains the other Package as a dependency.

The primary Package would have a CONTAINS Relationship with each dependency Package that it directly contains. If a dependency Package itself contains other subdependencies, then those Packages would similarly have a CONTAINS Relationship.

For example, this may look like the following:

Relationship: SPDXRef-MySoftware CONTAINS SPDXRef-AcmeRuntime
Relationship: SPDXRef-AcmeRuntime CONTAINS SPDXRef-AcmeMemoryManager

3. Understanding an NTIA Minimum Elements SPDX SBOM

3.1. Example SPDX Document

Let’s look at a basic SPDX Document that contains the NTIA Minimum Elements data for a simple piece of software.

This is an SBOM I’ve created for a fictional piece of software, the Frobozz Text Editor. It contains a single third-party component, a spellchecker that is packaged into and distributed together with the main text editor.

Here’s the SPDX Document, in tag-value format:

samples/sample.spdx
SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: Frobozz Editor SBOM
DocumentNamespace: https://spdx.org/spdx-docs/spdx-ntia-sbom-howto/sample1-v1
Creator: Person: Steve Winslow (steve@example.com)
Created: 2023-03-26T18:00:00Z

PackageName: Frobozz Text Editor
SPDXID: SPDXRef-Package-Frobozz
PackageVersion: v1.2.3
PackageSupplier: Organization: Frobozz Magic Software Company
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-Package-Frobozz

PackageName: Spellchecker of Yendor
SPDXID: SPDXRef-Package-Yendor
PackageVersion: v3.5-beta2
PackageSupplier: Person: Wizard of Yendor
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
Relationship: SPDXRef-Package-Frobozz CONTAINS SPDXRef-Package-Yendor

This SPDX Document begins with the mandatory Document Creation information section, and is followed by two Package information sections—​one for the text editor, and one for its packaged spellchecker component.

Let’s walk through it line by line.

3.2. Document Creation Information Section

Lines 1-7 form the Document Creation information section, which is essentially a "file header" defining data about the SPDX Document itself.

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: Frobozz Editor SBOM

The first four lines are required by the SPDX Document format, and are not part of the NTIA Minimum Elements. These lines indicate:

  • SPDXVersion: the version of the SPDX specification being used (here, 2.3)

  • DataLicense: the license applicable to the SPDX Document itself (CC0-1.0, per section 6.2 of the SPDX spec)

  • SPDXID: the "local" part of the unique SPDX identifier referring to the SPDX Document itself (SPDXRef-DOCUMENT); and

  • DocumentName: a user-defined plain language name to refer to the SPDX document

SPDXVersion, DataLicense and SPDXID will be identical in every SPDX Document you create—​assuming you’re creating a tag-value SPDX 2.3 Document. DocumentName is also required by the SPDX specification to be present, but can contain whatever value you’d like.

DocumentNamespace: https://spdx.org/spdx-docs/spdx-ntia-sbom-howto/sample1-v1
Creator: Person: Steve Winslow (steve@example.com)
Created: 2023-03-26T18:00:00Z

The next three lines cover the remainder of the required elements for the Document Creation information section. These are also part of the NTIA Minimum Elements:

  • DocumentNamespace: a unique URI for this SPDX Document, although the Document does not need to be accessible from this URI (see Part 2.3 for more information); this is part of the Other Unique Identifiers NTIA element

  • Creator: one or more of Person, Organization or Tool that created this SPDX Document, with optional email address in parentheses for a Person or Organization; this is the Author of SBOM Data NTIA element

  • Created: the date-time of the creation of the SBOM, expressed in UTC per the ISO 8601 format; this is the Timestamp NTIA element

These seven lines comprise the entirety of the required fields for the Document Creation information section for an SPDX 2.x Document, and also cover 2 1/2 of the NTIA Minimum Elements.

3.3. Package Information Section and Relationship - primary package

The next block (lines 9-15) forms the Package information section for the primary Package being described by the SPDX Document: the Frobozz Text Editor. It also includes a DESCRIBES Relationship, stating that this SPDX Document is principally describing the text editor Package.

PackageName: Frobozz Text Editor

For SPDX Documents in tag-value format, a new Package information section always begins with the PackageName tag. This line indicates:

  • PackageName: the full human-readable name for the Package, as given by the Package’s originator; this is the Component Name NTIA element

SPDXID: SPDXRef-Package-Frobozz

The next line indicates:

  • SPDXID: together with DocumentNamespace, this forms a unique addressable identifier for this Package, as described in 2.3; this is the other part of the Other Unique Identifiers NTIA element

The SPDXID will always begin with SPDXRef-, followed by a unique string containing letters, numbers, . and/or -. The SPDXID value must be unique within this SPDX Document.

PackageVersion: v1.2.3
PackageSupplier: Organization: Frobozz Magic Software Company

These two lines indicate:

  • PackageVersion: The version of the Package, as specified by its supplier; this is the Version of the Component NTIA element

  • PackageSupplier: The identity of the direct supplier of the Package, as a Person or Organization similar to the SPDX Document Creator element described above; this is the Supplier Name NTIA element

PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
Relationship: SPDXRef-DOCUMENT DESCRIBES SPDXRef-Package-Frobozz

The next three lines are not part of the NTIA Minimum Elements, but are instead required by the SPDX 2.3 specification. These two lines indicate:

  • PackageDownloadLocation: the URL or version control system location from which the Package can be downloaded, if any

  • FilesAnalyzed: a boolean specifying whether or not the SPDX Document includes File information sections for the Files comprising this Package

  • Relationship: with the DESCRIBES relationship type, indicates that the SPDX Document is primarily describing the text editor Package

A minimal SBOM meeting the NTIA Minimal Elements requirements does not need to include File information sections, so we’ll leave FilesAnalyzed as false.

If we know the PackageDownloadLocation for this version of the Package, we can specify the URL, but there’s no need to do so. We can leave it as NOASSERTION to indicate that we (as the SPDX Document creator) are not making any attempt to specify it; or if we knew that there is no download location whatsoever, we could also specify NONE.

Line 15 is technically part of a Relationship information section, but it can in fact appear anywhere in the SPDX Document after the initial Document Creation information section. Each SPDX Document that contains more than one Package must include at least one DESCRIBES Relationship, in order to specify which Package is the primary one being described by this SPDX Document.

3.4. Package Information Section and Relationship - contained dependency

The elements listed in subsections 3.2 and 3.3 above are actually all that is required by the NTIA Minimum Elements and the SPDX specification format, for a primary Package that contains no dependencies.

For this example, we’re assuming that the text editor includes exactly one dependency, a separate spellchecker component obtained from a third party. The final block (lines 17-23) describes this dependency.

Most of the fields have an identical meaning and structure as those used in the Package information section for the primary Package. Only the final line has a different structure:

Relationship: SPDXRef-Package-Frobozz CONTAINS SPDXRef-Package-Yendor

While this is also a Relationship information line as for the prior Package, this one instead has a CONTAINS relationship type, indicating:

  • Relationship: with the CONTAINS relationship type, indicates that the Package with the ID specified on the left side contains the Package with the ID specified on the right side; this is the Dependency Relationship NTIA element

Assuming that this spellchecker Package is the only dependency contained in the text editor Package, we are all done. This SPDX Document contains all of the NTIA Minimum Elements for an SBOM.

3.5. Summary of required fields

The following table summarizes the SPDX fields that correspond to the NTIA Minimum Elements fields.

Table 1. NTIA Minimum Elements and SPDX 2.3 fields
NTIA element name SPDX 2.3 field name SPDX 2.3 specification reference

Supplier Name

PackageSupplier

Section 7.5

Component Name

PackageName

Section 7.1

Version of the Component

PackageVersion

Section 7.3

Other Unique Identifiers

DocumentNamespace, SPDXID

Section 6.5, Section 7.2

Dependency Relationship

Relationship (CONTAINS)

Section 11.1

Author of SBOM Data

Creator

Section 6.8

Timestamp

Created

Section 6.9

Additionally, the following table summarizes the other SPDX fields that are required as mandatory fields per the SPDX spec, which do not correspond to the NTIA Minimum Elements.

Table 2. Other mandatory SPDX 2.3 fields
SPDX 2.3 field name Value SPDX 2.3 specification reference

SPDXVersion

SPDX-2.3

Section 6.1

DataLicense

CC0-1.0

Section 6.2

SPDXID (for Document)

SPDXRef-DOCUMENT

Section 6.3

DocumentName

user-defined name of SPDX Document

Section 6.4

PackageDownloadLocation

NOASSERTION or URL / VCS location

Section 7.7

FilesAnalyzed

false (unless including all File information sections)

Section 7.8

Relationship (DESCRIBES, for primary Package)

SPDXRef-DOCUMENT on left side, ID of primary Package on right side

Section 11.1

Annex K.2 of the SPDX specification includes a related table describing the NTIA elements. Please note that it uses field names that differ slightly from the official NTIA Minimum Elements, and also includes one field (Component Hash) that is not one of the NTIA Minimum Elements. The field names listed in Annex K.2 originate from a separate report issued by the NTIA Multistakeholder Process on Software Component Transparency. Although NTIA encourages SBOMs to include Component Hashes, it is not one of the mandatory NTIA Minimum Elements.

4. Creating an NTIA Minimum Elements SPDX SBOM

The next part of this HOWTO describes a few different processes for creating an NTIA Minimum Elements SBOM in SPDX format, including some additional considerations for your own software.

4.1. Manual creation via text file

The simplest way to get started with creating an SBOM is to do it manually. An SPDX Document in tag-value format is nothing more than a text file with particular fields.

Below is a template that you can copy and use to create your own SPDX 2.3 SBOM for your own software.

4.1.1. SPDX 2.3 template for NTIA Minimum Elements SBOM

Here are a few rules for using this template:

  • SPDX tag-value files typically end with the .spdx file extension.

  • Lines beginning with # are comments, and are included in the template just as guidance; these can be omitted.

  • Bracketed portions of text explain the values that should be used for those lines; refer back to Part 3 of this HOWTO for more details about the meanings of each line.

  • The remaining lines without brackets should be reproduced as-is, for this minimal SBOM template.

  • The bottom block of text in the template (lines 23-29) should be reproduced with a separate copy for each dependency included in the primary Package; see also the notes following the template below regarding additional and unknown dependencies.

samples/template.spdx
# Document Creation information section

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: [Name of SPDX Document]
DocumentNamespace: [URI for unique namespace for this SPDX Document]
Creator: [SBOM creator, in one of the following forms][Option 1: Person: Full Name][Option 2: Organization: Company Name]
Created: [SBOM creation date and time in UTC ISO 8601 format, e.g. YYYY-MM-DDThh-mm-ssZ]

# Package information section - primary Package

PackageName: [Name of primary Package]
SPDXID: [Unique ID for primary Package, beginning with SPDXRef- followed by letters, numbers, . and -]
PackageVersion: [Version of primary Package]
PackageSupplier: [Supplier of primary Package, in one of the following forms][Option 1: Person: Full Name][Option 2: Organization: Company Name]
PackageDownloadLocation: NOASSERTION
FilesAnalyzed: false
Relationship: SPDXRef-DOCUMENT DESCRIBES [ID for primary Package specified above]

# Package information section - one for each dependency contained in primary Package

PackageName: [Name of dependency]
SPDXID: [Unique ID for dependency, following the ID rules described above]
PackageVersion: [Version of dependency]
PackageSupplier: [Supplier of dependency, in one of the following forms][Option 1: Person: Full Name][Option 2: Organization: Company Name]
FilesAnalyzed: false
PackageDownloadLocation: NOASSERTION
Relationship: [ID for primary Package] CONTAINS [ID for dependency]

4.1.2. Additional subdependencies

According to the NTIA guidance on Minimum Elements for an SBOM, an SBOM

should contain all primary (top level) components, with all their transitive dependencies listed. At a minimum, all top-level dependencies must be listed with enough detail to seek out the transitive dependencies recursively.
— NTIA Minimum Elements p. 12, "Depth"

This indicates that although it is only required that the top-level dependencies be specified in an SBOM, it is preferred that it describe ALL dependencies, if possible. This would include both:

  • direct dependencies (aka "top-level"), which are directly leveraged by the primary software; and

  • indirect dependencies (aka "transitive" or "subdependencies"), which are leveraged by another direct or indirect dependency.

Ideally, then, the SBOM should include a Package information section for each direct AND indirect dependency, if possible.

  • For a direct dependency, the Relationship line would have the primary software Package’s ID on the left side of the CONTAINS field.

  • For an indirect dependency, the Relationship line would have the parent dependency Package’s ID on the left side of the CONTAINS field.

Keep in mind that it is possible for a Package to be a subdependency of two (or more!) other dependencies, or for it to be both a direct and indirect dependency. In any of these cases, multiple Relationship lines can be used to specify the various dependency relationships.

4.1.3. Unknown dependencies

The NTIA guidance also states

For instances in which the full dependency graph is not enumerated in the SBOM, the SBOM author must explicitly identify "known unknowns."
— NTIA Minimum Elements p. 12, "Known Unknowns"

If your SBOM contains a Package section with corresponding Relationships for all contained dependencies, then you are all set; you have enumerated the full dependency graph.

But if you know that you have not listed all indirect dependencies contained in your software, that’s okay under the NTIA Minimum Elements (as long as all direct dependencies are listed). It just means that you need to include a statement explicitly indicating that there are "known unknowns".

In SPDX 2.3, this is done with using the following line for each direct dependency (assuming for this example that the direct dependency Package’s specified SPDXID is SPDXRef-Package-Dep1)

Relationship: SPDXRef-Package-Dep1 CONTAINS NOASSERTION

The NOASSERTION special identifier indicates that the SBOM Document’s author is explicitly not asserting whether there are other indirect dependencies that might be contained within the SPDXRef-Package-Dep1 dependency’s Package.

So if you haven’t described in the SBOM all indirect dependencies, be sure to include this CONTAINS NOASSERTION relationship line for each such direct dependency.

4.2. Manual creation via SwiftBOM

Rather than creating an SPDX Document via a text file from scratch, there are templating tools that can assist with filling in the fields manually and formatting the data as required by SPDX.

The CERT Coordination Center at Carnegie Mellon University’s Software Engineering Institute hosts a tool called SwiftBOM (with source code available on GitHub at https://github.com/CERTCC/SBOM under the MIT license). This is a proof of concept SBOM generator that shows the fields required to be filled in by the SPDX Document creator in a simple form. After the form is filled in, an SPDX SBOM containing the NTIA Minimum Elements can be downloaded (assuming that the fields are filled in correctly.

Note that the generated SBOM may not be "optimized" for human readability. For example, it generates SPDX IDs for the Package information sections using hashes, which are fine for automated parsing but may make it more challenging for a human reader to fully understand the SBOM. This tradeoff between tooling-assisted creation of SBOMs (easier but less readable) and manual human creation of SBOMs (more readable but more tedious and error-prone) is something that SBOM creators will need to consider when designing their processes.

4.3. Automated creation using tooling

Most or all aspects of creating an NTIA Minimum Elements SBOM in SPDX format can be automated using tooling.

At a high level, the process would involve the following steps:

  1. Determine the following info for the primary software package:

    • its name

    • its supplier

    • its version number

    • its direct dependencies

  2. Repeat the process in 1 for each dependency (ideally continuing down the tree for each subdependency)

  3. Assign SPDX identifiers for each package

  4. Output the Document Creation information section

  5. Output the Package information section and DESCRIBES Relationship for the primary software package

  6. Output the Package information section and CONTAINS Relationship for each dependency

The specifics of how to obtain the information for steps 1 and 2 will vary, depending on the nature of your software programming ecosystem.

Step 3 can be handled via use of a UUID generator, prefixed by SPDXRef- in each case. Or a slightly more complicated algorithm can be used to convert package names and version numbers into SPDX identifiers that are more readily human-readable, if desired.

After the above data is gathered, steps 4, 5 and 6 can be performed using text templating tools, or even simple print statements or their equivalent. The official SPDX tools (Java, Golang, and Python) can also be used to programmatically output SPDX Documents in the correct format.

Additionally, the SPDX project makes available the SPDX Online Tools, a collection of tools hosted by SPDX which can assist in validating whether your SPDX Document is correct and valid. It includes (1) a Validator that checks to ensure that a Document meets the SPDX 2.3 specification’s requirements; and (2) an NTIA Conformance Checker that confirms whether a Document meets the NTIA Minimum Element requirements. If you will be making substantial use of the SPDX Online Tools, and particularly if you may use them to validate or check SBOMs containing sensitive data, you will likely want to install a local copy of the Online Tools yourself from the source code repo.

SPDX also makes available a command-line NTIA conformance checker tool.

A variety of other open source, proprietary and commercial tools and services have implemented different aspects of SPDX Document creation. Many of these may be able to handle some or all of the aspects needed for automatic generation of NTIA Minimum Elements SBOMs in SPDX 2.3 format.

5. Additional resources

NTIA resources on SBOMs

SPDX resources

SPDX SBOM samples

SPDX tools

License

Copyright 2023 Steve Winslow

This work is licensed under a Creative Commons Attribution 4.0 International License (CC-BY-4.0), available at https://creativecommons.org/licenses/by/4.0/legalcode.

SPDX and Software Package Data Exchange are registered trademarks of The Linux Foundation.