What is a vulnerability?

What is a vulnerability?

A vulnerability describes a flaw in either code or configuration with potential or demonstrated security impact. For a flaw to be considered a vulnerability, rather than just a bug, it must have security impact, potential or demonstrated. Security impact is classified by the potential to cause software to behave in a way which would be considered unexpected by a typical user of the software or system, negatively impacting the availability or integrity of the software, or the confidentiality of information held or processed by the system. A vulnerability does not need to be demonstrated to be exploitable to be considered a vulnerability, as many vulnerabilities are exploited in very creative and unexpected ways, often in combination with other vulnerabilities to form an attack chain.

Vulnerabilities can be described in a few different ways. It is common for the detection of a vulnerability in code or in a system to be also referred to as a vulnerability. It is also common for information about a known vulnerability, and the metadata about the known vulnerability to also be referred to as a vulnerability. As an example, CVE-2022-38392 is considered a vulnerability. It describes a condition where unexpected impact to the availability of certain hardware can be caused. The impacted hard drives would be considered vulnerable, and the vulnerability could also be detected on impacted systems by a vulnerability scanner. When looking at the vulnerability report produced by the vulnerability scanner, the individual detection of CVE-2022-38392 in relation to an impacted system would also be considered a vulnerability. If this scanner was able to export a GitLab scan artifact, and the vulnerability was included, it would be represented in GitLab as a vulnerability. A vulnerability tracking issue could then be created to track mitigation and resolution of vulnerability (in this case, replacing the hard drive is the most likely mitigation). As you can see, the term “vulnerability” is often overloaded and can become confusing. To help avoid ambiguity, individual detections of a vulnerability are often referred to as “findings”, “detection” or “vulnerability findings”. The metadata about a vulnerability is often referred to as an “advisory” or “vulnerability data”.

Advisories

Advisories are information about a vulnerability published by one or more sources, typically including the vendor or maintainers of the vulnerable software, hardware or operating system. Advisories are also published and maintained by bodies such as NVD and often have identifiers such as CVE numbers, but other identifiers exist and are used by some advisory databases. GitLab also issues advisories for our own software and is able to issue CVEs as well. Advisory databases and data sources do not always agree on the particulars of a vulnerability, and often differ on the assessed impact or amount of information available about a vulnerability. In some cases, vendors may publish their own advisories which reference another advisory with more specific information - one example of this is RHSAs as issued by Red Hat covering the impact of vulnerabilities (typically with a CVE). RHSAs are only issued when Red Hat releases a fix, in some cases Red Hat will determine a specific vulnerability is not present in their packaged version of a component, and in this case, the vulnerability will not be fixed and the advisory from Red Hat will reflect this, but the advisory as recorded by NVD may not have this level of detail.

Vulnerability Findings

An individual detection of a vulnerability by a security scanning tool (such as a container scanner, or dependency scanner) is a finding. An individual vulnerability finding on a system or in a codebase can be remediated. A vulnerability finding also typically is linked to and refers to an advisory which gives guidance and impact information about the vulnerability useful when performing triage and resolving an individual vulnerability finding. At GitLab, we track vulnerability findings in GitLab as vulnerabilities, however we also use issues currently to track the workflow and lifecycle of vulnerability remediation in code and systems we are responsible for. This is different to an advisory, as the finding refers to a single instance of a detected vulnerability in a detected component, rather than general information and advice about a software flaw which may or may not impact individual systems or code projects.