+2.1.3 SBOM Types

2.1.3 SBOM Types

It is important to understand that the selection of the SBOM format is not the only decisive factor influencing the information that the SBOM is going to contain. Based on “ when ” the SBOM is generated, it may contain different forms of information and serve different purposes. The choice of “when” to generate SBOMs should serve the operational needs of the Organization but also align with the applicable regulatory requirements.

In this case, the categorisation of SBOMs derives from the phase of the SDLC under which they are generated. The most recognised SBOM types based on the U.S. CISA types of SBOM (12) are:

SBOMDefinitionInformation PotentiallyIndicative Use
TypeCaptured
DesignSBOM of intended design of included components (some of which may not exist) for a new software artifact.
  • Planned third-party
  • Architectural decisions
  • Licencing purchase
  • Threat Modeling
  • Regulatory requirements management

libraries

  • Open-source packages
  • Commercial

components

  • External services and

APIs

  • Expected versions
  • Intended licensing

model

SourceSBOM created directly from the development environment, source files, and included dependencies used to build a new product artifact.
  • Existing components
  • Dependency visibility
  • Early vulnerability detection

from the source code

  • Direct dependencies

from third-party and

open-source

components

  • Exact versions
  • Licenses
BuildSBOM generated as part of the process of building the software to create a releasable artifact (e.g., executable or package) from data such as source files, dependencies, built components, build process ephemeral data, and other SBOMs.
  • Direct dependencies
  • Regulatory compliance
  • Vulnerability Assessment
  • Software transparency
  • Transitive

dependencies

  • Linked libraries
  • Generated artifacts
  • Build-time packages
  • Operating system

components

  • Exact versions
  • Cryptographic hashes
  • Supplier Information
  • Dependency graph
  • Package URLs
  • CPE identifiers
  • Licenses
AnalysedSBOM generated through analysis of artifacts (e.g., executables, packages, containers, and virtual machine images) after its build. Such analysis generally requires a variety of heuristics. In some contexts, this may also be referred to as a “3rd party” SBOM.
  • Direct Dependencies
  • License compliance
  • Provenance verification
  • Supply chain risk assessment
  • Security certification / verification
  • Transitive

dependencies

  • Linked Libraries
  • Generated artifacts
  • Versioning
  • Cryptographic

information

  • Licenses
  • Integrity validation
  • Software origin
  • Supplier trust

information

DeployedSBOM provides an
  • Installed packages
  • Container images
  • Environment-specific dependencies
  • Platform-specific libraries
  • Installed packages
  • Enterprise-level asset inventory
  • Patch management
  • Environment-specific risk assessment
  • Configuration management

inventory of software

  • Container images

that is present on a

system. This may be
  • Environment-specific
an assembly of otherdependencies

SBOMs that

combines analysis of
  • Platform-specific
configuration options,libraries

and examination of

execution behavior in

a (potentially

simulated)

deployment

environment.

RuntimeSBOM generated
  • Dynamically loaded libraries
  • Plug-ins
  • Runtime modules
  • Container sidecars
  • Injected agents
  • Shared services
  • Threat detection
  • Attack surface risk assessment
  • Runtime monitoring

through instrumenting

the system running

the software, to

capture only

components present

in the system, as well

as external call-outs

or dynamically loaded

components. In some

contexts, this may

also be referred to as

an “Instrumented” or

“Dynamic” SBOM.

Table 3 - SBOM Types

1. Ülevaade

1.1 Viited

1.2 Tuvastatud nõuded

1.3 Seotud regulatsioonid

2. Tuvastatud nõuded

Nõuded

3. Seotud regulatsioonid

Regulatsioonid