NotCVE augments the existing security frameworks by tracking and identifying security issues that could potentially benefit attackers, even if these issues are not officially classified as vulnerabilities or assigned a CVE.

Yes. Among others, in cases involving security issues not covered by existing policies, vendors are encouraged to request a NotCVE number instead of overlooking the issue. This approach ensure the issue is tracked, enabling vendors, clients, and the broader security community to easily identify and monitor the security concern. Additionally, it acknowledges and credits the security researcher who reported the issue.

Of course, researchers can directly request a NotCVE using the NotCVE request form.

NotCVEs are crucial in situations where products with inadequate security measures are used in the industry.

Take, for instance, a chip that is susceptible to voltage-glitching attacks. Despite the manufacturer not claiming security against glitching attacks and the chip lacking defences features against glitching attacks, it became a significant concern for a customer. This customer, previously unaware of the security issues, warned the manufacturer that they would discontinue using the chip unless the issue was resolved. Unfortunately, the vendor, lacking alternatives with better security, lost this customer.

NotCVEs are instrumental in raising awareness among clients and customers about such security gaps, even when these are not formally classified as vulnerabilities. This increased awareness is crucial for preserving customer trust and averting business losses.

Upon submission, a member of the NotCVE team will evaluate your request. If the issue meets the criteria, a NotCVE number (for example, NotCVE-2023-0002) will be assigned. It's important to note that NotCVE does not advocate for or against the qualification of an issue for a NotCVE assignment; the decision is purely based on whether the issue meets the established qualification criteria.

Security issues that present an advantage for an attacker to compromise the confidentiality, integrity or availability of a device, system or application. Examples include:

1. A security issue considered a feature by the vendor.
2. A security issue technically correct but outside the vendor's threat model.
3. CVE rejections because of and End-of-Life and Support
4. An issue that could be considered a vulnerability by MITRE but not by the vendor.
5. A notified security issue that has not been assigned a CVE after 90 days.
6. A published security issue without an assigned CVE.

NotCVE does not include software/hardware defects that fail to offer an advantage for an attacker in compromising the confidentiality, integrity, or availability of a device, system, or application. Examples of such non-qualifying issues include:

1. A software defect with no impact on security.
2. A submission with no public information or nought data/PoC append in the submission.
3. Generic issues. You need to list one or more devices/software affected with your finding.
4. A potential vulnerable code but that the attacker cannot trigger.
5. Security issues in software that clearly have no intention to provide security. For example, Telnet, FTP, the first versions of WhatsApp, etc.

Our approach doesn't aim to duplicate MITRE's CVE Program, so we recommend reaching out to the vendor initially. Nonetheless, we recognize that in certain scenarios, contacting the vendor may not be required. This includes situations where the vendor has made clear their stance on a product, such as declaring it End-of-Life, or in instances where similar issues have previously been denied a CVE assignment.

No. If a security issue has assinged a CVE then it do not qualify for a NotCVE. If the CVE is later rejected, then it may qualify for a NotCVE from that moment.

No. If a vendor rejects to assign a CVE it should provide a justification. This proves that decision was not arbitrary and therefore not a false negative.

A CVE assignation can be refused in the first place, but this decision can be changed later. This could happen due to many reasons such as an incorrect first assessment of the issue, etc. We do not plan to reject NotCVEs based on this but use it as record of the whole story. For example, the NotCVE entry will have a more precise information about when the vulnerability was reported, published, etc.

Just as not all CVEs (Common Vulnerabilities and Exposures) are critical, the same applies to NotCVEs. It's not solely about the severity of the issue but involves processes like identification, tracking, and scoring among others.

Yes. The search engine allows to search for both, CVEs and NotCVEs.