A computer security vulnerability is a weakness that can be exploited by a hacker. These weaknesses can be found in the software, hardware, or firmware of a computer system. Common Vulnerabilities and Exposures (CVE) is a dictionary of computer security vulnerabilities. It is maintained by the MITRE Corporation and is used by government agencies, businesses, and researchers to share information about security vulnerabilities. In this blog post, we will discuss the process of publishing a CVE vulnerability.
Confirm that your vulnerability is new
You have identified a new computer vulnerability in a software product. The first step is to ensure that this vulnerability is new by doing searches. If your searching in any of the following repositories indicates that your vulnerability has already been assigned a CVE identifier, then it’s not new and it doesn’t need to be published.
CVE
The first database to search is Mitre’s CVE catalog. The CVE catalog is a list of computer security vulnerabilities that have been assigned a CVE identifier.
The National Vulnerability Database (NVD)
Another place to search is the National Vulnerability Database (NVD). The NVD is a repository of computer security vulnerabilities maintained by the US government.
GitHub, ExploitDB, and PacketStorm
Among the other databases worth searching are GitHub, ExploitDB, and PacketStorm. These are repositories of computer security exploits.
It doesn’t hurt to also do a quick search on Google. Just be aware that some of the results may not be accurate. The reason for this is that Google indexes CVE identifiers and sometimes includes them in the search results even if the vulnerability has not yet been assigned a CVE identifier.
Contact the vendor of the affected product
When your searches allow you to confirm that the vulnerability you’ve identified is new, the next step is to contact the vendor of the affected product. The vendor is the company that makes the software, hardware, or firmware in which you’ve found the vulnerability.
From that point, several scenarios can unfold:
If the vendor is cooperative
You’ve contacted the product owner to alert them to the new computer security vulnerability. They are cooperative and want to work with you to resolve the issue. The vendor will assign a CVE identifier and add the entry to their security advisory.
If the vendor is uncooperative
You’ve contacted the product owner, but they do not want to work with you. They may be uncooperative for any number of reasons. In this case, you can still submit a request to the CVE dictionary to have a CVE identifier assigned.
If the vendor is non-responsive
You’ve contacted the product owner, but you don’t get a response. This is known as being “non-responsive.” In this case, you can also submit a request to the CVE dictionary to have a CVE identifier assigned.
If the vendor offers a bug bounty
If the vendor decides to offer a bug bounty, they will issue a request for information (RFI) to solicit reports of computer security vulnerabilities. The RFI will include a list of criteria that must be met for the submission to be eligible for the bug bounty.
Publish your vulnerability in the CVE catalog
The publishing process can be broken down into the following steps:
Gather information about the vulnerability
The information you’ll need to pull together includes the following:
- Attack type
- Impact
- Affected component
- Attack vector
- How the vendor acknowledged the vulnerability
- Some public references
MITRE even provides their own description templates:
- [VULNTYPE] in [COMPONENT] in [VENDOR][PRODUCT] [VERSION] allows [ATTACKER] to [IMPACT] via [VECTOR].
- [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] [ROOT CAUSE], which allows [ATTACKER] to [IMPACT] via [VECTOR].
Create a CVE request
A CVE request is simply a request to have a CVE identifier assigned. The request must include all of the information mentioned above.
Submit the CVE Request
After you send your CVE request, it will be reviewed and, if approved, your vulnerability will be assigned a CVE identifier and be published. In any case, always make sure that your newly found vulnerability follows a responsible disclosure process agreed with the vendor.
Wrapping up
Finding a new vulnerability and having it published in the CVE catalog can be a gratifying experience. For some vulnerability researchers, it could mean a great career boost. At any rate, following a strict ethical approach that includes the vendor’s agreement is essential at any stage of this publishing process. Adhering to responsible disclosure also helps ensure that the vendor releases a patch before the vulnerability gets published, thus keeping the attackers at bay.
In the same spirit, improving your application security by identifying and fixing your vulnerabilities before an attacker can exploit them only makes sense.
If you need help testing your systems to fix their vulnerabilities, contact us.
