Obtaining consumable OpenJDK vulnerability information

[tellison]

Just thinking about how we should be requesting the fixed OpenJDK vulnerability information from upstream. We want it in machine readable format, with a consideration of publishing it from Adoptium for each release of Temurin in CycloneDX format. At present the information is provided on the OpenJDK website and via the release announcement e-mail to the mailing list.

1. First step is to consider how the current information provided by OpenJDK can be represented in CycloneDX format.
2. Secondly, is there additional information in the CycleDX format that we would request be added by OpenJDK.

So, considering the first step...

Current OpenJDK vulnerability advisories depict:

• CVE ID
• Link to NIST National Vulnerability Database
• OpenJDK component (implicated?)
• Common vulnerability scoring system numerical score
• Affected version (states "...and earlier")

Maps to CycleDX vulnerabilities format

Name	Type	Description	Example
id	String	The identifier that uniquely identifies the vulnerability.	"CVE-2021-39182"
source.url	String	The url of the vulnerability documentation as provided by the source.	"https://nvd.nist.gov/vuln/detail/CVE-2021-39182"
properties[].name	String	Key indicating the implicated OpenJDK component	"Component"
properties[].value	String	Value of implicated OpenJDK component	"client-libs/javax.sound"
affects.ref	String	References a component or service by the objects bom-ref	Required: [1]
affects.versions[].range	String	Affected version range.	[2]
affects.versions[].status	String	The vulnerability status for the version or range of versions.	"affected"
[3]	String	CVS score	"3.7"

[1] Assume we have a BOM ref for Temurin as a whole. Maybe later refine for OpenJDK code vs. dependencies.

[2] Temurin affected version details

The spec states: > A version range specified in Package URL Version Range syntax (vers) which is defined at https://github.com/package-url/purl-spec/VERSION-RANGE-SPEC.rst

However, that link is invalid. We need to describe a range of Temurin versions following the Java version naming convention

[3] Not sure how to depict the CVS score for the fixed vulnerability in CycloneDX. Can always put it in as a generic `properties[].value, but seems that it should fit into a more structured location.

[danyvisi]

This is what Black Duck is reporting

[gdams]

@tellison I've updated my scripts to use the CycloneDX format. You can see a sample file here: https://github.com/gdams/openjdk-cve-parser/blob/main/releases/2023-01-17.json

Like you say, the only field I need to work out is affects.versions[].range as there's no easy way to compute this

[tellison]

IMHO we shouldn't be pursuing the approach of parsing the OpenJDK webpage depiction of vulnerabilities, but rather approach the OpenJDK Vulnerability Group (OJVG) with a request for them to publish sufficient machine readable information to meet our requirements. The goal of this issue is to figure out what we ask OpenJDK to provide.

It seems entirely reasonable for the OJVG to provide the required information as a Vulnerability Disclosure Report (VDR) themselves, but we can take the information we require in a different format too.

The VDR is a living document, as CycloneDX state:

Inventory described in a BOM (SBOM, SaaSBOM, etc) will typically remain static until such time the inventory changes. However, vulnerability information is much more dynamic and subject to change. Therefore, it is recommended to decouple the VDR from the BOM. This allows VDR information to be updated without having to create and track additional BOMs.

That is, as a new vulnerability is exposed, the VDR would be updated to refer to all the affected OpenJDK versions.

I believe that we would like enough information from OpenJDK to be able to:

• Produce useful Temurin release notes by listing the CVEs that are fixed in a specific release. That list should include enough information for Temurin users to form an opinion about, or reach more details of, the fixed vulnerability. Providing vulnerability fix information in the release notes seems like a simpler problem to solve. We can take in the OJVG fix information and present it in a similar fashion to the release change set we currently show.
• Maintain a VDR for Temurin where we provide ongoing vulnerability information about our product. This would require more sophisticated management. We'd either derive it from the OpenJDK VDR if it exists, or have to construct it from the know list of fixes. We would refer to the Temurin SBOM from the VDR, and could use the VDR to augment a specific release's notes.

So back to the objective of this issue, we either go to OJVG and ask them to maintain a VDR, or we ask for a machime-readable set of fixed vulnerabilities per release.

WDYT?

[gdams]

FYI I found the correct link to that file: https://github.com/package-url/purl-spec/blob/version-range-spec/VERSION-RANGE-SPEC.rst

[tellison]

Thinking about this again, and after a discussion with a few people here, I propose we create a Vulnerability Disclosure Report (as described above) for Temurin. The VDR would cover all versions, therefore not be in the releases repos, and it would be updated from information provided by the OpenJDK Vulnerability Group and third-parties (e.g. NIST).

Practically, this would be:

1. Create a VDR in /adoptium/adoptium/VDR/temurin-vdr.json
2. Include the minimal required information in the VDR to comply with the CycloneDX spec, preferring to delegate to the information held in trusted third-party reports (NIST, MITRE, FIRST, etc)
3. Populate the VDR with information from the OpenJDK Vulnerability Group public disclosures.

Note that the VDR would not contain any non-public disclosures.

The Temurin VDR should be available to all via (for example) api.adoptium.net/v3/info/vdr.

The VDR would be used to augment Temurin's dynamic release notes rendering to inform users of vulnerabilities fixed in this release and vulnerabilities affecting this release.

[tellison]

A first pass of an example Temurin VDR entry. Trying to blend the CycloneDX 1.5 schema with the information returned by NVD (example) and OpenJDK disclosures (example) that is likely useful to a Temurin user and can be used in a notes rendering as described above.

Work in progress!

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "vulnerabilities": [
    {
      "id": "CVE-2023-25193",
      "source": {
        "name": "NVD",
        "link": "https://nvd.nist.gov/vuln/detail/CVE-2023-25193"
      },
      "properties": [
        {
          "name": "component",
          "value": "client-libs/2d"
        }
      ],
      "published": "2023-02-04T20:15:08.027",
      "updated": "2023-07-25T15:15:13.163",
      "description": "hb-ot-layout-gsubgpos.hh in HarfBuzz through 6.0.0 allows attackers to trigger O(n^2) growth via consecutive marks during the process of looking back for base glyphs when attaching marks.",
      "ratings": [
        {
          "source": {
            "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-25193",
            "name": "NVD"
          },
          "score": 7.5,
          "severity": "high",
          "method": "CVSSv3",
          "vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
          "exploitabilityScore": 3.9,
          "impactScore": 3.6
        }
      ],
      "affects": {
        "ref": "???????",
        "versions": [
          {
            "range": [
              "<8u333",
              "<11.0.15.1",
              "<17.0.3.1",
              "<20.0.1.1"
            ]
          }
        ]
      }
    }
  ]
}

Thoughts:

• Maybe cut out all the info taken from NVD and just pull from there as required?
• Not sure what the ref should be?