Parlay should add itself as a tool in the SBOM

[vpetersson]

I'm part of the CISA Tiger Team for SBOM Generation. We've adopted Parlay as part of the reference implementation. It generally speaking works fine, but we're missing one relatively small detail, namely that Parlay should add itself as a tools in the pipeline (metadata.tools in CycloneDX).

We're currently working around this by appending parlay with sbomasm, but it would be great if this wasn't a necessary step.

[mcombuechen]

Hey @vpetersson
there is an old (stale) discussion on this topic here: #11
There was some pushback on the idea of inserting parlay as a tool into the SBOM as it effectively alters creation data. However, I'm open to reviving this discussion and re-assess whether this isn't complete adequate. As parlay's enrichment insert new data anyawy, why not an additional entry to the tools section of the SBOM?

[vpetersson]

(@goneall is in fact part of the Tiger Team too for context.)

A fair point is raised in the discussion in #11. From our vantage point however, the generation and the enrichment happens in the same CI/CD workflow. Thus the creation timestamp is less of an issue. If this is more of a manual process, the timestamp might of course be more of an issue.

Perhaps this is a feature that should be enabled by default, but could be disabled with an argument?

[goneall]

In the scenario the SBOM Generation tiger team is using Parlay, adding the tool should be fine since the original SBOM is never really "published". Where we would get into trouble is if we have 2 SBOMs published with exactly the same namespace URI (similar to the CDX serial number). Many systems (including some I've written) depend on the namespace being unique.

Could we created a unique SPDX document namespace as part of the Parlay (e.g. append "/parley-enhanced")? If you want to relate back to the original document, you can add an Amends relationship between the docs. I can provide an example if this is helpful.

[mcombuechen]

Perhaps this is a feature that should be enabled by default, but could be disabled with an argument?

I was having the same thought, a possibility to opt out of this. Sounds good!

Could we created a unique SPDX document namespace as part of the Parlay (e.g. append "/parley-enhanced")?

you can add an Amends relationship between the docs

I feel like both things are something we'd want regardless of the additional entry to the list of tools. Parlay is changing the original document in other ways depending on what enrichment strategy you chose, this should probably be reflected on the namespace, serial number anyway. Again, we could offer a way to opt out of this if it's not desired.

@goneall an example would be really helpful!

[goneall]

@mcombuechen - I created a pull request in the SPDX examples repo with what I would propose are additional fields for any tool which modifies an SPDX document: https://github.com/spdx/spdx-examples/tree/enrich/software/example14

Let me know if you have any questions.