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.

“Minimum Elements for a

Software Bill of Materials

(SBOM)” (7)

SBOM Metadata

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 Author to specify a

change in the SBOM

document from a previously

identified version or to indicate

that it is the first version.

(URI)” of this SBOM.

used to represent the SBOM

data.

SBOM data format to specify

the version of the data format.

the SBOM Author to generate

or amend the SBOM.

tool identified in the SBOM

Tool Name element.

compilation according to the

specification of the formats.

Note: It is recommended to only

use timestamps in UTC.

phase and data available at

the time the SBOM Author

generated the SBOM (before

build, during build, after build).

Component Data

created and, if applicable,

maintains the respective

component. If no email address

is available this MUST be a

“Uniform Resource Locator

(URL)”.

component by the component

creator. If no name is assigned

this MUST be the actual

filename.

Component Creator to specify

a change in a software

component from a previously

identified version or to indicate

that it is the first version.

(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.

used to identify the component

or to look it up in relevant

databases, such as Common

Platform Enumeration (CPE) or

Package URL (purl).

Locator (URL)” of the

component

creator’s security.txt.

checksum (hash value) of the

deployed/ deployable

component.

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.

used to compute the

Component Hash Value of the

software component.

component under which it can

be used by a licensee.

assigned by the creator of the

component.

component is used by the

licensee that is the creator of the

current SBOM.

component is executable;

possible values are “executable”

and “non-executable”.

component is an archive;

possible values are “archive”

and “no archive”.

component is a structured file,

i.e. metadata of the contents is

still present; possible values are

“structured” and “unstructured”.

Table 1 - Data Models

1. Pārskats

1.1 Atsauces

1.2 Identificētās prasības

1.3 Saistītie tiesību akti

2. Identificētās prasības

3. Saistītie tiesību akti

• ENISA -