OpenJDK Vulnerability Group

The Vulnerability Group is a secure, private forum in which trusted members of the OpenJDK Community receive reports of vulnerabilities in OpenJDK code bases, review them, collaborate on fixing them, and coordinate the release of such fixes. The Group also discusses other OpenJDK security-related issues, as needed.

The current members of the Vulnerability Group are listed in the census.

Membership

Membership in the Vulnerability Group is limited, due to the nature of its work. To become a Member of this Group, an OpenJDK Contributor must:

New members may be voted in after the above criteria are validated by the Group Lead. Voting a new member into the Vulnerability Group requires a Three-Vote Consensus rather than the weaker Lazy Consensus used for ordinary Groups.

The Group Lead of the Vulnerability Group will initially and always be appointed by Oracle.

Any decisions about the Group’s membership may, as usual, be appealed to the Governing Board.

The special membership requirements of this Group were approved by the Governing Board in March 2018.

Making decisions

Decisions within the OpenJDK Vulnerability Group are made by rough consensus. If consensus cannot be reached on a particular issue then the Group Lead will make the decision. Any decision of the Group Lead may be appealed to the OpenJDK Lead.

Communication channels

The Vulnerability Group will shortly establish three mailing lists, each with a specific purpose:

NOTE: These lists are not yet active.

The Vulnerability Group will make use of the JDK bug system (JBS) to store vulnerability reports and track the development of fixes. Only members of the Vulnerability Group will have access to such reports. Additional fields will be defined as needed for, e.g., CVE numbers and CVSS scores.

Communication policy

Members of the Vulnerability Group are expected to treat information about vulnerabilities as highly confidential until publicly disclosed.

A Group Member who works for a vendor organization that ships products based upon an OpenJDK code base may share vulnerability information internally within that organization on a need-to-know basis, and may communicate such information back to the Group.

It may occasionally be necessary for the Vulnerability Group to contact external security organizations (e.g., CERT), or vice-versa, or to exchange information with the submitter of a vulnerability report, or to exchange information with the maintainers of implementations of the Java SE Platform that are not based upon an OpenJDK code base. In such situations the Group Lead handles the communication unless the Lead proposes, and there is rough consensus in support of, the delegation of a specific communication activity to another Group Member.

Members of the Vulnerability Group speak only for themselves, or as representatives of their respective employers. No Vulnerability Group member, not even the Lead, is authorized to speak on behalf of the Group, of any other OpenJDK Group or Project, or of the OpenJDK Community as a whole. The only exception to this rule is that Vulnerability Group members may post announcements to the vuln-announce list in accordance with the decisions made within the Group.

Violation of this policy, as judged by the Group Lead, is cause for immediate removal from the Group.

Information flow

There will be a bi-directional flow of information between the OpenJDK Vulnerability Group (hereinafter “OJVG”) and Oracle’s internal security teams. An Oracle engineer who is a member of the Vulnerability Group, though not necessarily the Group Lead, will facilitate this flow as follows:

The OpenJDK Web Site Terms of Use will govern the content of incoming vulnerability reports and any subsequent discussion. Reports from submitters who insist on other terms will not be accepted.

Work flow

Once a vulnerability is reported, the members of the OJVG work together as follows:

  1. Review and validate the vulnerability — Check that the report is complete, test the proof-of-concept if one was provided, assign it a CVSS score if it does not already have one, request a CVE identifier if needed, and create a JBS issue. If the report was sent to the OpenJDK vuln-report list then send an acknowledgement to the report’s submitter.

  2. Develop a fix — This can be done collaboratively amongst OJVG members. OJVG members can also share proposed fixes developed privately within their respective organizations, which may be further refined in OJVG discussions.

  3. Schedule a publication date — Once a fix is settled upon, OJVG members will agree on a publication date. The date should allow vendor organizations who are represented in the OJVG adequate time to make updates to affected products available to their customers and end users. The publication date is confidential until the date itself.

  4. Publish the vulnerability and its fix — On the publication date the fix will be integrated into the affected OpenJDK code bases and a high-level description of the vulnerability and its fix will be posted to the OpenJDK vuln-announce list.

Last update: 2018/3/30 17:49 UTC