SBOM Naming

[anthonyharrison]

Comments on proposed SBOM Naming scheme

General comment. This looks very much like it is written from the point of view of creating a source level SBOM. As there are other SBOM types to be considered, need to ensure that the document covers these as well

Specific comments

1. There are already suggested naming conventions for files in SPDX (section 4.4). I suggest we adopt these rather than introduce a new ones

Format	Extension
tag:value	*.spdx
RDF	*.spdx.rdf
JSON	*.spdx.json
XML	*.spdx.xml
YAML	.spdx.yaml or .spdx.yml

Cyclonedx can then be .json or .xml.

This fits in with the standards adopted by many of the tools already generating and consuming SBOMs.

I am not a fan of including version information in filenames. Project name should be implicit by context.

2 Directory Structure

Agree that a dedicated directory is required but need to recognise that not all SBOMs are related to source code/exist in a source code repository.

Suggest that directory is structured with separate sub-directories to represent the different SBOM types created at different stages of the lifecycle e.g. source, build, runtime etc

4 Versioning

Is this not implicit if we are saying that every software release must include an SBOM?

6 Automation

Not sure what this has got to do with naming. This is just an SBOM best practice

[ctcpip]

duplicate of #32

[david-a-wheeler]

The current text suggests that the suffix end in _spdx.json and _cyclonedx.xml. It gives as its examples sbom.projectname_v1.2.3_spdx.json or sbom.projectname_v1.2.3_cyclonedx.xml.

I do NOT recommend this file naming format; the underscore seems wrong here.

I think the file naming extensions should be of the form .spdx.json and E.g.: https://github.com/spdx/tools-java/blob/master/testResources/SPDXJSONExample-v2.2.spdx.json

Recommend changing _spdx and _cyclonedx to use . instead of _. Note that this issue (34) ALSO uses periods and not underscores.

[ljharb]

i 100% agree, the underscores are weird.

I think it should also be inside a directory, since there are likely to be many types of SBOMs, and a single dir is cleaner than N files.

[stevespringett]

Recognized CycloneDX file patterns are here: https://cyclonedx.org/specification/overview/#recognized-file-patterns.

I think one thing to recognize about "SBOM Naming" is that it misses the bigger picture. SPDX and CycloneDX are just formats. CycloneDX was designed to be a BOM standard and transparency exchange format for software and systems. As such, it supports:

• SBOM
• SaaSBOM
• HBOM
• ML-BOM (AI-BOM)
• MBOM
• VDR
• VEX
• CBOM (coming in Q4)
• Attestations (coming in Q4)

SPDX currently just supports SBOM, but I know some of the others are in the works.

My point is that what would be the recommended naming conventions for an open source project where they provide and SBOM and MBOM for a given release?

I think there's a general assumption that the PURPOSE of the SPDX or CDX to be published is for SBOM. However, that's a false assumption. Open source projects are already creating VEX and MBOM for their given releases and will likely create more variety in the future. IMO, the purpose of the document should likely be incorporated into the naming conventions as to prevent duplicate filenames.

[stevespringett]

So, do we want something like *.sbom.spdx.json and *.sbom.cdx.json?

[ljharb]

That also seems fine - but I still think there should be a single, conventionally named directory at the root of a project that's meant to contain all of these files.

[joshbressers]

I'm closing this as this is now covered in the naming document at https://github.com/ossf/sbom-everywhere/blob/main/reference/sbom_naming.md