Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Identify the various ways we want to utilize the VDR report #8

Open
smlambert opened this issue Apr 26, 2024 · 2 comments
Open

Identify the various ways we want to utilize the VDR report #8

smlambert opened this issue Apr 26, 2024 · 2 comments

Comments

@smlambert
Copy link

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
Copy link

tellison commented Apr 29, 2024

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.

@smlambert
Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants