CRAVEX: Vulnerability exploitability: Reachability integration

[pombredanne]

Create models and design API to integrate external tool's reachability analysis results inform vulnerability ranking

See also:

• RFC: vulnerability reachability vulnerablecode#1313

[DennisClark]

A reachable vulnerability has a path from your code to the root cause of a vulnerability.

Gauge risk by identifying whether a function related to the vulnerability is being called by your application, raising the chances of that vulnerability being exploitable in the context of your application.

[DennisClark]

A "reachability ranking" appears to be relevant to product or other first-party code ("your code") and applies to that usage context.

[pombredanne]

Here is my take:

A definition of reachability

from https://owasp.org/www-chapter-los-angeles/assets/prez/OWASPLA_prez_2024_03-1.pdf

Vulnerability Reachability Analysis

Code that is contains vulnerabilities is bad
Code that contains vulnerabilities used in your application is worse
How do you know if some code you are using is vulnerable?
Better yet, how do you know you’re even using the vulnerable code at all?

Minimal design

In this context there are tools that can determine if a vulnerable piece of code is effectively used and reached in some way.

The goal of this issue is to provide a way to track this information. For a simple start, we could have a trib-oolean field at the intersection of product packages and vulnerability that state if a this vulnerability is reachable or not reachable, or this fact is not known. Bonus if we have an extra field that explain how this was determined.

We are going to provide a minimal UI to update the data in these new fields, so that a user can do this. And a way through the API to update the data so we can offer an entry point for tools to contribute their results

And finally, this reachability should also influence the ranking of vulnerabilities in a product as detailed in:

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

[tdruez]

The goal of this issue is to provide a way to track this information. For a simple start, we could have a trib-oolean field at the intersection of product packages and vulnerability that state if a this vulnerability is reachable or not reachable, or this fact is not known. Bonus if we have an extra field that explain how this was determined.

@DennisClark Could you review this design and provide name and help for those new fields so I can get started on the implementation. Thanks!

[DennisClark]

@tdruez and @pombredanne I think we actually already cover the functionality described here in the ability to edit the Analysis of a product package vulnerability. I don't think we need to introduce anything completely new and we can declare this functionality covered by the Analysis fields. See example screenshot.

[tdruez]

Implemented in #206 (comment)

Changes:

• Add is_reachable field on the VulnerabilityAnalysis model as a tri-boolean field: yes, no, unknown
• Reachability column added in the "Vulnerability" tab.
• Add filter by "Reachability" from the column header.
• The is_reachable value can be set from the "Vulnerability analysis" modal form
• Add a VulnerabilityAnalysis REST API endpoint.