ossf/sbom-everywhere

specification for sbom filename

ctcpip opened this issue · 5 comments

ctcpip commented

re: https://github.com/ossf/sbom-everywhere/blob/main/reference/sbom_naming.md

to minimize guesswork and prevent false positives or negatives, can we harden the naming conventions to be more standardized and thus validate conformity with the expected format for the filename?

for example, based on the current recommendation:

sbom.<projectName>-v<versionNumber>-<sbomFormat>.<extension>

which then could be regex validated via:

/sbom\.[a-z0-9-_]+[-_]v\d.+\d.+\d+([-_][a-z]+)?[-_][a-z]+\.[a-z]{3,4}/

or implementations can be more strict, using a list of known or supported types:

/sbom\.[a-z0-9\-_]+[-_]v\d.+\d.+\d+([-_][a-z]+)?[-_]((spdx)|(cdx)|(cyclonedx))\.((json|spdx|xml))/
lumjjb commented
lumjjb commented
zvr commented

The SPDX standard mentions these naming conventions, depending on the format used:

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

@zvr lists the SPDX file extensions above.

@stevespringett referred to https://cyclonedx.org/specification/overview/#recognized-file-patterns which lists these file names and file extensions:

  • bom.json
  • bom.xml
  • *.cdx.json
  • *.cdx.xml

You'll typically want conventional file extensions, not a single filename:

  • It's nice to be able to know the filetype by looking at its extension. You can double-click on the file (to have it do the right thing), HTTP servers can select the correct MIME extension based on the file extension, etc.
  • You can't change the contents of a digitally-signed file without invalidating its signature. I expect many SBOMs to refer to other SBOMs, transitively, so that their digital signatures trivially stay valid (people have tried to have digital signatures over "parts of files" but in practice that is often too fragile).

So I expect in many cases you're going to have a set of SBOM files for "the SBOM", with conventional file extensions.

I would suggest the "sbom" directory when storing SBOMs in source repositories or archives (e.g., zip, .tar.gz, and various package formats that are really archives). Then systems can look at the root directory or the "sbom" directory" for these files. Thoughts?