Rethink how SBOMs are ingested / modelled
Right now, SBOMs require a Repo Key when importing them, which ties them quite strongly to the understanding of where that SBOM has come from.
However, at the time of ingestion, this isn't necessarily known.
Instead, we could:
- Remove
platform
,organisation
andrepo
fromsboms
- Create a
sboms_metadata
table, that can beLEFT JOIN
'd to retrieve the Repo Key, if known- Alternatively
sboms_repokey
- Alternatively
- Relax the
import sbom
/import bulk
requirements
This would have the follow-on of making i.e. platform
a nullable field when querying via GraphQL, or in reports, so we'd need to consider this.
This then would also lead into #352's ability to import generic SBOMs.
Additionally, this will affect how SBOMs + ownership info shows up, which then may cause issues for uniqueness due to NULL
s?
TODO:
-
SBOM parsing pass filename, optional Repo Key -
Missing data gen -
Basename the filename? -
Validate the repo key in the DB -
allow multiple SBOMs
Edited by Jamie Tanna