sbom: use relationship data to reconstruct package files

[jedevc]

⬆️ Follow-up to #6.

Scanners producing SPDX documents do not neccessarily use the hasFiles key to define available files belonging to a package.

We need to use the relationship data to reconstruct this information.

[tonistiigi]

Scanners producing SPDX documents do not neccessarily use

"do not neccessarily use" or never use it without relationship to doc level file being defined as well?

[jedevc]

"do not neccessarily use" or never use it without relationship to doc level file being defined as well?

The field is now deprecated - but ugh, yeah, this doesn't guarantee that people produce it or not. We could do both? Just to be sure? That said, it's not even really documented in the most recent spec, so I'm tempted to just omit it - we can always add it back if people add support for scanners that do this.

[tonistiigi]

We could do both?

I think it is simple enough to have that additional check.

[jedevc]

On further inspection, the new SPDX parser in https://github.com/spdx/tools-golang/ doesn't support extracting the old hasFiles field at all.

Glancing over the specs in https://spdx.dev/specifications/, it looks like hasFile was deprecated entirely with SPDX 2 - I don't believe it's something worth supporting, given that SPDX 2.0 was released in 2015.

So any SBOM generator that still produces these deprecated fields shouldn't be.