Minimum SBOM Elements

On this page we explore the minimum required specifications for an SBOM declared under Executive Order 14028 and outlined in this document.

Brief Introduction

SBOM’s form a foundational data layer on which further security tools, practices, and assurances can be built. To achieve this, three interrelated areas are specified:

  1. Data Fields
  2. Automation Support
  3. Practices and Processes

Data Fields

Data fields contain baseline information about each component to track them across the software supply chain and map them to other sources of data such as vulnerability databases or license databases. This includes:

  1. Supplier name - name of entity that creates, defines, and identifies components
  2. Component Name - name assigned to software package defined by original supplier
  3. Version of the Component - ID to specify version
  4. Other Unique Identifiers
  5. Dependency Relationship - characterizing relationship for component X included in software Y
  6. Author of SBOM Data - the name of the creating entity
  7. Timestamp - of SBOM data assembly

Automation Support

SBOM’s should have support for automation including automatic generation and machine-readability. Three standards have been deemed interoperable for core data fields and sytax representations:

  1. Software Package Data eXchange (SPDX)
  2. CycloneDX
  3. Software Indentification (SWID) tags

Practices and Processes

Certain practices and processes should be followed that focus on the mechanics of SBOM use. These include:

  1. Frequence - a new SBOM must be created upon version updates or error correction
  2. Depth - a SBOM should contain all primary components with transitive dependencies listed. At a minimum all dependencies must be listed with enough detail to seek recursive transitive dependencies.
  3. Known Unknowns - in cases when a full dependency graph is unable to be enumerated, a SBOM must explicitly identify “known uknowns”. Futhermore the author should affirmatively state when all direct dependencies of a component have been fully enumerated, or when there are no further cdependencies.
  4. Distribution and Delivery - SBOMs should be available in a timely fassion to those who need them and must have appropriate access permissions in place
  5. Access Control - if access control is desired, the terms for integrading SBOM datta to a user’s security tools must be specified
  6. Accommadation of Mistakes - should be built into the initial phase of SBOM, allowing for omissions and errors.