Idea for the SBOM study group #10
Description
Thinking loud here, maybe this does not make sense...
I was reading https://github.com/OpenChain-Project/OpenChain-JWG/blob/master/subgroups/sbom-sg/meetings/20250203.en.md and started to think that there are thousands of organizations around the world and some have systems and databases that provide, e.g.
- A database of all 3rd party components
- A database of all products and product versions that the organization produces
- A linkage between 3rd party components and products and versions
- A linkage between product versions and 3rd party components needed to build those products (versions)
Now obviously each 3rd party component in the DB comes with metadata and depending on the organization they may put more emphasis on different metadata.
The idea that I started to think is:
Would it make sense to create a high-level blueprint of a system that would enable an organization to implement a system that enables them to
- ingest SBOM documents from upstream providers with required metadata, then
- parse and store the SBOM data in the DB (original SBOM document would of course be stored as well)
- maybe add more metadata as needed, e.g. is the component deprecated, project health metrics, etc.
- what to do if the same (?) 3rd party component is coming, but with (slightly) different metadata, but for example the PURL may be the same with the already stored 3rd party component
- add new vulnerability data when new vulnerabilities are discovered
- the organization would of course add its own development to the DB
- generate SBOM documents in different formats (SPDX, CDX, Excel, ...)
- generate VEX documents in different formats
- generate SBOM documents with embedded VEX document
For the OpenChain Project, this may become too close to how, but maybe we could think of higher level what specification and requirements for such a system.