Triage vulnerabilities

The Spectra Assure platform detects a wide range of known vulnerabilities that may be present in your software packages.

In some cases, your software project may contain vulnerable code in its components and dependencies that is unused altogether, or only used in an isolated environment where exploits cannot be triggered remotely. ReversingLabs always recommends patching such vulnerabilities, but also provides support for vulnerability triaging as an effective temporary measure.

To triage vulnerabilities in rl-secure, you have to create a processing filter in your policy configuration file.

When you triage vulnerabilities in policy configuration, you are essentially telling rl-secure that you are aware of the vulnerability, but you want to suppress it in the analysis reports.

Every vulnerability in the policy configuration must be specified either by its CVE ID or by its exact, case-sensitive public vulnerability name (e.g. Log4Shell, Spectre). When using CVE IDs, you can provide them as a full ID (CVE-2021-44228) or use partial matching (CVE-2017-57*) and glob filters to define a range of CVE IDs (CVE-2018-4[6-9][3-8][1-9]). Use the rl-secure CLI output or analysis reports to identify vulnerabilities you want to triage.

Based on your policy configuration, rl-secure generates VEX (Vulnerability Exploitability eXchange) information and includes it in the CycloneDX reports. Because of this, it is mandatory to specify one of the following VEX-compliant reasons for every triaged vulnerability:

• vulnerable-code-absent
• vulnerable-code-unused
• mitigation-exists

In the following examples, our project relies on some third-party components that contain known vulnerabilities. The default rl-secure configuration produces the CI:FAIL status because the severity of those vulnerabilities impacts the final CI/CD status.

However, we have verified that some of those vulnerabilities do not affect our project because the third-party code is not used. To prevent CI/CD failing conditions, we're triaging those vulnerabilities in the policy configuration file for our project. When applied, our changes will affect all packages and package versions in the project.

As a result of this change, the vulnerabilities we specified in the filter will be displayed as 'Triaged' in the analysis reports. Their presence in the software package will not cause a CI/CD failing condition.

Examples in this guide show how to modify the policy configuration for existing projects and packages in a previously created package store. If you haven't yet created any projects and packages, follow the instructions in the quick start guide.

1. Modify project policy settings

1) In the rl-secure package store, navigate to the policy configuration file for the project and open it in a text editor. In this example, the full path to the file we're editing is /home/armando/my-repository/.rl-secure/projects/my-project/.project_policy.info.

2) In the .project_policy.info file, add a new processing filter.

• To ensure that the filter is applied when analyzing files, set enabled to true.
• With matches set to "path" and pattern set to a specific directory, the filter will target all files inside the directory. We're using this because the vulnerability has been detected in third-party components stored in that specific directory.
• In the triaged section, we're specifying which CVE found in the pattern path should be triaged and why.

Example processing filter

policies
{
    profile "project_profile"
    {
        inherit_rules "repository_profile"
        
        processing
        {
            filter
            {
                enabled   true
                
                matches   "path"
                pattern   "third-party/*"
                
                author    "Spectra Assure"
                timestamp "2023-01-01T12:00:00+00:00"
                reason    "Explicitly triaging third-party vulnerabilities"
                              
                triaged
                {
                    CVE-2022-3970 vulnerable-code-unused
                }
            }
        }
    }
}

3) Save changes to the file and close it.

2. Apply and verify configuration changes

1) To apply your policy configuration changes, run the following command in your package store:

rl-secure sync

The command automatically detects which packages in the package store require synchronization. Using the sync command does not count towards the monthly analysis capacity.

2) To make sure the new policy configuration is reflected in analysis reports, you have to regenerate them for all applicable package versions:

rl-secure report all --purl=pkg:rl/my-project/my-package@1.0 --bundle=report.zip

3) To confirm that the policy configuration change has been successfully applied, check the rl-secure output or the SAFE report (rl-html) for details about triaged vulnerabilities.

Check the CLI output

Use the find command to look up CVEs by name and confirm they are still detected, but reported as triaged in the project for which the configuration was modified.

rl-secure find CVE-2022-3970 --purl=pkg:rl/my-project

The output should be similar to the following example. It indicates that the CVE was detected and suppressed because of the configuration change.

Example output

[ MATCHED ] my-project/slack@4.28
[ CVSS:v3 ] [H] 8.80 / CVE-2022-3970
            Exploitable:   YES
            Introduced in: 3.5.7 (over 23 years ago)
            Resolved in:   4.5.0 (8 months ago)
            Patch mandate: NO
            Discovered by: Google LLC
            Sourced from:  NVD
            Description:   A critical vulnerability has been discovered in
                LibTIFF, specifically in the function TIFFReadRGBATileExt
                located in the file libtiff/tif_getimage.c. This vulnerability
                stems from an integer overflow manipulation, which can be
                exploited remotely. The details of the exploit have been
                disclosed to the public, increasing the risk of potential
                attacks.
Suppressed ---------------------------------------------------------------------
    Author: Spectra Assure
    Date: 2023-01-01T12:00:00+00:00 (7 months ago)
    Reason: Explicitly triaging third-party vulnerabilities
     1) ./third-party/lib/example-file <- via libtiff/4.2.0 (static)

Check the SAFE report

• In the SAFE report, select Vulnerabilities from the left sidebar. On the page that opens, make sure the Hide Triaged toggle is not active.
• Use the Filter vulnerabilities by CVE dropdown to find the triaged vulnerability.
• If the configuration change has been successfully applied, the vulnerability will have a "Vulnerability Triaged" tag assigned to it.
• You can expand CVSS Details for the vulnerability and look for its Triage details. The information in the Triage column should match the reason provided in the policy configuration file ("Vulnerable Code Unused").

3. Check VEX information

In Step 2, we created all supported report types for a package in our project. This includes the CycloneDX report, which should show VEX information about the triaged vulnerability. To confirm that this information is present in the CycloneDX report, locate and open the report.cyclonedx.json file.

In our example, the full path to the CycloneDX report file is /home/armando/my-repository/.rl-secure/projects/my-project/packages/my-package/versions/1.0/reports/report.cyclonedx.json.

In the CycloneDX report, look for the triaged vulnerability under vulnerabilities. The VEX information included in the report should be similar to the following example.

Example CycloneDX excerpt

    "analysis": {
        "detail": "Explicitly triaging third-party vulnerabilities",
        "justification": "code_not_reachable",
        "state": "not_affected"
    }