Main concepts

This page presents some of the main concepts that revolve around CVE Scan.

CVE

The Common Vulnerability and Exposures (CVE) is a list of vulnerabilities (weaknesses found on identified software or hardware components), theoretically providing grounds for actual attacks. Each vulnerability is labelled by a CVE identifier.

One usually uses the name ‘CVE’ both for the database and the CVE identifier itself (under the form ‘CVE‐YYY‐xxxx’, where ‘YYYY’ is the year of publication and ‘xxxx’ is a unique sequential number).

Example: CVE‐2020‐0022 (a.k.a. BlueFrag).

Formally, a CVE is "a weakness in the computational logic (e.g., code) found in software and hardware components that, when exploited, results in a negative impact to confidentiality, integrity, or availability. Mitigation of the vulnerabilities in this context typically involves coding changes, but could also include specification changes or even specification deprecations (e.g., removal of affected protocols or functionality in their entirety)." (according to this page)

The CVEs have a very concise format: no technical description, no information about existing exploits, risks, severity of mitigation are supplied. They are really used to provide unique names to public vulnerabilities, to prevent duplication and so that they can be referenced in further work.

The CVE Numbering Authorities (CNA) attribute the CVEs. There are several CNA around:

  • the MITRE corporation is the primary CNA. It’s an american non‐profit organization in charge of global coordination;
  • the Computer Emergency Response Teams around the world;
  • various developers, vendors and independant partners;

All CNA are referenced here.

Neither the MITRE corporation, the CERT/CC, nor the NIST are in charge of creating the CVEs (in the sense of doing research work on software components to spot new vulnerabilities). They are exclusively responsible of their indexation and the aggregation of the relevant information. The typical workflow for a new CVE is rather as follows:

  1. a security researcher (independent, pentester on a bug bounty, university lab, developers security team, …) discovers a new vulnerability;
  2. they warn the developer / vendor of the existence of the vulnerability on its product using a re‐ sponsible disclosure model, i.e. they keep information about the vulnerability private for a prede‐ fined period of time (usually 90 days) so that the developer has time to do its own analysis and prepare a security patch;
  3. the developer (or the security researcher upon expiration of the above delay) requests creation of a CVE‐id from the relevant CNA following a precise process:
    • the CNA reserves a CVE‐id immediately
    • the discoverer submits the details of the vulnerability
    • the CNA analyses the vulnerability to ensure it’s real
    • the CNA either publishes the vulnerability (giving rise to a new CVE) or drops it.

Attack vector

The attack vector assesses the level of access required by an attacker for exploitation, from remote Network access to Physical access. The Attack Vector can be either:

  • Network: vulnerabilities with this rating are remotely exploitable, from one or more hops away, up to and including remote exploitation over the Internet.
  • Adjacent: vulnerabilities with this rating requires network adjacency for exploitation. The attack must be launched from the same physical or logical network.
  • Local: vulnerabilities with this rating are not exploitable over a network. The attacker must access the system locally or remotely (via a protocol like SSH or RDP) or use social engineering or other techniques to trick an unsuspecting user into helping initiate the exploit.
  • Physical: In this type of attacks, the adversary must physically interact with the target system.

Data Sources

The NIST National Vulnerability Database (NVD) is an up-to-date reference of all CVEs that have been published by the CNAs. It's the main source of vulnerabilities used by CVE Scan.

Beyond the NVD CVE Scan make use of the Ubuntu CVE Tracker (UCT) which keep tracks of Linux-related vulnerabilities, with more refined information (especially regarding available patches for the CVEs.)

For more details please refer to Data sources in the reference documentation.

CVSS

The Common Vulnerability Scoring System (CVSS) is standardized way of evaluating the capabilities required to exploit software vulnerabilities, together with the impacts of a successful exploitation.

It takes into account various elements (attack vector, accessibility, easyness, severity) in the context of their evolution over time and across user environments.

The final score is a decimal number between $0$ and $10$.

CVSS shall be used as an overall indicator of the criticity of a CVE, in order to deal with the most important first and foremost. Each CVE must have a CVSS score.

CVE Scan uses two flavours of CVSS : CVSSv2 (now obsolete) and CVSSv3. CVSSv2 can be used for older CVEs that do not have a CVSSv3 score.

CPE

Common Platform Enumeration (CPE) is a structured naming scheme for information technology systems, software, and packages standardized by the NIST.

Based upon the generic syntax for Uniform Resource Identifiers (URI), CPE includes a formal name format, a method for checking names against a system, and a description format for binding text and tests to a name.

Here is an example of CPE: 

 cpe:2.3:o:linux:linux_kernel:6.4:rc6:*:*:*:*:*:*

Where the components can be read as follows: - cpe:2.3 : version of the CPE naming scheme (here 2.3); - o: kind of product (o for operating system, other values include a for application anf h for hardware products); - linux is the product vendor/developer; - linux_kernel is the product name; - 6.4 is the vendor-specific version information; - rc6 is the update information.

Each CVE has a number of applicable CPEs.

More details can be found on the MITRE website.

Inventory / SBOM

Monitoring vulnerabilities on a product starts by knowing precisely what it is made of. The inventory (or Software Bill of Material, abbreviated SBOM) is a list of all software components included in your product. From this SBOM, CVE Scan can query public databases of vulnerabilities (see below for details), using each software package as the atomic unit for these queries.

This means that the inventory should use the same common vocabulary for identifying the software components. Since we are mainly using the NIST database the inventory should provide a unique identification for each software package using CPE.

The inventory is generated outside CVE Scan, either:

  • using our dedicated Yocto meta, which properly labels each package with its CPE,
  • or using another tool with CycloneDX or SPDX export functionality (ensuring that it provides the CPEs).

It is then fed as the main input to the CVE Scan command.

Report

The main output of CVE Scan is a vulnerabilities report that lists all CVEs that are potentially applicable to the product described by its inventory. Its essentially a list of CVEs together with their description, publication and modification date, impacted software components, CVSS, and assessments regarding whether this CVE is relevant or not to your product.

One significant design choice for CVE Scan is that by default it does not hide any CVE, even though there are reasons to think that they are not relevant for the product (this behaviour can be changed using the --vulnerable-only option). Thus in the report you will get all CVEs for all the software components from the inventory, regardless of the anything that could rule them out as false positives (such as the package version number, applied patch, specific configuration, ...). The assumed relevance of each CVE will be recorded by CVE Scan in a dedicated "Vulnerable" field, so that you can filter out the irrelevant CVEs yourself.

The reports are basically JSON files, but can be exported to CSV for easy processing using a spreadsheet software, or YAML for further manual processing.

Annotations

Working on product vulnerabilities involves several steps: 1. produce the inventory; 2. query the CVEs from public sources; 3. filter out false positives; 4. assess each remaining vulnerability and propose a plan of actions: - either it's a false positive that was not automatically filtered (no action), - or it's a true vulnerability, but cannot be exploited in the operationnal context of the product (no action), - or it can be exploited, and there is a patch (apply patch), - or there is not patch (remove the vulnerable software component, or mitigate the vulnerability otherwise, or accept because the impacts are limited). 5. loop back at step 1 periodically to take into account new vulnerabilities and/or code changes.

Since the whole process is by essence iterative we need to have a way to keep track of previous assessments. This is the role of CVE Scan annotations files.

During step 3 the user can inject a manual annotations file from earlier iterations to import previous assesments in the current run. These files are simple JSON files (the file format is documented here) which allow documenting any work done on specific CVEs, and override CVE Scan automatic assessments regarding their relevance to the product. These notes will be injected in the resulting reports, and any vulnerability manually annotated as "not vulnerable" will be treated as a false positive by the tool.

Since these files are plain text files we advise to store them in you Git repositoty alongside your code, so as to keep syncrhonicity between the assesments and the state of the code, and the capacity to get the full history of all the work done on the vulnerabilities.

Scope

CVE scan provides a notion of scopes to allow the security analysis to use a single annotation file for several vulnerability reports and automatically import and apply assessments that are shared between them, while keeping the ability to restrict some assessments to some specific reports. The full documentation for these scopes can be found here.