Vulnerability Management

This section provides a comprehensive overview of the vulnerability management process within CVEScan Web. It explains how scans are used to identify vulnerabilities, the role of annotations in manual assessments, and the mechanisms for determining a vulnerability's state.

Scans

Scans serve as the foundation for updating a component's vulnerabilities information. They consist of the reports generated by the CVEScan CLI, enriched with additional metadata such as:

  • Name.
  • Internal version.
  • Upload date.

The CVEScan Web UI allows users to upload scan reports directly into a component, where they are automatically processed to extract relevant vulnerability information. This process identifies vulnerabilities, associates them with appropriate annotations, and stores the data in a database for historical tracking and future analysis. As new scans are uploaded, the component's state evolves, enabling users to monitor changes in vulnerabilities and their assessments over time. This historical data is essential for evaluating the component's security posture and making informed decisions about remediation and risk management.

The Web UI provides an intuitive interface for uploading, viewing, and analyzing scan reports, ensuring users have access to the latest vulnerability information. Additionally, it offers a "time travel" feature, allowing users to review vulnerabilities detected in a specific scan and assessments made at that time. This capability is particularly valuable for auditing purposes, as it provides a clear historical context of vulnerabilities and their resolutions. By maintaining a detailed record of scan reports and assessments, CVEScan Web empowers users to effectively manage their components' security and compliance, ultimately strengthening their overall risk management strategies.

Annotations

Annotations are the foundation of the manual assessment process. They are used to document and manage vulnerabilities identified in a component. They allow users to override automatic assessments made by the CLI and provide additional context.

An annotation is linked to a specific combination of vulnerability ID and product. This association is immutable and identifies the vulnerabilities that the annotation addresses. While this combination is typically unique within a single scan, exceptions may arise. In such cases, the annotation will be associated with all matching vulnerabilities.

Structure

An annotation consists of three main parts: scope, version specificity, and manual review.

Scope

The scope defines the level at which an annotation is shared within the CVEScan Web hierarchy, determining how broadly or narrowly the annotation is shared across the system. This means that the annotation will automatically appear on all scans that have the same vulnerability and are in the perimeter defined by the scope value.

The available scopes are as follows from the broadest to the most specific:

  • Vault: The annotation is accessible from all components within that same vault, regardless of their associated projects or transversal values.

    Example: An annotation associated with the vulnerability ID "CVE-2021-1234" and the product "MyProduct", having a Vault scope, will be considered by all vulnerabilities with the ID "CVE-2021-1234" and product "MyProduct" within that vault regardless of their components and projects.

    In the Web UI, the vault scope is represented by the All option in the scope dropdown.

  • Transversal: The annotation is accessible from all components within the same vault that share that same transversal value.

    Example: An annotation associated with the vulnerability ID "CVE-2021-1234", the product "MyProduct", having a Transversal scope, and the transversal value "MyTransversal", will be considered by all vulnerabilities with the ID "CVE-2021-1234" and product "MyProduct" within that vault where the component has the transversal value "MyTransversal".

    In the Web UI, the transversal scope is represented by the transversal_value option in the scope dropdown.

  • Project: The annotation is only accessible from components within that specific project.

    Example: An annotation associated with the vulnerability ID "CVE-2021-1234" and the product "MyProduct", having a Project scope, will be considered by all vulnerabilities with the ID "CVE-2021-1234" and product "MyProduct" within that project.

    In the Web UI, the project scope is represented by the /project_name option in the scope dropdown.

  • Component: The annotation is exclusively available to that specific component.

    Example: An annotation associated with the vulnerability ID "CVE-2021-1234" and the product "MyProduct", having a Component scope, will be considered by all vulnerabilities with the ID "CVE-2021-1234" and product "MyProduct" within that specific component.

    In the Web UI, the component scope is represented by the /project_name/component_name option in the scope dropdown.

Version Specificity

This field ties the annotation to a specific version range of the package with the vulnerability. CVEScan supports the semver format with start including and end including bounds, both being optional. If no version range is specified, the annotation applies to all versions of the package.

For a given scope, we can have at most two annotations for the same vulnerability ID and product:

  • One without version specificity.
  • One with version specificity. If present, it is more specific than the one without version specificity.

Please refer to the applicability section for more details on how the system determines which annotation is applicable.

Manual Review

The manual review is the core of the annotation, providing the user's assessment of the vulnerability. It consists of three fields:

  • Status (Enum): Indicates the vulnerability's state in regards to the user's assessment. The available statuses are:
    • Patched: The vulnerability has been resolved, but the automatic assessment fails to register this (e.g., a manual patch has been applied but the version number is not registered by the NVD as not vulnerable).
    • False positive: The vulnerability is wrongly attributed to this product (e.g., the NVD is incorrect).
    • Not exploitable: The vulnerability is legitimate, but it cannot be exploited on this software (e.g., it cannot be triggered because an existing control prevents this, or it is theoretical and no exploit exists).
    • Accepted: The vulnerability is present but has limited impact.
    • Ongoing: Mitigation is in progress.
    • Pending: Mitigation has not started.
    • Todo: The vulnerability must be assessed, but the analysis has not started yet.
    • Exploitable: The vulnerability is present and exploitable.
    • Legacy: deprecated state for historical annotations. You won't be able to create new annotations with this status.
  • Vulnerable (Boolean): Indicates whether the vulnerability is effectively present and can be exploited.
  • Comment (String): A log documenting the work done that led to the assessment.

Operations

  • Creating: A new annotation can be created for vulnerabilities without existing annotations by specifying the scope, version specificity (optional), and manual review.

  • Updating: Existing annotations can be updated in three independent operations:

    • Update the scope. Changing the scope can lead to unexpected changes in other components, so please use this feature with caution.
    • Update the version specificity.
    • Update the manual review.

  • Forking: Forking creates a new, more specific annotation based on an existing one. The original annotation remains unchanged but becomes non-applicable, and the resulting annotation inherits all the history of the original one. This operation is useful when a more specific assessment is needed for a particular component or version range.

  • Deleting: Annotations can be deleted (for traceability purposes, the deletion is a soft delete and the annotation is not removed from the database). Deleted annotations will be shown in the UI when using the time travel feature to view the vulnerability at a specific point in time before the deletion. However, it is impossible to restore a deleted annotation, so please use this feature with caution.

Info

Each performed operation creates a log entry in the annotation's history, providing a clear audit trail of changes.

Annotation State

At any given time, an annotation has a determined state, which is the combination of the latest values of its scope, version specificity, and manual review.

Applicability

For a given vulnerability ID and product, multiple annotations may exist, but only one is applicable at a given time.

The system determines the applicable annotation by prioritizing scopes in order of specificity:

graph TD
    Vault["**Vault** _(least specific)_"] --> Transversal["**Transversal**"]
    Transversal --> Project["**Project**"]
    Project --> Component["**Component** _(most specific)_"]

This hierarchy ensures that annotations with narrower scopes take precedence over broader ones.

Additionally, as mentioned before, for a given scope, there can be at most two annotations for the same vulnerability ID and product: one with version specificity and one without. If both are present, the annotation with version specificity is considered as more specific and takes precedence.

Assessments

Assessments are the evaluations of vulnerabilities. In CVEScan, there are two types of assessments: automatic and manual.

Automatic Assessment

Automatic assessments are generated by the CVEScan CLI to provide an initial evaluation of vulnerabilities. These assessments determine whether a vulnerability is flagged as exploitable or not, using predefined rules:

For more details, refer to the automatic assessment section in the CVEScan CLI documentation.

Manual Assessment

The term manual assessment for a given vulnerability refers to the state of the applicable annotation.

Vulnerability State

The vulnerability vulnerable state indicates whether a vulnerability is present and exploitable in a component. For a given vulnerability, the state is determined as follows:

  • If no manual assessment exists, the status is taken from the automatic assessment.

  • If a manual assessment exists, the vulnerable field from the state of the applicable annotation takes precedence over the automatic assessment. In cases where the value differs from the CLI's interpretation, a hand icon is displayed in the Web UI to indicate than the user has made an override.

    Exception

    If the vulnerability's last modified date is newer than the last operation performed on the applicable annotation, the manual assessment is completely ignored, and the status defaults to the CLI's assessment. In such cases, the Web UI will display an Outdated status on the manual review to indicate that a new investigation is needed.