Convert NTIA tool list into a more GitHub friendly format

[joshbressers]

Work done with NTIA - crowdsourced from NTIA (maybe should merge, because many tools support multiple formats)

Tooling Ecosystem working with SPDX

Tooling Ecosystem working with CycloneDX

Tooling Ecosystem working with SWID

TODO: Turn these into a machine readable format [Kate, Vicky, David, Bunny, Georg]

[stevespringett]

The CycloneDX community created the Tool Center from the original NTIA doc and largely abandoned the doc while NTIA was still referencing it. The current data is located at https://github.com/CycloneDX/cyclonedx.org/blob/master/_data/tools.yml

It uses a similar, but not identical taxonomy.

[joshbressers]

This is starting in this document
https://docs.google.com/document/d/1dSw2JiQCXnWG6NQoFH-S49o_t-cf9RIdJtFWCSPYIQ0/edit#heading=h.3odrrsftedbw

[anoncam]

@joshbressers if you'd like to assign i'm happy to take a stab

[anoncam]

@joshbressers @stevespringett

fair to state that the two formats of viable futures are SPDX and CycloneDX. Bringing this up in the public forum to address alternate formats, which have far less adoption to warrant inclusion at the standardization level of SBOM(s) everywhere.

[stevespringett]

The NTIA effort identified three formats which could be used as SBOM formats. SWID clearly isn't one. OWASP does not recognize SWID as an SBOM format. And CycloneDX natively supports SWID for the identification of commercial software, which is what SWID was designed for.

[gkunz]

Hi @anoncam. Just for clarification: the landscape we are envisioning to create here focuses primarily on providing an overview of available tooling for managing SBOMs. Obviously, the supported SBOM formats is a key property of the tools listed here, but the intention of this work is not really to dive into alternate SBOM formats themselves.

[anoncam]

Agreed. I don't think explicitly stating formatting standards changes that.

Arguably it offloads the focus of formatting to the project level where it is well-documented and supported.

@gkunz

[vmbrasseur]

As I skim the document my first impression is that this is likely far too academic and in the weeds for a first pass at collecting this information. Starting at categorisation—and in such detail—doesn't feel especially actionable/useful at this point.

Wouldn't it be better if we were first to gather a list of tools and then categorise them? That would provide a list for end users/developers to reference in some form while also allowing a better view for comparisons in the categorisation stage.

[joshbressers]

I think @vmbrasseur is on to something. Just having a list of tools would go a long way. Every list I've seen to date is VERY hard to navigate

[kestewart]

@vmbrasseur - did you have a chance to look at the NTIA tool summary individual pages at the start of this thread? The categorization work has already been done based on crowd sourcing. Key is to get an interface so people can find the tools they are interested in "easily".

@joshbressers - I think we need to decide do we want to organize by tools or organize by which format they support? Lots of tools nowaday support multiple formats.

[joshbressers]

@kestewart I'm a fan of organizing by use case and format. Nobody is going to come to us looking for a tool, they will have a specific problem to solve with an expected outcome. We should help them find the best tool for that job

[gkunz]

Given the discussions we had on the last call, which revolved around how this work fits into the larger picture of the SIG, I'd like to give it a try to detail the scope of this work item (according to my understanding). This may be considered input for #12 :

"The purpose of this work item is to create a landscape, i.e., a human-friendly navigatable list of SBOM tools, which allows users to identify relevant tools based on filters (e.g., use cases, capabilities, formats supported etc.). The data for this landscape should be sourced from the NTIA documents listed above. The value of this is to help users in identifying the right SBOM tool for their problem, thereby supporting the adoption of SBOMs across the industry."

This can be considered complementary to the idea of promoting a short list of specific tools, this SIG recommends for adoption by open source projects.