+2.1 How Software Bill of Materials works
---+2.1.1 Data Model
---+2.1.2 SBOM Formats
---+2.1.3 SBOM Types

2.1 How Software Bill of Materials works

An SBOM is a structured inventory that captures software components and their dependencies for a given software product. Creating this "list of ingredients” gives manufacturers and users a better understanding and greater visibility into the “ingredients” of their software product, who produced them, where they came from and whether those “ingredients” may pose any risks.

The SBOM generators gather information from different sources in order to effectively identify first-party components, open-source libraries, third-party commercial libraries, operating system packages, container images etc. Indicative sources of information are:

source code repositories,
build artifacts,
package manager manifests,
lock files,
container images,
binary analysis.

For each of the identified software components, the SBOM generator then collects and corelates metadata such as component name, component version, component creator, unique identifiers, license information, external references and dependencies. The scope and completeness of the collected metadata depend on its availability, the SBOM generator’s analysis methods, and the selected SBOM data model (e.g. CycloneDX or Software Package Data Exchange (SPDX)). The result is not merely a list of components but also a representation of their dependency relationships.

Upon the completion of the software composition analysis, the metadata collection and relationship discovery, an SBOM is generated in a standard machine-readable format , most commonly CycloneDX or SPDX. The SBOM can be generated and stored as JSON, XML, YAML or Tag-Value. It is important to highlight that SBOMs can be generated in different phases of the Software Development Lifecycle (SDLC). SBOMs generated in different SDLC phases serve different needs and contain different information.

The generation of an SBOM provides limited value unless it is actively consumed to support operational and security processes. The benefit of an SBOM lies in its integration into use cases such as vulnerability management, software asset inventory, license compliance, procurement, and regulatory compliance.

The need to treat an SBOM as more than a compliance artifact, is also reflected in the findings of the

ENISA SBOM Adoption State of Play 2026 , as respondents identified industry consensus on best

practices for integrating SBOM production and consumption into software development practices as the highest priority (23%), followed by best practices for integrating SBOMs into risk and compliance processes (19%) and guidance on how SBOM production and consumption methods should evolve over time (19%). These findings highlight that organisations consider the operational integration of SBOMs into existing development, security, and governance workflows as a crucial step for a mature SBOM adoption.

1. Prezentare generală

2.1.1 Data Model

With the aim to enable interoperability and consistency throughout the SBOM generation and consumption, authoritative bodies have published guidance on the data fields for SBOMs. The

German Federal Office for Information Security (BSI) has published a technical guideline defining the required data fields, while the U.S. Cybersecurity and Infrastructure Security

Agency (CISA), building upon the existing work previously published by the National Telecommunications and Information Administration (NTIA), defines the “Minimum Elements for a Software Bill of Materials”. Both publications provide a baseline for generating SBOMs.

The table below attempts to map the BSI required data fields with the U.S. CISA defined minimum elements in an effort to support organisations in producing SBOMs that satisfy international interoperability and regulatory requirements.

Data Fields

Technical Guideline BSI TR-03183: Part 2 Software Bill of Materials (6)

Data Fields

U.S. CISA

“Minimum Elements for a

Software Bill of Materials

(SBOM)” (7)

SBOM Metadata

Creator of the SBOM

Email address of the entity that

SBOM Author

The name of the entity that creates the SBOM data for the primary component.

created the SBOM. If no email

address is available this MUST

be a “Uniform Resource Locator

(URL)”, e.g. the creator’s home

page or the project’s web page.

SBOM Version

Identifier designated by the

SBOM Author to specify a

change in the SBOM

document from a previously

identified version or to indicate

that it is the first version.

SBOM-URI

“Uniform Resource Identifier

(URI)” of this SBOM.

SBOM Data Format Name

The name of the data format

used to represent the SBOM

data.

SBOM Data Format Version

Identifier designated by the

SBOM data format to specify

the version of the data format.

-	-		SBOM Author	A digital signature attributable
			Signature	to the SBOM Author.
-	-	SBOM Tool Name		The name of the tool used by

the SBOM Author to generate

or amend the SBOM.

SBOM Tool Version

Identifier for the version of the

tool identified in the SBOM

Tool Name element.

Timestamp

Date and time of the SBOM data

SBOM Timestamp

Record of the date and time of the most recent update to the SBOM data.

compilation according to the

specification of the formats.

Note: It is recommended to only

use timestamps in UTC.

SBOM Generation Context

The relative software lifecycle

phase and data available at

the time the SBOM Author

generated the SBOM (before

build, during build, after build).

Component Data

Component creator

Email address of the entity that

Component Producer

The name of an entity that creates, defines, and identifies components.

created and, if applicable,

maintains the respective

component. If no email address

is available this MUST be a

“Uniform Resource Locator

(URL)”.

Component name

Name assigned to the

Component Name

The name assigned by the Component Producer to a software component.

component by the component

creator. If no name is assigned

this MUST be the actual

filename.

	Filename of the		The actual filename of the
	component		component.
Component version		Identifier used by the creator to specify changes in the component to a previously created version.		Component Version	Identifier used by the

Component Creator to specify

a change in a software

component from a previously

identified version or to indicate

that it is the first version.

Source code URI

“Uniform Resource Identifier

Component Identifiers

Identifier(s) used to identify a component or serve as a look-up key for relevant databases.

(URI)” of the source code of the

component, e.g. the URL of the

utilised source code version in

its repository, or if a version

cannot be specified the utilised

source code repository itself.

	URI of the	“Uniform Resource Identifier
	deployable	(URI)”, which points directly to
	form of the	the deployable form of the
	component	component.
Other unique identifiers		Other identifiers that can be

used to identify the component

or to look it up in relevant

databases, such as Common

Platform Enumeration (CPE) or

Package URL (purl).

URL of the security.txt (optional)

Contains the “Uniform Resource

Locator (URL)” of the

component

creator’s security.txt.

Hash value of the deployable component

Cryptographically secure

Component Hash Value

The output generated from applying a cryptographic hash algorithm to an executable component artifact.

checksum (hash value) of the

deployed/ deployable

component.

Hash value of the source code of the component (optional)

Cryptographically secure

checksum (hash value) of the

component source code. A

specific algorithm how to create

a hash value of multiple source

files or a source code tree, and

which hash algorithm is utilised

for that has not yet been

determined.

Component Hash Algorithm

The cryptographic algorithm

used to compute the

Component Hash Value of the

software component.

Distribution licences

Distribution licence(s) of the

Component License

The identifier(s) for the license(s) under which the software component is available.

component under which it can

be used by a licensee.

Original licences

The licence(s) that have been

assigned by the creator of the

component.

Effective license (optional)

The licence under which the

component is used by the

licensee that is the creator of the

current SBOM.

Dependencies on other components	Enumeration of all components	Component Dependency Relationship		The relationship between two
	on which this component is			components, given that one
	directly dependent, or which this			component is necessary for
	component contains.			the operation of the other.
Executable property	Describes whether the	-	-

component is executable;

possible values are “executable”

and “non-executable”.

Archive property

Describes whether the

component is an archive;

possible values are “archive”

and “no archive”.

Structured property

Describes whether the

component is a structured file,

i.e. metadata of the contents is

still present; possible values are

“structured” and “unstructured”.

Table 1 - Data Models

2.1.2 SBOM Formats

The SBOM format is also a determining factor for interoperability across the software supply chain. Standardized formats provide a common data model that enables software producers, consumers, security tools, vulnerability management platforms, and compliance solutions to process and exchange software composition analysis information in a consistent manner.

ENISA’s SBOM Adoption State of Play 2026 mentions that almost 73% of the organisations use CycloneDX or SPDX.Table 2 presents the two predominant formats based on their current version.

SPDX (System Package Data

CycloneDX V 1.7 (9)

Exchange) V 3.0.1 (8)

Description

Comprehensive framework for

Security-focused approach to software bill of materials, emphasising vulnerability tracking, cryptographic integrity, and comprehensive dependency analysis.

documenting system component

information, with a historical focus

on supporting detailed software

metadata to enable tracking of

vulnerabilities, licensing, and

dependencies for product lines.

Standard/Backing

SPDX® Specification v2.2.1 is an

Ratified as ECMA-424 by ECMA International (11). Maintains a formal standardisation process and governance model through ECMA Technical Committee 54 (TC54). Currently pursuing ISO JTC1 FastTrack.

ISO-standardised format (ISO/IEC

5962:2021).

SPDX 3. in process at ISO to be

listed as an update to ISO/IEC

5962:2021.

SPDX 3.0 has been ratified as an

OMG standard (10).

Key Requirement

Risk Analysis: Providing clear,

Vulnerability Management: Enabling precise correlation between components and security vulnerabilities with native VEX (Vulnerability Exploitability eXchange) support.

machine-readable metadata to

support product line risk analysis,

including vulnerability management

(native CVE & VEX metadata, CSAF

and other formats, precise license

compliance metadata, and

dependency tracking), precise

license compliance metadata, and

dependency tracking.

Supply Chain Transparency:

Security Automation: Facilitating seamless integration with security tools and CI/CD pipelines through lightweight, efficient formats.

Enabling comprehensive component

provenance and cryptographic

integrity, together with rich

relationship options for creation of

knowledge graph.

	Regulatory Alignment: Meeting	Operational Visibility: Documenting not just
	increasing demands for software	static components but runtime services,
	transparency in regulated industries.	APIs, and operational dependencies.
Interoperability: Establishing a common language for software		Cryptographic Integrity: Providing robust

verification mechanisms for supply chain

attestation and component authentication.

composition across diverse

toolchains and ecosystems.

Table 2 - SBOM Formats

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:

	SBOM	Definition	Information Potentially	Indicative Use
	Type		Captured
Design		SBOM 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

Source

SBOM 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

Build

SBOM 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

Analysed

SBOM 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

Deployed

SBOM 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 other	dependencies

SBOMs that

combines analysis of	Platform-specific
configuration options,	libraries

and examination of

execution behavior in

a (potentially

simulated)

deployment

environment.

Runtime

SBOM 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.1 Referințe

1.2 Cerințe identificate

1.3 Reglementări asociate

2. Cerințe identificate

Cerințe
Sursă	Cerință

3. Reglementări asociate

Reglementări
Sursă	Reglementare

ENISA -