Find a way to group SBOMs

[ctron]

The idea is to be able to group multiple SBOM revisions for the same product "Foo Product 1.2".

[carlosthe19916]

Random thoughts:

Versioning could be the very first grouping we support

I believe each spec CycloneDX/SPDX already supports versioning. For instance: an application has "N" SBOMs then each has a version in CycloneDX:

We could use the version of each spec to group multiple sboms.

Problem: The spec versioning does not necessarily match the app versioning. e.g. The SBOM can have version=1 but the application is releasing the version1.0.0.Final of the application.

With the current way of consuming SBOMs, we will need to figure out how to play with the values of each SBOM to create groups.

The root of the problem

This is something I gave a thought multiple times in the past and I always arrive to the same conclusion: THE PULLING APPROACH FOR SBOMs SHOULD NOT BE THE WAY TO GO ON THE LONG TERM. Let me explain:

• csaf/vex files: we have a "walker/importer" where we continuously PULL data from different resources to feed the system. This is 100% correct to me,
• sbom files: we are applying the same approach, we PULL data from different resource to ingest SBOMs. This is the wrong part to me. For SBOMs we should follow the PUSH approach and not the PULL approach.

Whoever is generating the SBOMs (an CI pipeline or a human in his terminal) should always push his SBOM directly to Trustify without any third party in the middle. This gives us the advantage that whoever is the phase of creating the SBOM know details that are important like "grouping", "versioning", etc and that data is lost with our current approach of PULLING

We should think on an SBOM just like we think on a "container image". And we should think on Trustify just as we think on a "Container Registry".

Current approach (Pull)

graph TD;
    SBOM_GENERATOR_CI_PIPELINE-->STORAGE_From_where_we_currently_pull_data_with_walker;
    Trustify-->STORAGE_From_where_we_currently_pull_data_with_walker;

Loading

How I think we should do things (nothing in the middle between who creates the SBOM and Trustify):

graph TD;
    SBOM_GENERATOR_CI_PIPELINE-->Trustify;

Loading

If we remove the thing in the middle we could design a similar/better approach as the container registry has for tagging, versioning, and grouping multiple SBOMs (SBOMs are treated as container images)

[jcrossley3]

Interesting. I think of trustify's api server as ONLY supporting pushing: all docs (sbom/vex/csaf) are POST'ed to trustify. The walkers are just a convenient way to post a repository full of them. Posting a single doc or a collection is up to the user.