OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

csaf-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: SBOMs are mostly hidden


Dear CSAF Working Group,

I hope this message finds you well. As a newcomer to CSAF, I've been exploring the documentation and wanted to share some insights and suggestions regarding the inclusion of Software Bill of Materials (SBOM) URLs within CSAF documents.
The search feature onÂhttps://lists.oasis-open.org/archives/csaf/ is broken, so I couldn't figure out if someone asked my following questions already.

In my experience within the DevOps landscape, SBOMs are frequently bundled within container images or provided alongside product releases (e.g. on github.com). For instance, projects like the OWASP Juice Shop distribute SBOMs along with their releases, which can be found on their respective release pages.

When considering how to reference SBOMs within CSAF documents, the question arises regarding https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.html#31335-full-product-name-type---product-identification-helper---sbom-urls :
Should the URL point to a generic location where the SBOM can be found (such as the release page https://github.com/juice-shop/juice-shop/releases/tag/v16.0.0), or should it be specific to a particular version (https://github.com/juice-shop/juice-shop/releases/download/v16.0.0/juice-shop-16.0.0_node18_linux_x64.tgz)? While CSAF documents can include version information, it would be beneficial to provide guidance on the preferred approach within the standard itself.

As a CSAF user, I might want to download the referenced SBOM automatically. In that case, the path within the container (e.g. zip/tgz) needs to be provided. For example with an anchor URL:
https://github.com/juice-shop/juice-shop/releases/download/v16.0.0/juice-shop-16.0.0_node18_linux_x64.tgz#/juice-shop/sbom.json

Personally, I advocate for including specific version links whenever possible. This practice enhances traceability and clarity, especially in scenarios where multiple SBOM versions may exist due to updates or releases.

Additionally, I'd like to propose a standardized format for referencing SBOMs within container images. Given that containers utilizes the double colon (:) in the copy command, a similar syntax could be adopted for SBOM references:

```
docker://<image>:<path in image> Â# Or with the tag
docker://<image>:tag:<path in image>
```
For example, in the case of the Juice Shop image, the SBOM could be referenced as follows:
```
docker://bkimminich/juice-shop:v16.0.0:/juice-shop/sbom.json
```
This format provides a clear and consistent method for accessing SBOMs within container images. An alternative would be "podman://" or a container technology independentÂ"container://" which I didn't see beforehand.

Thank you for considering these suggestions, and I look forward to contributing further to the improvement of CSAF standards.

Best regards,
Timo


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]