As you probably know, the Eclipse Foundation is a CNA (CVE Numbering Authority), responsible for assigning vulnerability identification numbers, known as CVE (Common Vulnerability Enumerations), to our projects. This August 2024, a new set of rules for CNAs comes into force. The PDF detailing these new rules spans 23 pages https://www.cve.org/Resources/Roles/Cnas/CNA_Rules_v4.0.pdf
While we won’t list all the rules here, we would like to highlight the most important ones, and mention the key clarifications in the new rule set.
Those new rules are not revolutionary, but rather offer clarifications and codify existing practices. For example, the rules now include a Glossary with definitions of key terms https://www.cve.org/ResourcesSupport/Glossary
Interested in what a "Vulnerability" is? Here is the definition:
An instance of one or more weaknesses in a Product that can be exploited, causing a negative impact to confidentiality, integrity, or availability; a set of conditions or behaviors that allows the violation of an explicit or implicit security policy.
CVE? What is it?
A CVE is an identifier that ensures we’re discussing the same vulnerability. Think of it as a kind of a ticket number… This ID has a strict format and appears as “CVE-2023-12345” where “2023” is the year of discovery, and “12345” is an unique number during that year.
Which rules are important for me?
Of all these rules, what is important for developers?
- A vulnerability does not necessarily exist in a library or application. A website might have a vulnerability too, and it might be assigned a CVE.
- All CVEs in Eclipse Foundation Projects should be assigned by the Eclipse Foundation. To request a CVE, visit https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/new?issuable_template=new_vulnerability (for a vulnerability report, refer to the project’s SECUITY.md or go to https://gitlab.eclipse.org/security/vulnerability-reports/-/issues/new?issuable_template=new_vulnerability) Do not request a CVE from your employer, the researcher or GitHub.
- All requesters should approach the Eclipse Foundation with ID requests. The Foundation (like any other CNA) has 72 hours in most cases to decide whether to assign a CVE. During this period we will attempt to contact the affected Project. If we receive no response - we will need to make the decision independently. Make sure the EF Security team has up to date contact information of your Project! If we do not respond within 72h, the requester may seek assistance from a different CNA.
- It is important to have CVEs assigned by the Eclipse Foundation, because we collectively control the content of the entry. Fixing issues in an entry assigned by someone else (eg. wrong version numbers, missing details…), can be difficult.
- A fix committed to a repository is considered a public disclosure, even if there is no bugfix release yet.
- If a CNA becomes aware of a vulnerability in a dependency, it must contact the dependency/upstream’s CNA.
- You should never publicly use a CVE that has been assigned but not yet published. If you want to publish a CVE in your project, please consult the EF Security team first!
- The Eclipse Foundation CNA assigns CVEs to unsupported software versions (even if they will never receive a fix).
And some rules on what is a vulnerability and what is not…
- If you have a vulnerability in a dependency (and only the dependency, no changes needed in the Project’s code to fix), this is not a separate CVE and you should use the CVE of the dependency in your documentation.
- Insecure default configuration IS a vulnerability. However, an insecure non-default and well documented option is not.
- If multiple projects share the same code and it is vulnerable, this constitutes a single vulnerability.
- An issue in an end-of-life product or version is still considered a vulnerability (even if it will never receive a fix - there is a special tag for such CVE entries)
- An issue in a product developed deliberately for educational or research purposes only is not a vulnerability.
- If there’s a doubt if an issue is a vulnerability or not, we assign a CVE. It can later be- rejected if it turns out to be a regular issue with no security impact.
Hope that list is helpful. If you have any questions about the vulnerability assessment process, contact the EF Security team!
Join our discussion about the process during the Eclipse Foundation Development Process and IP Policy Office Hours on September 12, 2024. The link and join information is here: https://www.eclipse.org/projects/calendar/
