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 https://github.com/aboutcode-org/vulnerablecode/issues/1565#issuecomment-2306777070