Open smlambert opened 7 months ago
Agreed. The next steps are described in the original proposal as we move to steps two and three.
I have proposed that the VDR generator uses an action to create a PR to update the Temurin VDR document. This is a similar approach to the Temurin marketplace data updater.
- Link to it from GA release SBOMs (using the CycloneDX format that can link these documents)
The plan is to have an independent VDR BOM as a single report covering all versions of the Temurin product, rather than an embedded VDR BOM, so that we can update it with new vulnerability information after (possibly months/years after) a Temurin release is published.
It will be linked from the release SBOM, but as an Adoptium API call, e.g. https://api.adoptium.net/v3/info/temurin-vdr.json
used by all.
- Use it as an input to help generate the release blog post (which has a manually created CVE table at the moment)
Yes, like the machine format bug reports (e.g. jdk17 json), once we have the data we can render it in human-readable formats, including a blog post and webpage.
- Consume it as part of a regular run to verify its validity (and mirror what our enterprise consumers would experience)
+1 sanity check the format and test consumption using BOM tools. Hopefully we can grow this as we learn the dominant tools in this space that work with VDRs.
EDIT: Updated to show the access to the VDR should be through the API.
https://cyclonedx.org/tool-center/ - looking at those that are 'open-source' and 'analysis' as potential ones to use for consuming VDR and SBOM files to give opinions on 'next actions' to take
Pending https://github.com/adoptium/temurin-vdr-generator/issues/7 and having a 'latest' vdr.json artifact to be able to retrieve, we can identify the various ways we would like to utilize this report: