CRAVEX: Vulnerability exploitability: Identify and store a vulnerability exploitability

[pombredanne]

Create UI and DB models to create and store effective exploitability both org-wide and app- or product-specific.

We should also include tracing data to document the disposition of a vulnerability. (e.g., Tag a package as affected or not either globally, or just for one or more products)

[DennisClark]

see related issue https://github.com/nexB/vulnerablecode/issues/1028

[tdruez]

The next step is to implement the VulnerabilityAnalysisMixin into a concrete Product-context model. The fields available on this mixin are an implementation of the CycloneDX model. Once the concrete model is done, those fields should be added to the Product > "Vulnerabilities" tab as new sortable/filterable columns. Also, an add/edit form should be added in a modal so the Vulnerability analysis fields can directly updated from this tab.

Once this is completed, those fields can be added to the CycloneDX VEX output, at https://github.com/aboutcode-org/dejacode/issues/108

[pombredanne]

from: https://github.com/aboutcode-org/dejacode/issues/108#issuecomment-2332004824

Once the analysis fields from #98 (comment) are available, those can be added in the Vulnerability.as_cyclonedx() method at https://github.com/aboutcode-org/dejacode/blob/main/vulnerabilities/models.py#L206 The content of as_cyclonedx() is directly available in the new VEX output.

[tdruez]

@DennisClark In the context of the PR https://github.com/aboutcode-org/dejacode/pull/187 which focuses on the "Analysis" part of the vulnerability system. I wanted to continue the discussion about the status field.

For now, I've started the implementation with the fields directly from the CDX VEX spec: https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_analysis

This includes a state field with the following supported values:

• "resolved"
• "resolved_with_pedigree"
• "exploitable"
• "in_triage"
• "false_positive"

But the vulnerability status design from https://docs.google.com/document/d/1SRAkvoIj18quuRSap1r8-R6TMHAVPRPi/edit has different values: ● None Identified (the default) and the standard VEX Status values ● Not affected – No remediation is required to address vulnerabilities associated with the package. ● Affected – Actions are recommended to remediate or address vulnerabilities associated with the package. ● Fixed – Indicates that a fix is available for vulnerabilities associated with the package. ● Under Investigation – applied automatically to a Package when a new vulnerability is identified for it.

Since we want to be able to export VEX CDX documents, we somehow need to relate and reconcile those values.

I don't think having multiple status fields is a good idea. I think a single status field is enough, but I want to make sure the choices available there allow for a VEX export. How do we want to handle this? Let's say the status is set to "Affected", what's the value for the state in the VEX export file?

Should we start with a hardcoded mapping of the DejaCode Vulnerability.status choices and the CDX state choices (and CISA ...)? Or do you have another approach in mind?

---

Alternatively, we could add a new VulnerabilityStatus table, where we would have fields that would allow to define how the status is expressed in the CDX or CISA context. For example:

VulnerabilityStatus

• label = "Resolved"
• help = "Indicates that a fix is available for vulnerabilities associated with the package."
• cdx_state = "resolved"

This is probably a more flexible approach, but it would add some complexity and will require more configuration for the Dataspace manager.

[DennisClark]

@tdruez After further thought, and considering that actual implementations of the CISA-suggested VEX status values are most likely extremely rare, I think we should stick with the fields directly from the CDX VEX spec: https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_analysis

I will update the design document later today.

[tdruez]

I will update the design document later today.

@DennisClark Let me know when you are done with the design and I will finish the Analysis implementation ;)

[DennisClark]

@tdruez design document updated

[tdruez]

@DennisClark Following the implementation of the new vulnerability fields in https://github.com/aboutcode-org/dejacode/pull/194, I want to clarify where we want to go next. Especially about Vulnerability Analysis and VEX support.

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

introduce a "Vulnerability Status" table to define status codes that can be applied to Package and Product Package.

I'm trying to reconcile this new concept with my initial implementation of the VEX structure based on the CDX spec https://cyclonedx.org/docs/1.6/json/#vulnerabilities_items_analysis

The VEX spec for "Analysis", as defined as "An assessment of the impact and exploitability of the vulnerability.", focuses only on a single Vulnerability instance in the context of a Product. It includes a status and a few other fields to qualify the Vulnerability.

Whereas, the "Vulnerability Status" current design applies to a whole Package (in the context of a Product or globally) and is not directly attached to a Vulnerability instance.

As multiple vulnerabilities can affect one Package in multiple ways, I'm wondering about the ability to handle this complexity with a simple "Vulnerability Status".

I think we need a bit more discussion on how to reconcile the "Vulnerability Exploitability Analysis" of a given Vulnerability and the "Vulnerability of a Package".

@pombredanne Input welcome :)

[DennisClark]

@tdruez In light of your very pertinent comments about where a VEX belongs in the model, I have edited the initial statements of Issue #15 (which was originally written before the CRAVEX items were identified, so we have some duplication and overlap) and am copying them here, which hopefully will help us with discussions about the detail design.

Introduce VEX Support to DejaCode

enhance data model to support a Product VEX List
provide Export capabilities to produce VEX documents that comply with industry-recognized formats

Here are a few suggested details (subject to improvement upon review):

A VEX (Vulnerability Exploitability Exchange) is an assertion about the status of a vulnerability in specific products.

In DejaCode a VEX exists only in the context of a Product. Our first implementation of VEX support will apply to Product Packages Vulnerabilities

The standard VEX Status can be 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"

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

Given that a Product Package can have more than one vulnerability (VCID) and that a vulnerability can apply to more than one Product Package, it is probably best to consider defining each VEX in DejaCode as relating to a Product Package Vulnerability. Consider an on-demand process (button or command) in DejaCode that collects all the Vulnerabilities currently associated with Product Packages and creates or refreshes a list that we can call “Product VEX List” (working title) and presents them on a new tab (“VEX List”) of the Product User View.

The “logical” key of a Product VEX List is Product+VCID+PackageID (or perhaps Product+PackageID+VCID), and the presentation should be in that order, with one row for each Product VEX. Supporting data elements should include:

VEX Status (default value “in_triage”) – modifiable
VEX Action. modifiable. free form text. If the status is "exploitable", a valid VEX must have an action statement that tells the product user what to do.
VEX Impact modifiable. free form text. If the status is "false_positive", a valid VEX must have an impact statement to further explain details.
VEX Notes. modifiable. free form text. Additional notes to explain the VEX.

DejaCode Processing:

From the Product VEX list, ability to open a Product VEX detail form that includes the various VEX fields discussed above. From the Product VEX list, provide a navigation link to the Product Package details. Provide full support for Product VEX in Reporting. Provide full support for Product VEX in the DejaCode API. (future) Generate DejaCode Notifications when a Product VEX is created and when the VEX Status is modified. Provide a link to the Product VEX from the Notification.

Some useful files, background, and links:

See the example VEX at

https://github.com/CycloneDX/bom-examples/blob/master/VEX/vex.json

There is a descriptive overview of the CycloneDX approach to VEX here

https://github.com/CycloneDX/bom-examples/tree/master/VEX

DejaCode supports SBOM with or without VEX, as well as VEX documents.

After we finish CycloneDX: The CSAF standard format, recommended by the CycloneDX team, is described here: https://www.oasis-open.org/2022/11/28/common-security-advisory-framework-version-2-0-oasis-standard-is-now-published/

The CSAF also provides a downloadable package of the spec here: https://docs.oasis-open.org/csaf/csaf/v2.0/os/csaf-v2.0-os.zip

The most useful file in that package for us is probably csaf_json_schema.json

Additional guidelines from CISA 2023-11-06 attached. When-to-Issue-a-VEX-508c.pdf.zip

Interesting commentary from Tom Alrich attached. When will there be VEX tools.pdf

[DennisClark]

We can modify/enhance the existing Product Vulnerabilities tab to implement the various new features described above. Also, we don't need to call it "VEX Status"; Vulnerability Status will work.

[DennisClark]

Consider a vulnerability status on the Product Package that is actually computed based on the value(s) of the associated product-package-vulnerabilities.

[DennisClark]

Default status for a new vulnerability will be null, rather that in_triage