Adapt new and existing package metadata as SPDX relationships

[wagoodman]

SPDX has the concept of relationships that can be applied to packages, files, or other artifacts. This issue aims to explore what existing metadata can be expressed via SPDX relationships as well as potentially add more metadata to collect via the catalogers that can be expressed as SPDX relationships.

Internal to syft there is already the concept of package-to-package relationships, what isn't clear is if this should be further expanded generally or isolated only to the SPDX presenter (which is generally a new concept, since all data typically gets expressed via the JSON model first).

[spiffcs]

I've been doing research on this since Friday afternoon and this AM. The first questions I have concerns this repository:
https://github.com/spdx/tools-golang

The library is hosted by the spdx organization and defines roughly the same model we do in presenter/packagers/model/spdx22.

If we want to express SPDX relationships for 2.2 correctly I think the first discussion should be around if we move to their model or keep our presenter model.

The tough part with this proposal is that their model is not designed as a presenter (no JSON tags).

They take a pretty interesting approach as far as marshalling/unmarshalling.

Check out their parsing code here.

@wagoodman if you have time today can we talk a bit about the complexity of juggling our JSON model against the spdx tool model and then wrapping that into a "correct" presenter?

[kzantow]

One thing of note: I think CycloneDX also has a way of specifying dependencies using a bom-ref: https://cyclonedx.org/use-cases/#dependency-graph so we would quite possibly want this handled somehow in our own model. Although it is possible this is just a reference within the own document, it's a bit unclear to me.

[spiffcs]

Added - #507 as a starting point to build out the initial ROOT --> Package relationships. This PR makes the assumption that packages discovered by the cataloger are all directly related to the scanned image/directory.

[spiffcs]

#507 has been updated to now populate Files and include vertices between Packages and Files in the Relationships field

[spiffcs]

Before we dig further into relationships it's probably worth tackling some of the prioritized bugs we have surrounding SPDX. I pulled in #460 to make some progress in cleaning up our license section.

[spiffcs]

@luhring The next steps for making this better is starting to dive on the architecture changes we talked about on Monday.

#516

We'll work on refining this issue so we have a clear path to get syfts command API in the right place.

[wagoodman]

I've broken out package relationships work into #572 such that package catalogers raise this information before presenters/formats can leverage them (such as SPDX).