RE: [csaf-comment] SBOMs are mostly hidden

["Schmidt, Thomas" <thomas.schmidt@bsi.bund.de>]

Dear Mr. Pagel,
thank you for your comments. Please find my comments inline.

Best regards,
Thomas Schmidt

-- 
Thomas Schmidt

----------------------------------------
> From: csaf-comment@lists.oasis-open.org <csaf-comment@lists.oasis-open.org> On Behalf Of Timo Pagel
> Sent: Friday, February 16, 2024 2:49 PM
> To: csaf-comment@lists.oasis-open.org
> Subject: [csaf-comment] 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.

No worries. The issue is known and will (hopefully) be fixed by our new mail system which is going to be deployed next week. (During the migration, emails might not be delivered to the list.)

> In my experience within the DevOps landscape, SBOMs are frequently bundled within container images or provided alongside product releases (e.g. on http://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.

The URL should link directly to the SBOM, not to a generic download page.

> 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

In general, I think that makes sense. However, I wouldn't want to come up with a format just for CSAF. So my question is, whether this is already used / specified elsewhere? Please comment in GitHub issue: https://github.com/oasis-tcs/csaf/issues/689

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

As the SBOM URL should be a helper to identify the product, it is essential that it is software version specific. However, IMHO it does not make a difference which version of the SBOM (hopefully the latest) gets delivered.

>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
> ```

Has `docker` been registered as authoritative scheme? If not, we can't use the `//`. Is that syntax already used elsewhere (e.g. RFC, CycloneDX, SPDX,...)? Please comment in GitHub issue: https://github.com/oasis-tcs/csaf/issues/690

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

Same as above.

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