Store and display new Package.risk_score field in the UI

[tdruez]

Following https://docs.google.com/document/d/1FxeJLATdlrsDZspwByXgh5Wc_Vp83qNp/ and https://docs.google.com/document/d/1SRAkvoIj18quuRSap1r8-R6TMHAVPRPi/

Changes:

• Move the vulnerability filter to the left
• New risk_score field added on the Package/Component models
• Available in Reporting system
• Score removed from the Package and Product "Vulnerabilities" tab
• New "Risk" column in the Product "Inventory" tab with filter in the header. (As a colored badge)
• Display the risk badge next to its related Package in the "Affected packages" column of the Product "Vulnerabilities" tab

Notes:

• Only Package.risk_score is available for now from the VCIO API.
• The new risk_score available in the VCIO API is a Package value, not at the Vulnerability level.
  In the Context of a Vulnerabilities list/table, it does not make sense as a column.
• For the purpose of the review/demo, the risk_score values are randomly generated.
• Those changes focus on the display of the new field from VCIO, the analysis (status etc..) is handled separately in Add ProductVulnerabilityAnalysis model implementation #98 #187

The Product Vulnerabilities tab in DejaCode currently is a grid with the following columns: Vulnerability, Aliases, Score, Summary, Affected packages.
This should be improved to replace the Score column (which currently shows a Severity range) with three new columns that provide the Weighted Severity, Exploitability, and Vulnerability Risk score values.

An item to discuss is that the Risk score applies to Package entries where the Weighted Severity, Exploitability apply to Vulnerability entries.
The cannot be displayed the same way (single value column) depending on the context: Package listing or Vulnerability listing.

Database changes:

Migrations for 'component_catalog':

• component_catalog/migrations/0010_component_risk_score_package_risk_score.py
  • Add field risk_score to component
  • Add field risk_score to package
    Migrations for 'vulnerabilities':
• vulnerabilities/migrations/0002_remove_vulnerability_max_score_and_more.py
  • Remove field max_score from vulnerability
  • Remove field min_score from vulnerability
  • Add field exploitability to vulnerability
  • Add field risk_score to vulnerability
  • Add field weighted_severity to vulnerability

[DennisClark]

@tdruez All of your Changes confirmed in Staging Starship. The placement and appearance of the Risk Score is very nice! I agree with your Note about what it applies to, and yes we need to discuss more "An item to discuss is that the Risk score applies to Package entries where the Weighted Severity, Exploitability apply to Vulnerability entries." since I think the VulnerableCode effort there needs clarification.

One problem: The tool tips (flyover help) on all the column headings of the Product Inventory tab are suddenly missing, although they work fine in the other tabs.

[tdruez]

One problem: The tool tips (flyover help) on all the column headings of the Product Inventory tab are suddenly missing, although they work fine in the other tabs.

The tooltips never were available on the "Inventory" tab, I've added those.

---

New changes:

• Add exploitability, weighted_severity, risk_score fields on the Vulnerability model. Random values are generated for now until those data are made available in the VCIO API. WIP @ Add support for storing exploitability and weighted severity vulnerablecode#1646
• Those new fields are now displayed on the main Vulnerability list, the Product Vulnerabilities tab, and the Package vulnerabilities tab.
• You can sort and filter by the new fields. Also, the default sort for vulnerabilities lists is by risk_score

---

Questions/Discussions:

• In the design documents, the decimal values are always presented with 1 decimal place: 9.0 - 10.0 but the implementation was made with 2 on the VCIO side. I don't know if that was decided on purpose, but I'm not sure that the second decimal place is adding any values. It makes the UI more dense and does not fit the filters choices. Let's clarify this.
• What would be proper choices (range) for the Exploitability filter? The document says:

Exploitability may be expressed as a number ranging from 0.5 to 2, where:
0.5 = no exploit known
1 = PoC/Exploit script published
2 = Automatable Exploit with PoC script published OR known exploits (KEV) in the wild OR known ransomware OR high EPSS.

I've used the following for now but I doubt it make sense:

EXPLOITABILITY_RANGES = {
    "no exploit known": (0.5, 0.9),
    "exploit script published": (0.6, 1.5),
    "high exploitability": (1.6, 2.0),
}

Let's define the proper range for this filter.

[DennisClark]

@tdruez In principle (theory) the Exploitability will only be one of these 3 values: 0.5, 1.0, 2.0
There should not be any values in between those numbers.

[DennisClark]

@tdruez everything looks good on Staging Starship except for one problem, where on a Product Inventory tab I attempted to filter by Risk; if I select any of the filter values I get a "Fetching Inventory" message with a spinning circle that goes into infinite loop.

[tdruez]

In principle (theory) the Exploitability will only be one of these 3 values: 0.5, 1.0, 2.0
There should not be any values in between those numbers.

This was not clear as the design document mentioned a range and not fixed values:

Exploitability. A number ranging from 0.5 to 2 that refers to the potential or probability of a software package vulnerability being exploited by malicious actors to compromise systems, applications, or networks, andis determined automatically by discovery of exploits.

The filter is now set to the 3 choices: 0.5, 1.0, 2.0

See #97 (comment) for some discussion on improving the display of exploitability.

[tdruez]

@DennisClark The exploitability is now displayed as a colored label in the various vulnerability views.
Also, all the code is in place and ready to be deployed once aboutcode-org/vulnerablecode#1646 will be merged and deployed on the VCIO side.

Please have another look at this implementation in DejaCode of the new fields: risk_score, exploitability, weighted_severity, and let me know if it needs any changes before going live.

[DennisClark]

@tdruez The updates look very good, but I am still having the problem I mentioned in a previous comment where on a Product Inventory tab I attempted to filter by Risk; if I select any of the filter values I get a "Fetching Inventory" message with a spinning circle that goes into infinite loop. The problem occurs on Staging in both Starship and nexB dataspaces (see product ScanCode.io 33.0.0-dev as an example).

[tdruez]

@DennisClark This is now available on all instances.

[pombredanne]

For reference, here is the markdown export of the Gdoc at https://docs.google.com/document/d/1SRAkvoIj18quuRSap1r8-R6TMHAVPRPi/edit#heading=h.ll22skp48ksm :

CRAVEX: Managing-Vulnerabilities-in-DejaCode

This design is ready for review.

CRAVEX project: See https://github.com/orgs/aboutcode-org/projects/8/views/1

Background {#background}

Objective: Use Vulnerability Risk, Weighted Severity and Exploitability values from VulnerableCode to manage vulnerabilities in DejaCode.

Related GitHub issues:

• CRAVEX: Vulnerabilities policy #97
• Introduce VEX Analysis Capability to DejaCode #15
• CRAVEX: Vulnerability exploitability: Identify and store a vulnerability exploitability #98

Update DejaCode Packages with Vulnerability Scores {#update-dejacode-packages-with-vulnerability-scores}

DejaCode has a process that updates Packages with VulnerableCode data on a routine scheduled basis (such as daily). This makes vulnerability data fields available to the DejaCode user in Package and Product Package Queries.

Rather than max_score and min_score, DejaCode should be improved to get three new score values supported by aboutcode-org/vulnerablecode#1543 and #97 :

• Weighted Severity. A number ranging from 0 to 10 calculated from the severity scores provided by various data sources and the weight values assigned to each data source depending on its reliability and authority.

• Exploitability. A number ranging from 0.5 to 2 that refers to the potential or probability of a software package vulnerability being exploited by malicious actors to compromise systems, applications, or networks, and is determined automatically by discovery of exploits.

• Vulnerability Risk. A number ranging from 0 to 10 calculated from weighted severity and exploitability values.

These scores support the DejaCode user’s ability to prioritize review and determine action when reviewing Packages and Product Packages.

DejaCode should also set the Vulnerability Status (see next section) to “Under Investigation” when a Vulnerability is initially discovered for a Package.

Vulnerability Status {#vulnerability-status}

introduce a "Vulnerability Status" table to define status codes that can be applied to Package and Product Package. (We need one anyway to support VEX.) Reference Data Values (fixture values) should be

• None Identified (the default)

and the standard VEX Status values as defined for the “state” field in the CDX VEX spec: https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_analysis

• "resolved"
• "resolved_with_pedigree"
• "exploitable"
• "in_triage" applied automatically to a Package when a new vulnerability is identified for it.
• "false_positive"

Add the Vulnerability Status field to the Package and Product Package models.

DejaCode Product Package Relationship {#dejacode-product-package-relationship}

Introduce Vulnerability Status to the Product Package Relationship. Note that it refers to the Vulnerability Status within the context of the Relationship.

When a new Product Package is created in DejaCode, set the Vulnerability Status to be the same as the one identified in the corresponding Package.

DejaCode Packages UI {#dejacode-packages-ui}

The Vulnerabilities tab of the Packages detail user view in DejaCode currently is a grid with the following columns: Affected by, Aliases, Score, Summary, Fixed Packages.

This should be improved to replace the Score column (which currently shows a Severity range) with three new columns that provide the Weighted Severity, Exploitability, and Vulnerability Risk score values. Enable sorting and filtering on those columns.

DejaCode Product UI {#dejacode-product-ui}

Product Inventory Tab {#product-inventory-tab}

The Product Inventory tab in DejaCode currently is a grid with the following columns: Item, Purpose, Concluded license, Review status, Deployed, Modified.

This should be improved to:

• Modify the layout of the Item label cell to move the “Is vulnerable” dropdown button to the left so that it is just to the right of the “Show/Hide details” dropdown button. (Note that the current position of this button strongly implies that the little usage policy icon in each Item refers to vulnerability status rather than license compliance usage policy for the Item.)
• Replace the label of “Review status” with “Compliance status”
• Just after the “Compliance status” column, introduce a new “Vulnerability status” column and enable filtering on it.

Apply the label name change, and introduce the new “Vulnerability status” field, in the “Update relationship” form.

Product Vulnerabilities Tab {#product-vulnerabilities-tab}

The Product Vulnerabilities tab in DejaCode currently is a grid with the following columns: Vulnerability, Aliases, Score, Summary, Affected packages.

This should be improved to replace the Score column (which currently shows a Severity range) with three new columns that provide the Weighted Severity, Exploitability, and Vulnerability Risk score values. Enable sorting and filtering on those columns.

The Vulnerabilities tab on Product could possibly highlight specific items based on their Risk value:

8.0 - 10.0 Critical, immediate response required (red?)

6.0 - 7.9 High, response required as soon as possible (orange?)

3.0 - 5.9 Medium, investigation required (yellow?)

0.1 - 2.9 Low, response deferred (no highlight)

Also we can use the ranges defined above for filtering by Risk.