Identify the various ways we want to utilize the VDR report

[smlambert]

Pending #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:

• Link to it from GA release SBOMs (using the CycloneDX format that can link these documents)
• Use it as an input to help generate the release blog post (which has a manually created CVE table at the moment)
• Consume it as part of a regular run to verify its validity (and mirror what our enterprise consumers would experience)
• etc.

[tellison]

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.