ossf
specification for sbom filename
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))/
Refer to https://cyclonedx.org/specification/overview/#recognized-file-patterns
I think having name specifications with that level of specificity as proposed in the opening comment will result in naming collisions.
I am a proponent of adding the [format].json as the ending but I think the rest should be more open due to multiple types of sboms (source, build) or sboms from different tooling. In addition sboms can describe more than one piece of software.
On Wed, Aug 2, 2023 at 2:08 AM Steve Springett @.***> wrote:
Refer to https://cyclonedx.org/specification/overview/#recognized-file-patterns
— Reply to this email directly, view it on GitHub https://github.com/ossf/sbom-everywhere/issues/32#issuecomment-1661549926, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXLDBUZHIQXCYWMAZ6YS6TXTHVE3ANCNFSM6AAAAAA277BDZU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
I realize perhaps some of the concern I have is with the current proposed so please ignore them for this issue.
The current wording is a recommendation but I think shouldn’t be something we enforce programmatically.
On Wed, Aug 2, 2023 at 9:14 AM Brandon Lum @.***> wrote:
I think having name specifications with that level of specificity as proposed in the opening comment will result in naming collisions.
I am a proponent of adding the [format].json as the ending but I think the rest should be more open due to multiple types of sboms (source, build) or sboms from different tooling. In addition sboms can describe more than one piece of software.
On Wed, Aug 2, 2023 at 2:08 AM Steve Springett @.***> wrote:
Refer to https://cyclonedx.org/specification/overview/#recognized-file-patterns
— Reply to this email directly, view it on GitHub https://github.com/ossf/sbom-everywhere/issues/32#issuecomment-1661549926, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXLDBUZHIQXCYWMAZ6YS6TXTHVE3ANCNFSM6AAAAAA277BDZU . You are receiving this because you are subscribed to this thread.Message ID: @.***>
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?
