CRAVEX: Vulnerabilities policy

[pombredanne]

Create UI and DB models to create and store vulnerability policy: org-wide, and product-specific policy based on purpose, destination, type of usage and other factors.

[DennisClark]

See https://www.fedramp.gov/documents-templates/ for related approach.

[DennisClark]

Generally the application UI to maintain and view Vulnerability Policy should resemble Usage Policy wherever appropriate.

Add/Change form help text

You can define the Vulnerability Policy choices that may apply to various application object types such as Packages and Components.

For each application object type, you can specify the Vulnerability Policy label text, icon, icon color, guidelines, and security alert for each relevant policy position that you need to communicate to your users. Examples might include: No Action Required, Consider Software Upgrade, Urgent Action Required.

[DennisClark]

Label: Label is the text that you want to present to application users to describe a specific Vulnerability Policy as it applies to an application object.

Object type: Object type identifies the application object (Component, Package) to which the Vulnerability Policy will apply.

Guidelines: Guidelines explain the organization definition of a vulnerability policy and can also provide detailed procedural requirements.

Icon: You can choose an icon to associate with the vulnerability policy from the available icons at https://fontawesome.com/icons?d=gallery&m=free

Color code: You can specify a valid HTML color code (e.g. #FFFFFF) to apply to your icon.

Security alert: Indicates the criticality of a vulnerability based on organizational policy. Value choices include "Pass" (or empty, the default value), "Warning" (should be reviewed and fixed), and "Urgent" (highest priority).

[DennisClark]

@pombredanne I think that a vulnerability policy only applies to packages and components. In a product context, purpose, destination, type of usage and other factors belong to the setting of a (new) Vulnerability Status on the Product Inventory Item relationship.

[DennisClark]

The actual setting of a policy on a package or component should be automated as much as possible, although manual assignment and editing should also be supported. The best determining factor here would be the Severity Score associated with the vulnerability (currently something of a moving target). Perhaps another user-modifiable field to define on this Vulnerability Policy object would be a Severity Score Range, so that a Vulnerability within that range would trigger the assignment of that Policy to a package or component.

[DennisClark]

Regarding potential triggering numbers, we need to consider the elements currently described at

https://nvd.nist.gov/vuln-metrics/cvss/v4-calculator

that is, VulnerableCode needs to provide at least two numbers (scores) for (1) Impact/Severity and (2) Exploitability.

[DennisClark]

another useful resource for background material:

https://vulcan.io/blog/cvss-v4-0-what-you-need-to-know/

[DennisClark]

Calculating Risk in VulnerableCode. See discussion document https://docs.google.com/document/d/1FxeJLATdlrsDZspwByXgh5Wc_Vp83qNp/edit?usp=sharing&ouid=117241222429542576816&rtpof=true&sd=true

Here are two more fields that should be supported in the definition of a Vulnerability policy:

From risk: The low risk numeric value in the definition of the range of risk values that trigger the setting of this policy on a Product Inventory Item or Package.
To risk: The high risk numeric value in the definition of the range of risk values that trigger the setting of this policy on a Product Inventory Item or Package.

[pombredanne]

FYI, Fedramp in the US demands that Fedramp compliant vendors have a specific policy.
See page 2 of https://www.fedramp.gov/assets/resources/documents/rev4/REV_4_CSP_Vulnerability_Scanning_Requirements.pdf
For instance:

• National Vulnerability Database (NVD): For any vulnerability listed in the latest version of the National Institute of Standards and Technology (NIST) NVD, the Common Vulnerabilities and
  Exposures (CVE) reference number must be included with the machine-readable findings data for that vulnerability.
• Common Vulnerability Scoring System (CVSS) Risk Scoring: For any vulnerability with a CVSSv3
  base score assigned in the latest version of the NVD, the CVSSv3 base score must be used as the original risk rating. If no CVSSv3 score is available, a CVSSv2 base score is acceptable where available. If no CVSS score is available, the native scanner base risk score can be used.

The full doc further explain that CVEs with a CVSS above a "high" value must be fixed.

[DennisClark]

@tdruez @pombredanne In the near term, I suppose we can base automatic vulnerability policy assignment on severity range score rather than waiting for a calculated vulnerability risk that also folds in weighting and exploitability factors. It seems like a compromise to me, but it would get things moving in DejaCode.

See aboutcode-org/vulnerablecode#1565 (comment)

[DennisClark]

Please ignore my "in the near term" remarks in the previous comment. This issue depends on the completion of VulnerableCode issue aboutcode-org/vulnerablecode#1543 and that issue points to a design document with more details. The VulnerableCode API v2 will need to support the new fields and that might require another issue to complete. The new fields identified in that design:

"When a user gets software package metadata from VulnerableCode, any “Affected By” Vulnerability metadata for the specific PURL should include these 3 values: Weighted Severity, Exploitability, Vulnerability Risk."

In particular, Vulnerability Risk is the critical value for automated assignment of a Vulnerability Policy to a Package and a Product Package, and all 3 values should be displayed on a Package.

The next Comments will attempt to summarize how the Vulnerability Policies should be defined in DejaCode, how it will get assigned, where it will show up in the DejaCode UI, and what the possible workflows will be for a user to take advantage of the Policy.

[DennisClark]

We need to step back and reconsider this Vulnerability Policy. Are we making this too complicated? Is it possible that DejaCode workflows can be more simply supported by the Vulnerability Risk value, where the Risk value (a number from 0 to 10) determines the urgency of addressing a vulnerability? (It also occurred to me that the actual Risk value might be a dynamic thing that could change during the lifecycle of a Vulnerability.)

A simpler, and possibly better, approach would be to introduce a basic "Vulnerability Status" table that could be applied to Package and Product Package. (We need one anyway to support VEX.) Values could be
● None Identified (the default)
and the standard VEX Status values
● Not affected – No remediation is required regarding this vulnerability.
● Affected – Actions are recommended to remediate or address this vulnerability.
● Fixed – Represents that there is a fix for the vulnerability.
● Under Investigation – applied automatically to a Package when a new vulnerability is identified.

(DejaCode should support the standard VEX Status list. To avoid adding too much complexity to the data model, this new VEX Status could simply be coded into DejaCode, rather than creating a new VEX Status code table.)

The Vulnerabilities tab on Product could possibly highlight specific items based on their Risk value:
8.0 - 10.0 Critical, immediate response required
6.0 - 7.9 High, response required as soon as possible
3.0 - 5.9 Medium, investigation required
0.1 - 2.9 Low, response deferred

See related issues:
#15
#98

[mjherzog]

I am still concerned that we keep focus on the idea that: "VulnerableCode needs to provide at least two numbers (scores) for (1) Impact/Severity and (2) Exploitability." We want to keep things as simple as possible, but one number seems to be too simple.

[DennisClark]

Concerns noted. We will have 3 values: Weighted Severity, Exploitability, Vulnerability Risk.

[DennisClark]

@tdruez @pombredanne @mjherzog The results of our analysis and discussions are now in the document at

https://docs.google.com/document/d/1SRAkvoIj18quuRSap1r8-R6TMHAVPRPi/edit

Please review that document when you have the opportunity and let us use it to record final design decisions (which have been modified significantly since this issue was first created). All comments, suggestions and questions are welcome.

[tdruez]

@DennisClark

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.

I'm wondering about the current exploitability design. Using a decimal value for the risk_score and severity make sense, but I'm not sure about using 3 decimal hardcoded choices for the exploitability.
I understand that those values are used internally to compute the risk, but couldn't we use label to present those 3 values (0.5, 1.0, or 2.0) instead in the UI? At least on the DejaCode side.

Too many decimal numbers may be confusing:

Looking at those values, it is not obvious that exploitability is only 3 options, where the severity and risk are real dynamic values computed between 0 and 10.

[DennisClark]

How about these 3 labels:
Unknown
Potential
Known

[DennisClark]

or maybe better
No exploits known
Potential exploits
Known exploits

[DennisClark]

perhaps color-coded as well
green
yellow
red

[mjherzog]

For risk numbers we generally need to avoid false precision so one decimal point only.

[DennisClark]

Design document updated:

Exploitability
Exploitability may be expressed as one of these numbers, 0.5, 1.0, 2.0, where:
0.5	= no exploit known (Label: “No exploits known”) 
1.0 	= PoC/Exploit script published (Label: “Potential exploits”) 
2.0	= Automatable Exploit with PoC script published OR known exploits (KEV) in the wild OR known ransomware OR high EPSS. (Label: “Known exploits”) 
Exploitability refers to the potential or probability of a software package vulnerability being exploited by malicious actors to compromise systems, applications, or networks. It is determined automatically by discovery of exploits.

[ziadhany]

@tdruez @DennisClark The Exploitability value currently has three options (0.5, 1.0, 2.0) in the implementation for VulnerableCode. However, I believe we should store it in a decimal field rather than limiting it to these three choices. From my understanding, some exploit scripts may be unverified or come from less reliable data sources, so restricting the value to only three options might not be the best approach. Instead, I think we should allow for a continuous range (0 to 2.0), while initially starting with three predefined ranges as a baseline.

[tdruez]

@ziadhany Yes, the labels are for display purposes in DejaCode. This has no impact on your decimal implementation on the VCIO side.
See

dejacode/vulnerabilities/models.py

Lines 104 to 121 in 666ef3d

	EXPLOITABILITY_CHOICES = [
	(0.5, _("No exploits known")),
	(1.0, _("Potential exploits")),
	(2.0, _("Known exploits")),
	]
	exploitability = models.DecimalField(
	null=True,
	blank=True,
	max_digits=3,
	decimal_places=1,
	choices=EXPLOITABILITY_CHOICES,
	help_text=_(
	"Exploitability refers to the potential or probability of a software "
	"package vulnerability being exploited by malicious actors to compromise "
	"systems, applications, or networks. "
	"It is determined automatically by discovery of exploits."
	),
	)

for the current DejaCode implementation of this field. We store the decimal value but display labels in the UI.

[pombredanne]

The key "risk" score has been implemented in:

• CRAVEX: Calculate Package Vulnerability Risk vulnerablecode#1543

And merged with PR:

• Add support for Calculating Risk in VulnerableCode vulnerablecode#1593

[tdruez]

@pombredanne @DennisClark Now that we have all the score related fields available in DejaCode, where do we want to go from there regarding policies features?

[DennisClark]

Here is how we should implement a Vulnerability Policy:

Define a new field called Risk Threshold, with a format consistent with our Risk field.
Description:
A Risk Threshold is a Risk value between 0 and 10.0 that applies to a Product and indicates that any Product Package Vulnerability with a Risk at the threshold level or higher requires urgent attention but lower Risk values have a lower priority. A Risk Threshold can be defined for a DejaCode Dataspace to provide a default value for a Product.

On the Product Vulnerabilities tab, initial presentation should include only the Vulnerabilities at the Risk Threshold or higher. A toggle should be available to show all Vulnerabilities.

[DennisClark]

An empty Risk Threshold value on a Product can be treated as a Zero value.

[tdruez]

Risk Threshold implemented in #210

[pombredanne]

For reference, the Calculating-Risk-in-VulnerableCode temp design doc at https://docs.google.com/document/d/1FxeJLATdlrsDZspwByXgh5Wc_Vp83qNp/edit#heading=h.ll22skp48ksm has this content:

CRAVEX: Calculating Risk in VulnerableCode

The design is ready for implementation. Significant revisions were made to this document on 2024-09-05.

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

Background {#background}

Objective: Evaluate severity, exploitability, and context factors to calculate a software package vulnerability risk score in VulnerableCode. Use that risk score to trigger the setting of vulnerability policy values on Product Inventory Items in DejaCode.

Master GitHub issue: aboutcode-org/vulnerablecode#1543

Related GitHub issues have been assigned the “risk” tag (a changing list).

• https://github.com/nexB/vulnerablecode/labels/risk
• https://github.com/nexB/dejacode/labels/risk

Vulnerability Risk Factors {#vulnerability-risk-factors}

Origin {#origin}

One of the primary benefits of identifying a software object using a PURL, is that in addition to the identification of the package Name and Version, it identifies its origin via Type and Namespace. As an example, note that the severity and exploitability of a package as built, deployed and used in a Linux distro may be different from the same package in another platform or environment.

Severity {#severity}

Severity may be expressed as a number ranging from 0 to 10. Severity indicates the potential impact of a vulnerability as it applies to a software package, and specific severity scores may be assigned a descriptive label as in the following example:

• 9.0 - 10.0 Critical
• 7.0 - 8.9 High
• 4.0 - 6.9 Medium
• 0.1 - 3.9 Low

Ideally, a Severity score should be determined in the context of its origin, and how it is built or deployed. Note that CVSS scores from the NVD are not context sensitive.

Weight {#weight}

Weight may be expressed as a number ranging from 0 to 10. Weight refers to the reliability and authority of the data source assigning a severity. Since this is an inherently subjective score, it may be advisable to implement this using some kind of config file in VulnerableCode, which would be a list of all the data sources imported by VulnerableCode, with a Weight assigned to each one.

Specific weighting scores may be assigned a descriptive label as in the following example:

• 9.0 - 10.0 Strong
• 7.0 - 8.9 Good
• 4.0 - 6.9 Fair
• 0.1 - 3.9 Unreliable

Note that weight is more specific for a specific PURL and not just a package/version in general, because the PURL gives you more context information that is critical to assessing the severity.

Weighted Severity {#weighted-severity}

Weighted Severity may be expressed as a number ranging from 0 to 10. For a specific software package vulnerability, the assignments of severity and weighting values will vary depending on the data source reporting the vulnerability. The availability of the complete range of these severity values may be useful to support analytical research, but a range is not practical to support automated assignment of risk to a software package vulnerability.

Weighted Severity is the maximum value obtained when each Severity is multiplied by its associated Weight/10.

Example of Weighted Severity: max(7*(10/10), 8*(3/10), 6*(8/10)) = 7

Example of Weighted Severity: max(3*(10/10), 10*(3/10), 10*(8/10)) = 8

Example of Weighted Severity: max(7*(10/10), 7*(3/10), 7*(8/10)) = 7

Exploitability {#exploitability}

Exploitability may be expressed as one of these numbers, 0.5, 1.0, 2.0, where:

• 0.5 = no exploit known (Label: “No exploits known”)
• 1.0 = PoC/Exploit script published (Label: “Potential exploits”)
• 2.0 = Automatable Exploit with PoC script published OR known exploits (KEV) in the wild OR known ransomware OR high EPSS. (Label: “Known exploits”)

Exploitability refers to the potential or probability of a software package vulnerability being exploited by malicious actors to compromise systems, applications, or networks. It is determined automatically by discovery of exploits.

Risk Calculation {#risk-calculation}

Risk may be expressed as a number ranging from 0 to 10. Risk is calculated from weighted severity and exploitability values. It is the maximum value of (the weighted severity multiplied by its exploitability) or 10.

Risk = max(weighted severity * exploitability, 10)

• Example of Risk: max(7.00 * 0.5, 10) = 3.5
• Example of Risk: max(7.00 * 1, 10) = 7
• Example of Risk: max(7.00 * 2, 10) = 10

Suggested assignment of descriptive Risk labels should take that into account, as in the following example:

• 8.0 - 10.0 Critical, immediate response required
• 6.0 - 7.9 High, response required as soon as possible
• 3.0 - 5.9 Medium, investigation required
• 0.1 - 2.9 Low, response deferred

VulnerableCode Model {#vulnerablecode-model}

When a user gets software package metadata from VulnerableCode, any “Affected By” Vulnerability metadata for the specific PURL should include these 3 values: Weighted Severity, Exploitability, Vulnerability Risk. Note again that these values may vary for the same package Name/Version where the Type/Namespace values are different.

Software applications (such as DejaCode) depending on vulnerability scores for prioritization purposes, based on organization-defined policies, should make use of the Vulnerability Risk value, to automatically set priorities for analysis and the setting of vulnerability status. All 3 values should be available to support the analysis, in addition to the ability to get and explore all pertinent metadata available from VulnerableCode. That analysis will support the information needed to generate a meaningful VEX (Vulnerability Exploitability Exchange) document.

[pombredanne]

For reference, the Managing-Vulnerabilities-in-DejaCode temp design doc at
https://docs.google.com/document/d/1SRAkvoIj18quuRSap1r8-R6TMHAVPRPi/edit#heading=h.ll22skp48ksm has this content:

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.

![][image1] ![][image2]

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, andis 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.

[pombredanne]

The overall policy feature consists of these elements:

• A new vulnerability risk factor computed from multiple factors in VulnerableCode
• The integration of this risk factor fetched through VulnerableCode API for usage in DejaCode to sort and rank vulnerabilities, and set a policy for a risk threshold.

In VulnerableCode, this score is computed in VulnerableCode and exposed in the API v2

In DejaCode, we consume and use this score

We have a new vulnerabilities risk threshold field in a DejaCode Product and in a Dataspace configuration, where Product threshold takes precedence over the Dataspace configuration value.

This threshold is the main policy to help prioritize and control the level of attention to vulnerabilities.

• We also introduce a new Vulnerability Analysis model loosely based on on the CycloneDX spec: https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_analysis

This Vulnerability Analysis is always assigned to a Vulnerability object and a ProductPackage relation. The values for a Vulnerability Analysis are displayed in the Product "Vulnerabilities" tab.

A "Edit" button can be used to open a form in a model to provided analysis data.
Those new VEX related columns can be sorted and filtered.
That Vulnerability Analysis is exported in the VEX (only) and SBOM+VEX (combined) CycloneDX outputs.

A secondary element of a policy is at the ScanCode.io level, where we can exclude specific vulnerabilities entirely using a project config file.

See the related PRs and issues at:

• Add ProductVulnerabilityAnalysis model implementation #98 #187
• CRAVEX: Vulnerability exploitability: Identify and store a vulnerability exploitability #98
• Add vulnerabilities_risk_threshold fields #97 #210
• CRAVEX: Calculate Package Vulnerability Risk vulnerablecode#1543
• Add support for Calculating Risk in VulnerableCode vulnerablecode#1593
• Add support for storing exploitability and weighted severity vulnerablecode#1646