You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 #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:
The text was updated successfully, but these errors were encountered: