Actually, being listed as a CVE is not the criteria for being a vulnerability. Only vulnerabilities catalogued as CVEs are 'known vulnerabilities'. There are actual instances of uncatalogued (unpublished) vulnerabilities; some are in proprietary or intelligence organization's libraries, and some are held by malicious actors for future exploitation (at which point they will be known as zero-day vulnerabilities).
It is the existence of an exploit designed to take advantage of a weakness (or multiple weaknesses) and achieve a negative technical impact that makes a weakness a vulnerability. It is not the state of being publicly known or catalogued that makes it a vulnerability. ...Joe On Thu, Jul 14, 2022 at 11:50 AM Rob Wissmann <rob.wissm...@nteligen.com> wrote: > Regarding the circular definitions, it has always struck me that > weaknesses are flaws that *may or may not* be exploitable to cause > negative impact whereas vulnerabilities are flaws *known* to be > exploitable to cause negative impact. > > > > A rewrite of the definitions to match this concept: > > > > *Vulnerability* > > *A flaw in a software, firmware, hardware, or service component known to > be exploitable to cause a negative impact to the confidentiality, > integrity, or availability of an impacted component or components (from > CVE®)* > > *Weakness* > > *A flaw in a software, firmware, hardware, or service component that may > or may not be exploitable to cause a negative impact to the > confidentiality, integrity, or availability of an impacted component or > components.* > > > > Vulnerabilities must be known to be exploitable because of the CVE > criteria <https://www.cve.org/About/Process#CVERecordLifecycle>: “Details > include but are not limited to affected product(s); affected or fixed > product versions; vulnerability type, root cause, or impact; and at least > one public reference.” > > > > An example of a flaw that may or may not be a vulnerability is an integer > overflow. It might result in a vulnerability, or it might not. That’s a > weakness. > > > > Thanks > > > > *From:* Alec J Summers <asumm...@mitre.org> > *Sent:* Wednesday, July 13, 2022 1:09 PM > *To:* CWE Research Discussion <firstname.lastname@example.org> > *Subject:* CWE/CAPEC Definitions > > > > Dear CWE Research Community, > > > > I hope this email finds you well. > > > > Over the past few months, the CWE/CAPEC User Experience Working Group has > been working to modernize our programs through a variety of activities. One > such activity is harmonizing the definitions on our sites for some of our > key terminology including weakness, vulnerability, and attack pattern. As > CWE and CAPEC were developed separately and on a different timeline, some > of the terms are not defined similarly, and we want to address that. > > > > We are seeking feedback on our working definitions: > > > > *Vulnerability* > > *A flaw in a software, firmware, hardware, or service component resulting > from a weakness that can be exploited, causing a negative impact to the > confidentiality, integrity, or availability of an impacted component or > components (from CVE®)* > > *Weakness* > > *A type of flaw or defect inserted during a product lifecycle that, under > the right conditions, could contribute to the introduction of > vulnerabilities in a range of products made by different vendors* > > *Attack Pattern* > > *The common approach and attributes related to the exploitation of a > weakness, usually in cyber-enabled capabilities* > > > > *Note*: CVE’s definition for ‘vulnerability’ was agreed upon after > significant community deliberation, and we are not looking to change it at > this time. > > > > We are hoping to publish new, improved definitions on our websites at the > end of the month. Please provide thoughts and comments by Tuesday, July 26. > > > > Cheers, > > Alec > > > > -- > > *Alec J. Summers* > > Center for Securing the Homeland (CSH) > > Cyber Security Engineer, Principal > > Group Lead, Cybersecurity Operations and Integration > > *––––––––––––––––––––––––––––––––––––* > > *MITRE - Solving Problems for a Safer World™* > > > > > -- Regards, Joe Joe Jarzombek C 703 627-4644