+3. SBOM Threats and Risks
---+3.1 SBOM Threats
---+3.2 SBOM General Risks

3. SBOM Threats and Risks

SBOM Threats and Risks

1. Přehled

3.1 SBOM Threats

This section presents an SBOM focused STRIDE threat model to support organisations in the identification and mitigation of threats across the SBOM lifecycle. The STRIDE threat model, developed by Microsoft, provides a structured framework for the continuous assessment of threats. It is divided in six categories: S poofing, T ampering, R epudiation, I nformation disclosure, D enial of service and E levation of privilege.

The identified threats not only focus on the SBOM artifact but rather on the entire SBOM ecosystem (e.g., SBOM generation tools, validation and signing service, repositories, consumption pipelines) (Table 5).

STRIDE	Threat	Threat Scenario		Potential Impact	Indicative Mitigation Activities
Spoofing	Spoofed Identity of SBOM Author or Software Producer		Impersonation of a	Trust and use malicious software or compromised components.	Digital signatures Supplier identity verification

legitimate SBOM

Author or Software

producer to

distribute

compromised

SBOM.

Spoofed Consumer Identity

Impersonation of a legitimate consumer to gain unauthorised access to restricted SBOM.

Gain access to

Consumer identity verification
Controlled SBOM sharing

restricted

information that

assist attacker

reconnaissance

and targeted

attacks.

Spoofed CI/CD pipelines		SBOM appears to	Trust in malicious software provenance.			Build attestations
		be generated from a				Build Attestation
		trusted CI/CD				Authenticated CI/CD
		pipeline.				pipelines
Spoofed SBOM generation tool		A malicious tool		Trust and use	Trusted tool use Code signing
		generates SBOM		malicious or
		that appear to be		compromised
		valid.		SBOM.
Spoofed certificates	Stolen certificates are used to sign malicious SBOM.			Trust and use	Secure key Management Certificate revocation

malicious SBOM

appearing to be

legitimate from a

trusted source.

Spoofed SBOM repository mirror

Compromised repository mirror distributes malicious SBOM appearing to be legitimate.

Trust and use malicious SBOM appearing to be legitimate from a trusted source.

SBOM Signature

verification

Compare

cryptographic hashes

against trusted

metadata

Monitor repository

certificates

Tampering

Tampered SBOM data

Components,

Incorrect dependency analysis and vulnerability identification.

Integrity verification
Signature verification

versions or

dependency

relationships are

tampered (added,

deleted, or altered)

after generation.

Tampered metadata		Component	Inaccurate	Cryptographic integrity check
		versions, hashes,	software
		licenses or suppliers	inventories and
		are tampered before	compliance
		SBOM generation.	breach.
Tampered hashes	Cryptographic hashes are altered.		Lack of proper	Document Signature

artifact

verification.

Tampered provenance

Build provenance is altered.

Trust and use

Signed attestations

malicious SBOM

appearing to be

from a trusted

source.

Tampered external references

PURLs or CPEs are altered.

Use and act upon

Digital signatures
External references verification

compromised

resources

appearing as

known and trusted

to conduct

vulnerability

matching and

assessment.

Repudiation

Software Producer or SBOM Author repudiation

Software Producer

Lack of accountability.

Digital signatures
Timestamps
Audit logs

or SBOM Author

denies the

generation or

publication of

SBOM.

Distribution repudiation

SBOM Author or

Reduced supply chain transparency.

Repository logging
Signed releases

Software producer

denies the

distribution of an

SBOM.

Information Disclosure	Technology stack disclosure	Lack of controlled		Assist attacker to	Controlled SBOM sharing Access control
		SBOM sharing		conduct
		reveals software		reconnaissance
		frameworks and		and increase
		versions.		attack surface.
	Component disclosure	Proprietary software		Intellectual		Controlled SBOM
		components		property rights		sharing
		become visible.		breach.		Access control
	Supplier relationship disclosure	Supplier	Increased attack surface and more targeted attacks.		Controlled SBOM sharing Access control

relationships

become publicly

visible.

Dependency graph disclosure

Software

Increased attack surface and more targeted attacks.

Controlled SBOM sharing
Access control

architecture and

dependency

relationships

become publicly

visible.

Version disclosure

Exact software

Faster exploitation using known CVEs.

Controlled SBOM sharing
Access control

versions enable

vulnerability

mapping.

Cryptographic material / metadata disclosure

Embedded

Assist attacker to conduct reconnaissance and increase attack surface.

Key management
Access control
Audit Logging

certificates or key

identifiers leak trust

relationships.

Hashes or identifiers

reveal internal

release processes.

Denial of Service

SBOM repository DoS

SBOM repositories are not available.

SBOM

Redundant infrastructure
DDoS protection

unavailable during

incident response

or procurement.

Parser DoS

Extremely large or

Resource exhaustion and parser failures.

SBOM size limitation
Parser hardening

deeply nested

SBOM cause

excessive

computation and

exhaust parser

resources.

Storage DoS

Large number of SBOM exhaust repository capacity.

Resource

SBOM size and number limitation.
SBOM Retention Policy

exhaustion and

potential

disruption of the

CI/CD pipelines if

SBOM is a

mandatory step.

Elevation of Privilege

CI/CD pipeline privilege escalation

Elevated privileges in the build pipeline generating SBOMs.

Corrupted SBOM

Access control
CI/CD pipeline hardening

generation that

appears to be

legitimate.

SBOM repository privilege escalation

Unauthorised access to SBOM repository.

Use and

Access control

distribution of

compromised

SBOM.

Signing Infrastructure privilege escalation

Compromised

Use and trust of compromised SBOM.

Key management
Access control

infrastructure

creates trusted

SBOM.

Table 5 - SBOM Threat Model

3.2 SBOM General Risks

Complementary to the identification of threats, this section presents some general risks that jeopardise the SBOM accuracy, integrity and operationalisation. Table 6 lists indicative risk scenarios, their potential impact and suggested mitigation activities.

Risk

Risk Scenario

Potential impact

ndicative Mitigation

Activities

Non-standardised SBOM Format	SBOMs generated using	Reduced interoperability between producers and consumers.	Generate SBOMs using established standards, such as SPDX or CycloneDX	Generate SBOMs
	a proprietary, custom,			using established
	unstructured, or			standards, such as
	otherwise non-			SPDX or CycloneDX

interoperable format.

SBOM in a Non-Machine-Readable Format	SBOMs provided only in	Reduced automation	SBOMs in a machine-readable format suitable for automated processing
	a format intended	and scalability of SBOM
	primarily for human	consumption and
	consumption.	inability to automatically correlate components

with vulnerability

databases.

Incomplete SBOM

Components or dependencies are not fully covered by the SBOM.

Vulnerabilities remain undiscovered and software inventory is incomplete.

Automatic generation

at release

CI/CD integration
Documented treatment

of known unknowns and

missing metadata

Outdated SBOM

The SBOM no longer reflects the current version of the software.

Insufficient vulnerability

Regenerate SBOMs based on the above identified triggers

management and

inaccurate risk

assessment.

Poor component identification

Components are not uniquely identified across ecosystems.

Inaccurate vulnerability correlation and matching.

Use standardised

ecosystem-aware

component identifiers.

Use repository URL

from upstream source

repository, OR

Use Package URL

combined with

namespace, exact

version, and

cryptographic hashes

where applicable OR

Use CPE, following

naming convention

consistently with

namespace, exact

version and

cryptographic hashes

where applicable

Insufficient SBOM Accuracy

SBOM generation tools

Excessive vulnerability alerts and alert fatigue due to false-positive components, missed vulnerabilities due to omitted or incorrectly identified components and/ or incorrect vulnerability matching.

Select appropriate SBOM generation techniques according to the software ecosystem, build process, artifact type, and intended SBOM use case,
Validate generated SBOMs against S/W artifacts,
Perform completeness and accuracy checks,
Validate component identifiers

relying on heuristic

analysis to identify

components and

dependencies, generate

SBOMs that may contain

components that are not

actually present or used

(false positives), omit

components that are

present (false

negatives), or incorrectly

report versions,

dependency

relationships, or

identifiers.

Weak SBOM-to-Artifact Binding	SBOMs not strongly and	Incorrect SBOM may be used for vulnerability analysis increasing false positives or false negatives in vulnerability matching.	Cryptographically bind
	unambiguously		the SBOM to the exact
	associated with the		artifact using a
	exact software artifact,		cryptographic hash or
	build, release, container		immutable digest
	image, or package that it		Verify the SBOM-to-
	describes.		artifact association

Limited SBOM operationalization

SBOMs are generated but not integrated into the SDLC.

Reduced value from SBOM adoption and ineffective vulnerability management.

Consume SBOMs for

asset management,

vulnerability

management, license

compliance etc.

Insufficient SBOM Retention and Lifecycle Evidence

Failure to retain historical SBOMs and their associated evidence (e.g. previous SBOM versions, build identifiers, artifact digests, signatures, VEX documents) for an adequate period.

Inability to determine whether historical or deployed software versions contain a newly discovered vulnerable component.

Define an SBOM

retention policy

Retain SBOMs per

release

Maintain version

history

Maintain SBOM-to-

artifact traceability

Define lifecycle

disposal procedures

Lack of vulnerability prioritization

Every vulnerability identified through the SBOM is treated equally without considering exploitability.

Vulnerability overflooding and delayed remediation of highly targeted vulnerabilities.

Combine SBOM data

with VEX to assess

exploitability and

reachability

Incorporate asset

criticality and exposure

Establish risk-based

vulnerability prioritization

process

Table 6 - SBOM General Risks

1.1 Odkazy

1.2 Identifikované požadavky

1.3 Související regulace

2. Identifikované požadavky

Požadavky
Zdroj	Požadavek

3. Související regulace

Regulace
Zdroj	Regulace

ENISA -