Closed tellison closed 5 months ago
mrybczyn
commented
1 year ago This looks like a good idea. Take into account that the vulnerability data at different sources change over time (especially just after the vulnerability has been disclosed). For an existing version of Temurin, new vulnerabilities might appear out of sync with your VDR release schedule (especially in dependencies). Because of that, it is helpful to publish such information together with the assessment date.
smlambert
commented
1 year ago Thanks for the note @mrybczyn - see the example temurin-vdr.json file, where there is the ability to include publish date and last updated/assessed, does that satisfy your suggestion?
smlambert
commented
1 year ago loosely related: https://github.com/adoptium/adoptium/issues/209
Scanteianu
commented
1 year ago work in progress: https://github.com/Scanteianu/openjdk-cve-parser/pulls
smlambert
commented
5 months ago I believe this can be closed and any enhancements raised as issues in https://github.com/adoptium/temurin-vdr-generator
Introduction
Adoptium wishes to provide a Vulnerability Disclosure Report (VDR) for Eclipse Temurin releases.
A VDR is a type of bill of materials, and we will use the CycloneDX format in line with other parts of the Adoptium project.
The VDR is a living document that must be updated as necessary, and reside at a known fixed location. For our project, the VDR will be updated when we receive new information about vulnerabilities that affect past Temurin releases, or when there are new Temurin releases. The VDR should be version controlled, so it is likely to be made available from the adoptium/temurin repository. Note that there is only one VDR covering all Temurin releases (unlike the SBOM which is one per release).
Vulnerability Information
Adoptium receives vulnerability information from a couple of different sources. Primarily the OpenJDK Vulnerability Group (OJVG) publish advisories that describe vulnerabilities that have been fixed in OpenJDK source code.
Furthermore, Adoptium may work on vulnerabilities and hold information for them as part of our security policy. External entities may also hold information on vulnerabilities affecting Temurin, such as the US Government National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD) collection of Common Vulnerability Enumerations (CVEs). The Temurin VDR may draw upon and refer to information from any of these resources to provide a description useful to Temurin users.
Each vulnerability's impact is described by a Common Vulnerability Scoring System (CVSS). We will use CVSS version 3.1 to describe the impact of of a vulnerability on each Temurin release. Note that a CVSS is context-specific, so the score may be different for Temurin compared to other software products affected by the same vulnerability. The details of how the score was determined is represented by a CVSSv3.1 vector string.
OpenJDK source vulnerability information
Unfortunately the OJVG does not provide its information in a structured machine readable format. OpenJDK vulnerability advisories are published to the OpenJDK Vulnerability Announcements mailing list, and displayed on the project's website. Each advisory webpage and e-mail announcement is semi-structured / formulaic.
The information published includes:
Note that the OJVG webpage and e-mail do not contain exactly the same information. The e-mail does not contain an OpenJDK component or CVSSv3.1 score and doesn't show which CVE applies to each source code stream, and the webpage is not OpenPGP signed.
NIST
NIST provide a rich REST API to the NVD, and provides instructions on how to use it.
Proposed Approach
The creation of a Temurin VDR may follow these steps.
Step One: OJVG Sanitisation
This step will gather OpenJDK source vulnerability information from the OJVG advisories. This will need to be based upon the expected format of information from the OJVG, and create a well-defined intermediate machine-readable file, likely in JSON format.
This level of isolation will allow for any breakage caused by the OJVG format changing having minimal downstream impact. We should be able to update the parser and ensure that it still creates our expected intermediate file.
There is already an initial parser trial for the OVJG advisory webpages that can be used as a starting point this this step, though rather than go straight to BOM it should go to the intermediate file.
It would be interesting to subscribe to the mailing list so that the awareness of new OJVG vulnerabilities could be event drive and we can check validity of CVEs notified by a signed message, but the e-mail does not contain all the required information.
Step Two : Create a rich VDR
Using the OJVG intermediate file data, NVD information via the NIST API, and Adoptium API we can determine which vulnerabilities apply to each Temurin release and all the data we wish to share.
Combining these data sources we can create/update a VDR as a GitHub PR at (for example)
adoptium/temurin/temurin-vdr.json. This Temurin VDR captures CVE information, scores from others and affected Temurin releases. This should be created in the standard CycloneDX format, and (ideally) signed by the project.An example of a Temurin VDR has been created manually to illustrate the idea. This example includes CVSS scores from OJVG and NIST, and shows that it applies to a range of Temurin releases using the standardised package URL version range specification.
As described above, this VDR should be regenerated each time there is a new vulnerability disclosure/advisory where a new vulnerability is identified that affects a Temurin release, or when there is a new Temurin release so that the VDR is up to date with known vulnerabilities for all publications.
The VDR should have tests (e.g. workflow checks) to ensure that it conforms to the CycloneDX v1.5 BOM schema.
Step Three: Accessibility via API and Website
Finally, the Adoptium API should be updated to provide the VDR, so that its location is independent of the decision to use GitHub, and the Temurin website updated to use the VDR information to display known vulnerabilities alongside each Temurin Releases' set of release notes.
This follows the project's principles of having a strong data model, accessible via the API, and a view of that data from the Website..