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.