CRAVEX: Vulnerability exploitability: re-rank for product context and policies

[pombredanne]

Re-rank the exploitability scores given the org and local app/product context and policies

[DennisClark]

not sure I understand what is being re-ranked: specific vulnerabilities? specific packages? the vulnerable packages in a product inventory? (probably the last one i guess)

[pombredanne]

Here is my take:

Initial global context

Say we start from a DejaCode products with packages where we have identified known vulnerabilities, and we are getting scoring from VulnerableCode for each of these as they apply to the packages, and this in in abstract of the context of this specific product.

Product-specific context

Now, there are some packages may not be deployed, some may be modified, some may have a specific purpose. The product may be designated as private/internal, public, more or less critical. It may have specific characteristics that matter wrt. vulnerability exploitability: for instance a customer-facing web app, that is internet accessible may have a different profile than a ECU in car, or an embedded device for industrial control or an app on a phone.

Here we should have way to account for the Product-specific context to "re-rank" the exploitability.

For instance, if a package is not deployed in a product, the priority rank or order for this vulnerability in this package in this product should be lowered. If we have ranked list of vulnerabilities then this would move down.

Taking into account policies

It could be that a policy for a product or a global policy demands to address all vulnerabilities with a certain risk, exploitability or risk score threshold. And this could be then be used to change the order of issues. There is design to do done here of course

[pombredanne]

Here is a more specific design:

1. A product item (package or component) has a Purpose https://github.com/aboutcode-org/dejacode/blob/356001e74369967f6de121ac1ffb90661ab4cfa7/product_portfolio/models.py#L587
2. We could add an "exposure factor" field to each Purpose that would be a number between 0 and 10 (or a float between 0 and 1) where NULL/None would mean this is not set
3. The actual risk inherited from a package vulnerability would be weighted by this exposure factor

As example, if a Product has a Junit package with a vulnerability and the computed vulnerability risk of 9 with a Purpose of test, and that the test purpose has an exposure factor of 0.1, then the re-ranked, re-evaluated risk for this Junit vulnerability in that specific Product would become something like 9 x 0.1 = 0.9... e.g., the purpose of a package in a product boosts or lessens the risk.

[DennisClark]

regarding the suggested design details:

• I think we should settle on a float between 0.0 and 1.0 for the "exposure factor", which would then become new field in the "Product item purposes" table. I agree that it can default to an empty value, meaning not set.
• reword the third point to something like "The actual product package risk would be inherited from a package vulnerability risk as weighted by the exposure factor in the context of the package purpose in the product."

[DennisClark]

Suggested help text for "exposure factor" A number between 0.0 and 1.0 that identifies the vulnerability exposure risk of a package as it is actually used in the context of a product, with 1.0 being the highest exposure risk and 0.0 being no exposure risk at all.

[DennisClark]

The new "weighted" risk score value would replace the current non-factored risk score on the Product Vulnerabilities tab. If there has not been any exposure factor assigned to the corresponding Purpose, the non-factored Package risk is used.

Suggested new help text for the Risk on the Product Vulnerabilities tab:

Risk score from 0.0 to 10.0, with higher values indicating greater vulnerability risk. This score is the maximum of the weighted severity multiplied by exploitability, capped at 10, which is then multiplied by the associated exposure risk factor assigned to the product package purpose (when available).

(and yes, class, there will be a quiz on this soon ...) suggestions to make the definition easier to understand are welcome!

[tdruez]

Implemented in https://github.com/aboutcode-org/dejacode/pull/218

• Add exposure_factor field to the ProductItemPurpose model and a weighted_risk_score on the ProductPackage model. The weighted_risk_score is computed from the package.risk_score and purpose.exposure_factor values.

• Add the vulnerability icon in Product list view. A "Is Vulnerable" filter is also available. The count in the Vulnerability tab was improved to include the count of affected packages and the count of unique vulnerabilities. Note that those count reflect the current risk threshold.