Version 0.5 June 18, 2012
A CVE is a common name for a single security vulnerability so that we can identify and talk about issues sanely (e.g. "that OpenSSL vulnerability, from like 2009, the DoS one" vs. "CVE-2009-3555"). CVE allows multiple vendors, products, and customers to properly track security vulnerabilities and make sure they are dealt with.
The CVE database is a list of information security vulnerabilities and exposures that aims to provide common names for publicly known problems. The goal of CVE is to make it easier to share data across separate vulnerability capabilities (tools, repositories, and services) with this "common enumeration."
Because it makes it much easier to track, discuss and otherwise handle security issues for everyone. Upstream vendors, downstream vendors, security tracking firms, customers, security products, etc. all increasingly rely upon CVE to identify issues clearly.
There are several ways to make a request depending on what your requirements are:
| Contact | Who sees the info | Embargo time | Information required | |
| Public | oss-security@lists.openwall.com | Public | none | Detailed info |
| Semi-private | distros@vs.openwall.org | Linux/BSD vendors | Max 2 weeks | Detailed info |
| Private (vendor) | prearranged | Limited (Red Hat) | Max 30-60 days | negotiated |
| Mitre | cve-assign@mitre.org | Mitre | negotiated | negotiated |
These are sent to oss-security@lists.openwall.com (http://oss-security.openwall.org/wiki/mailing-lists/oss-security). They are completely public (anyone can sign up to the oss-security@ list, the archives are public). This is the best because everyone that cares to track CVE #'s will find out about it ASAP, also because it is a public request it is unlikely that anyone else will accidentally or otherwise request a CVE for the same issue.
Time line: I generally respond to these within one business day, this means you'll either get a CVE or a request for more information if the request is not properly formatted or is unclear/missing details/etc.
If you have a semi-private issue (you want to notify vendors, but not the entire world, giving time for it to be fixed) the easiest way to do this is to email the distros@vs.openwall.org list (http://oss-security.openwall.org/wiki/mailing-lists/distros).
Please note that one of the list requirements is that issues be embargoed (kept private) for 2 weeks at most (e.g. 14 to 16 days depending on when during the week the email was sent). DO NOT SEND A REQUEST TO THIS LIST IF YOU NEED MORE THAN 2 WEEKS TO ADDRESS AND RELEASE THE ISSUE. The distros@ list is a private list consisting of security teams for Linux and BSD distributions. No archives of this list exist publicly at this time, although a time delayed archive may be created at some point (delayed at least 14-16 days so embargoed issues don't appear in the archives). The advantage of this list is it allows you to easily co-ordinate a public release with the projects most likely to ship your software (e.g. Linux and BSD vendors).
Time line: I generally respond to these within one business day, this means you'll either get a CVE or a request for more information if the request is not properly formatted or is unclear/missing details/etc.
In order to serve the community better I've decided to allow private vendor requests that meet certain requirements and that are arranged in advance (since I need your PGP key, etc.). Email me at kseifried@redhat.com to set this up for your project.
If you are unwilling or unable to share any information regarding the CVE request than please go directly to Mitre at cve-assign@mitre.org.
Time line: I don't speak for Mitre (unknown).
This information is required for public requests to oss-security@ and private embargoed requests to distros@, and generally recommended for all other request types. More information up front means less problems down the road.
Information for CVE request that is REQUIRED:
Information for CVE request, REQUESTED:
Examples of CVE entries can be found at http://cve.mitre.org/cve/, examples of CVE requests can be found in the OSS-sec archives.
Authoritative information is better. The upstream vendor advisories are ideal as they tend to be correct and sourcing them will generally not result in mistakes or overlap. This is especially important if the vendor has already requested or assigned a CVE to the issue they will likely place it within the security advisory they post online, checking this first will prevent multiple CVE's from being issued. Other good sources of information are the specific bugzilla entries, ChangeLog entries or code commits (ideally with identifying comments or other related meta-data). These will often give the original information and date of publication, however they tend not to be polished like a vendor advisory is. Although third party advisories and information can be used to source a CVE request this can lead to problems (lack of details, overlapping requests, etc.), so please, whenever possible include first hand sources.
http://seclists.org/oss-sec/2011/q4/3
http://seclists.org/oss-sec/2011/q4/107
Bad request:http://seclists.org/oss-sec/2011/q4/65 - this one is a bad request because the affected product name was mixed up (Ruby-on-rails/Ruby)