COLLECTED BY
Collection:Common Crawl
Web crawl data from Common Crawl.
TIMESTAMPS
The Vulnerability Group is a secure, private forum in whichtrusted members of the OpenJDK Community receive reports ofvulnerabilities in OpenJDK code bases, review them, collaborate onfixing them, and coordinate the release of such fixes. The Groupalso discusses other OpenJDK security-related issues, asneeded.
The current members of the Vulnerability Group arelisted in the census.
Please see thereportinginstructions for information about how to report avulnerability.
Current and previousvulnerabilityadvisories are available for reference. You can receivenotifications of new advisories by subscribing to thevuln-announcemailing list.
Membership in the Vulnerability Group is limited, due to thenature of its work. To become a Member of this Group, an OpenJDKContributor must:
Have a validOCA onfile;
Agree to thecommunicationpolicy (below) and theNon-Disclosure and LicenseAgreement;
Have an established track record of handling security issues ina professional and trustworthy manner; and
Be a recognized technical expert, or else a developer who holdsanOCTLA or JCKlicense or works for a vendor organization that holds such alicense.
New members may be voted in after the above criteria arevalidated by the Group Lead. Voting a new member into theVulnerability Group requires aThree-Vote Consensus rather thanthe weakerLazy Consensus usedfor ordinary Groups.
The Group Lead of the Vulnerability Group will initially andalways be appointed by Oracle.
Any decisions about the Group’s membership may, as usual,be appealed to theGoverning Board.
The special membership requirements of this Group wereapproved by the Governing Board in March 2018.
Decisions within the OpenJDK Vulnerability Group are made byrough consensus.If consensus cannot be reached on a particular issue then the GroupLead will make the decision. Any decision of the Group Lead may beappealed to the OpenJDK Lead.
The Vulnerability Group will shortly establish three mailinglists, each with a specific purpose:
vuln-report@openjdk.java.net— For reports of vulnerabilities in any OpenJDK code base.Anyone may post to this list. Messages sent to this list must beencrypted, and are automatically forwarded tovuln-dev@openjdk.java.net.
vuln-dev@openjdk.java.net — For review andanalysis of incoming vulnerability reports, collaborativedevelopment of fixes, and coordination of public announcements.Open only to members of the Vulnerability Group. Messages sent tothis list must be encrypted.
vuln-announce@openjdk.java.net— For announcements of the release of vulnerability fixes andrelated news. Anyone may subscribe, but only members of theVulnerability Group may post. Publicly archived; signed, but notencrypted.
The Vulnerability Group will make use of theJDK bug system (JBS) to storevulnerability reports and track the development of fixes. Onlymembers of the Vulnerability Group will have access to suchreports. Additional fields will be defined as needed for,e.g., CVE numbers and CVSS scores.
Members of the Vulnerability Group are expected to treatinformation about vulnerabilities as highly confidential untilpublicly disclosed.
A Group Member who works for a vendor organization that shipsproducts based upon an OpenJDK code base may share vulnerabilityinformation internally within that organization on a need-to-knowbasis, and may communicate such information back to the Group.
It may occasionally be necessary for the Vulnerability Group tocontact external security organizations (e.g., CERT), orvice-versa, or to exchange information with the submitter of avulnerability report, or to exchange information with themaintainers of implementations of the Java SE Platform that are notbased upon an OpenJDK code base. In such situations the Group Leadhandles the communication unless the Lead proposes, and there isrough consensus in support of, the delegation of a specificcommunication activity to another Group Member.
Members of the Vulnerability Group speak only for themselves, oras representatives of their respective employers. No VulnerabilityGroup member, not even the Lead, is authorized to speak on behalfof the Group, of any other OpenJDK Group or Project, or of theOpenJDK Community as a whole. The only exception to this rule isthat Vulnerability Group members may post announcements to thevuln-announce list in accordance with the decisions madewithin the Group.
Violation of this policy, as judged by the Group Lead, is causefor immediate removal from the Group.
There will be a bi-directional flow of information between theOpenJDK Vulnerability Group (hereinafter “OJVG”) andOracle’s internal security teams. An Oracle engineer who is amember of the Vulnerability Group, though not necessarily the GroupLead, will facilitate this flow as follows:
If a vulnerability is reported tovuln-report@openjdk.java.net:
If it’s relevant to both an OpenJDK code base and toOracle’s JDK products then the facilitator will communicateit to Oracle’s internal security teams and thereafter act asa two-way Oracle/OJVG proxy for the issue.
If it’s relevant only to Oracle’s JDK products thenthe facilitator will communicate it to Oracle’s internalsecurity teams and will notify the OJVG that it does not affect anyOpenJDK code base.
If a vulnerability is reported via Oracle’s standardpublic channel (i.e.,secalert_us@oracle.com), then:
If it’s relevant to an OpenJDK code base then thefacilitator will communicate it to the privatevuln-devlist for review and analysis, and thereafter act as a two-wayOracle/OJVG proxy for the issue.
If it’s not relevant to any OpenJDK code base(e.g., a Java Plug-In bug) then no action is taken withrespect to the OJVG.
TheOpenJDK Web Site Terms of Use willgovern the content of incoming vulnerability reports and anysubsequent discussion. Reports from submitters who insist on otherterms will not be accepted.
Once a vulnerability is reported, the members of the OJVG worktogether as follows:
Review and validate the vulnerability — Checkthat the report is complete, test the proof-of-concept if one wasprovided, assign it a CVSS score if it does not already have one,request a CVE identifier if needed, and create a JBS issue. If thereport was sent to the OpenJDKvuln-report list then sendan acknowledgement to the report’s submitter.
Develop a fix — This can be done collaborativelyamongst OJVG members. OJVG members can also share proposed fixesdeveloped privately within their respective organizations, whichmay be further refined in OJVG discussions.
Schedule a publication date — Once a fix issettled upon, OJVG members will agree on a publication date. Thedate should allow vendor organizations who are represented in theOJVG adequate time to make updates to affected products availableto their customers and end users. The publication date isconfidential until the date itself.
Publish the vulnerability and its fix — On thepublication date the fix will be integrated into the affectedOpenJDK code bases and a high-level description of thevulnerability and its fix will be posted to the OpenJDKvuln-announce list.
