What are CVE IDs?
Common Vulnerabilities and Exposures (CVE) IDs are unique, alphanumeric identifiers assigned by the CVE Program operated by the MITRE Corporation (https://cve.mitre.org/). Each identifier references a specific vulnerability and, collectively, the CVE List aims to present a complete catalog of all CVE Records identified by, or reported to, the CVE Program, an international, community-driven effort to catalog Vulnerabilities. A CVE ID enables automation and multiple parties to discuss, share, and correlate information about a specific vulnerability, knowing they are referring to the same thing
What kinds of vulnerabilities are assigned CVE IDs?
Under the CVE Program, CVE numbers or IDs are assigned by MITRE to track known specific vulnerabilities within computer systems and application software. They apply to widely deployed systems and software such as operating systems (e.g. Microsoft Windows), web browsers (e.g. Google Chrome) and server software (s.g. Microsoft IIS). For a vulnerability to be assigned a CVE, it should be a flaw that is present in the underlying code that the application is written in, meaning that all deployed instances of that software will have the vulnerability software version. CVEs reference specific versions that are vulnerable, as well as versions in which the vulnerabilities is fixed (patched).
CVE Numbering Authorities (CNAs) are organizations from around the world that are authorized to assign CVE IDs to vulnerabilities affecting products within their distinct, agreed-upon scope, for inclusion in first-time public announcements of new vulnerabilities. These CVE IDs are provided to researchers, vulnerability disclosers, and information technology vendors.
What is not covered by CVE IDs?
CVE numbers are not given to vulnerabilities that affect anything outside the scope of the systems and products managed by the CVE Numbering Authorities. This means that bespoke applications (such as many websites, which are specifically developed in-house for individual customers or companies), are not within scope to be assigned CVEs. Most web application security flaws are due to insecure code written by the application developer(s) and will not have a CVE assigned.
This makes sense, because there is only one deployment of that web application, so there is no need to assign a global CVE ID - the vulnerability will not exist in any other organisation, since only that one customer operates their bespoke website.
Although each flaw can be categorised as being of a particular known type or pattern that is frequently seen (e.g. "SQL Injection"), the specific vulnerability in question is a variant that only affects one particular system and would not be listed in vulnerability databases, nor would information about the flaw be shared in the public domain. This would change if the system was packaged up and widely deployed since it then becomes a common issue across multiple organisations where CVE becomes applicable.
Do vulnerabilities found by AppCheck web application scans have CVE IDs?
When AppCheck performs a web application scan, they can find both vulnerabilities in custom in-house code (which would not be assigned a CVE ID, for the reasons above) - however the scan may also detect known vulnerabilities within underlying common "COTS" (Commercial Off The Shelf) components underlying the bespoke application code - such as the Application Server, Proxy Server, Caching Server, Application Programming Framework (example; ASP.NET, NodeJS, PHP), CMS, or CMS Plugin / Extension. These would all be in-scope for CVE ID assignment and would likely have CVE IDs if already known.
Detection of new vulnerabilities ("0-Days") in common software
CVE numbers are requested from MITRE by security researchers when they discover a vulnerability within a qualifying system, therefore a CVE will only exist when a vulnerability has become known and then subsequently published (A reserved candidate number is created shortly before publication).
Vulnerabilities within software that are yet to be known publicly are often referred to as 0Day (zero day). This means that the vendor either is unaware of or has yet to address the flaw and no public information exists that could be used by a signature-based scanner.
Can AppCheck detect new 0-Days?
AppCheck implements a Dynamic Application Security Testing (DAST) when scanning web applications for vulnerabilities. This approach applies a methodology to vulnerability detection from first principles, so may potentially discover vulnerabilities in underlying software (such as the webserver) that are not previously known about.
At a high level this works by enumerating each application component though OSINT, Crawling, Forced Browsing and API enumeration to build up a logical attack surface for the application. Each identified taint source (e.g. Query String Parameter, Request Body, WebSocket, Http Header or Cookie) is then examined for security flaws. The process involves analysing the original value and then applying mutations to it identify insecure processing within the application. Each check is applied in layers, beginning with the smallest modification possible to find a suspected candidate, followed by more in-depth testing to prove and where applicable safely exploit the flaw to provide evidence.
In many cases this will identify security flaws that are unique to in-house bespoke web application code that would not be in scope for a CVE ID assignment. However, the same methodology is applied to any underlying target systems that may include widely deployed software where vulnerabilities are uncovered that were previously unknown.
What should I do if AppCheck finds a new 0-day in an underlying common component?
In this scenario AppCheck would have uncovered a 0day vulnerability that should be reported to the vendor. This can be done either directly or AppCheck can do this on your behalf. At this point a CVE ID can be requested that will help other users of the same software to identify the same flaw in their systems.