+3.1 SBOM Threats

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

STRIDEThreatThreat ScenarioPotential ImpactIndicative Mitigation Activities
SpoofingSpoofed Identity of SBOM Author or Software ProducerImpersonation of aTrust and use malicious software or compromised components.
  • Digital signatures
  • Supplier identity verification

legitimate SBOM

Author or Software

producer to

distribute

compromised

SBOM.

Spoofed Consumer IdentityImpersonation 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 pipelinesSBOM appears toTrust in malicious software provenance.
  • Build attestations
be generated from a
  • Build Attestation
trusted CI/CD
  • Authenticated CI/CD
pipeline.pipelines
Spoofed SBOM generation toolA malicious toolTrust and use
  • Trusted tool use
  • Code signing
generates SBOMmalicious or
that appear to becompromised
valid.SBOM.
Spoofed certificatesStolen 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 mirrorCompromised 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

TamperingTampered SBOM dataComponents,Incorrect dependency analysis and vulnerability identification.
  • Integrity verification
  • Signature verification

versions or

dependency

relationships are

tampered (added,

deleted, or altered)

after generation.

Tampered metadataComponentInaccurate
  • Cryptographic integrity check
versions, hashes,software
licenses or suppliersinventories and
are tampered beforecompliance
SBOM generation.breach.
Tampered hashesCryptographic hashes are altered.Lack of proper
  • Document Signature

artifact

verification.

Tampered provenanceBuild provenance is altered.Trust and use
  • Signed attestations

malicious SBOM

appearing to be

from a trusted

source.

Tampered external referencesPURLs 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.

RepudiationSoftware Producer or SBOM Author repudiationSoftware ProducerLack of accountability.
  • Digital signatures
  • Timestamps
  • Audit logs

or SBOM Author

denies the

generation or

publication of

SBOM.

Distribution repudiationSBOM Author orReduced supply chain transparency.
  • Repository logging
  • Signed releases

Software producer

denies the

distribution of an

SBOM.

Information DisclosureTechnology stack disclosureLack of controlledAssist attacker to
  • Controlled SBOM sharing
  • Access control
SBOM sharingconduct
reveals softwarereconnaissance
frameworks andand increase
versions.attack surface.
Component disclosureProprietary softwareIntellectual
  • Controlled SBOM
componentsproperty rightssharing
become visible.breach.
  • Access control
Supplier relationship disclosureSupplierIncreased attack surface and more targeted attacks.
  • Controlled SBOM sharing
  • Access control

relationships

become publicly

visible.

Dependency graph disclosureSoftwareIncreased attack surface and more targeted attacks.
  • Controlled SBOM sharing
  • Access control

architecture and

dependency

relationships

become publicly

visible.

Version disclosureExact softwareFaster exploitation using known CVEs.
  • Controlled SBOM sharing
  • Access control

versions enable

vulnerability

mapping.

Cryptographic material / metadata disclosureEmbeddedAssist 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 ServiceSBOM repository DoSSBOM repositories are not available.SBOM
  • Redundant infrastructure
  • DDoS protection

unavailable during

incident response

or procurement.

Parser DoSExtremely large orResource exhaustion and parser failures.
  • SBOM size limitation
  • Parser hardening

deeply nested

SBOM cause

excessive

computation and

exhaust parser

resources.

Storage DoSLarge 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 PrivilegeCI/CD pipeline privilege escalationElevated privileges in the build pipeline generating SBOMs.Corrupted SBOM
  • Access control
  • CI/CD pipeline hardening

generation that

appears to be

legitimate.

SBOM repository privilege escalationUnauthorised access to SBOM repository.Use and
  • Access control

distribution of

compromised

SBOM.

Signing Infrastructure privilege escalationCompromisedUse and trust of compromised SBOM.
  • Key management
  • Access control

infrastructure

creates trusted

SBOM.

Table 5 - SBOM Threat Model

1. Overzicht

1.1 Referenties

1.2 Geïdentificeerde eisen

1.3 Gerelateerde regelingen

2. Geïdentificeerde eisen

Eisen

3. Gerelateerde regelingen

Regelingen