Additional metadata such as prioritization scores for vulnerabilities

[sei-vsarvepalli]

CSAF team,

The CSAF scores object https://github.com/oasis-tcs/csaf/blob/164cad8c37edd1265900f6ca3ca3fa3ff84f1a2e/csaf_2.0/json_schema/csaf_json_schema.json#L1255 currently support cvss_v2 and cvss_v3. CERT/CC is also exploring Stakeholder Specific Vulnerability Categorization (SSVC) which attempts a different approach for prioritizing a vulnerability.

We have a JSON schema, definition and examples of such scores available at CERT/CC's Github page https://github.com/CERTCC/SSVC. I would like to learn the best ways to represent such data in CSAF.

An example is shown here for convenience using an array for fields under the property called "metrics". Note: the SSVC decisions can have multiple values for a single vulnerability by CVE) or a group of vulnerabilities (say by CERT''s VU#). SSVC also have a timestamp field which can be used to update a vulnerability's computed prioritization.

Thanks Vijay

        "metrics": [{
        "other": {
            "type": "ssvc",
            "content": {
            "role": "Coordinator",
            "id": "CVE-2022-0012",
            "version": "2.0",
            "generator": "Dryad SSVC Calculator 5.1.1",
            "computed": "SSVCv2/E:N/A:Y/T:P/P:M/B:M/M:L/D:T/2022-02-09T18:45:53Z/",
            "timestamp": "2022-02-09T18:45:53Z",
            "options": [
                {
                "Exploitation": "none"
                },
                {
                "Automatable": "yes"
                },
                {
                "Technical Impact": "partial"
                },
                {
                "Mission Prevalence": "Minimal"
                },
                {
                "Public Well-being Impact": "Minimal"
                },
                {
                "Mission & Well-being": "low"
                },
                {
                "Decision": "Track"
                }
            ],
            "reference_schema": "https://democert.org/ssvc/SSVC_Computed_v2.02.schema.json",
            "decision_tree_url": "https://democert.org/ssvc/CISA-Coordinator-v2.0.3.json"
            }
        }
        }]

[sthagen]

@sei-vsarvepalli it is just an example stated, I understand, but the values look a bit volatile. Can you maybe kindly provide a link to a schema file? Poking around in the repository I found many interesting things but no schema definition I recognized. Thanks. That would help me - and I guess the other TC members as well - a lot to support you in your endeavor.

[tschmidtb51]

@sei-vsarvepalli I like the idea of including SSVC - it was already on the list. However, I had a look at the schema and IMHO we need to work a little bit on it before we can include that. I'm happy to help with the work one we have the CSD02 out. Maybe that including SSVC is something for CSAF 2.x?

Here are some points, I think we need address:

• Schema draft: That should be updated to 2020-12 as draft-04 is incompatible. (Just a minor one.)
• documentation: What are the field? How should they be used?
• precedence (vector vs single points)
• validation
• usage of id (Why is this mandatory, at least in the computed one?)

[sei-vsarvepalli]

Hello @sthagen

Thanks for such a quick response. The schema for the "content" object comes from here. The "metrics" is a way to potentially update your schema to provide score containers that can be SSVC or other options like EPSS that are being explored as potential candidates for the challenging vulnerability prioritization problem.

https://github.com/CERTCC/SSVC/blob/92349cd8960ab40db72c4eb6fc4339f0f51f2fd8/data/schema/SSVC_Computed_v2.02.schema.json

An example result that uses a computed schema is in the link below:

https://github.com/CERTCC/SSVC/blob/92349cd8960ab40db72c4eb6fc4339f0f51f2fd8/data/schema_examples/Computed-CVE-2014-0751-Coordinator-v2.0.3.json

[sei-vsarvepalli]

@sei-vsarvepalli I like the idea of including SSVC. However, I had a look at the schema and IMHO we need to work a little bit on it before we can include that. Maybe that's something for CSAF 2.x?

Here are some points, I think we need address:

• Schema draft: That should be updated to 2020-12 as draft-04 is incompatible. (Just a minor one.)
• documentation: What are the field? How should they be used?
• precedence (vector vs single points)
• validation
• usage of id (Why is this mandatory, at least in the computed one?)

Hello Tomas,

The id field is unique identifier for each vulnerability.

https://github.com/CERTCC/SSVC/blob/92349cd8960ab40db72c4eb6fc4339f0f51f2fd8/data/schema/SSVC_Computed_v2.02.schema.json#L47-L49

    "id": {
        "type": "string",
        "description": "Identifier for a vulnerability could be CVE, CERT/CC VU#, OSV id, Bugtraq etc."
    },

As far as other issues CSAF current scores object only has CVSS as the possibility as I understand. I recommend either extending that to be more like "metrics" or if you feel like CVSS actually is the correct way to "score" a vulnerability, consider additional field metrics perhaps?

Thanks Vijay

[sthagen]

The schema seems to add a very open extension point. This producers can already achieve by using the non-strict CSAF mode, where they can inject any objects they like and that do not conflict with specified names (per the CSAF version in use - currently 2.0).

I can very well imagine that future CSAF versions will introduce a metrics Element - a common trait these days - with exactly that name (in SARIF we also discuss this as candidate extension of the existing format version.

So, maybe you want to inject with a safer name, decorated with a namespace guard?

When the CSAF v2.0 iteration is done, maybe we can exchange more specific ideas on how to define real metrics that are both useful to produce and (which I am missing from the given schema and examples) automate.

[sei-vsarvepalli]

Hello @sthagen

Thanks for considering this and the option to use the "non-strict" CSAF schema. I had some discussions with @tschmidtb51 as well on potential way forward into CSAF 2.x as it evolves as well (like you mentioned).

Finally, the result we are really after is to enable operators to prioritize vulnerabilities. So even if we integrate in the non-strict CSAF schema, we would be in touch with your team so there is opportunity to enrich vulnerability data and provide actionable feed to the operations.

Thanks Vijay

[sthagen]

Some proposals for SARIF to offer harmonized/simplified/unified scales for metrics are:

• https://github.com/oasis-tcs/sarif-spec/issues/611
• https://github.com/oasis-tcs/sarif-spec/issues/612

The initial use cases are driven by learnings/needs from GitHub Advanced Security's code scanning feature.

[zmanion]

Updating this feature request with:

1. Plus one to wanting SSVC support in CSAF, possibly via a somewhat generic "metrics" feature (metrics could include various versions of CVSS, SSVC, others in the future), this belongs within the vulnerability node

2. SSVC JSON schema is being updated: https://github.com/CERTCC/SSVC/issues/576

I'm not sure how to implement SSVC as "non-strict" CSAF but am exploring that option. Another hack would be to add a vulnerability note containg terse a SSVC vector string as the description.

[tschmidtb51]

@sthagen, @santosomar: We should discuss this request in our next TC meeting.

[santosomar]

Absolutely! Consider it in the agenda. Great suggestions and conversation here!

[sei-vsarvepalli]

Thank you all One small update from earlier conversation - Vector Representation of SSVC is currently not quietly fully baked - https://github.com/CERTCC/SSVC/issues/333 . But a full JSON representation now exists and hopefully will be part of projects like vulnrichment and VINCE.

[tschmidtb51]

@sei-vsarvepalli Thank you for pointing that out. If the TC decides to include that (which I hope), I'll probably come back to you to clarify any open question.

[sei-vsarvepalli]

Pursue this with https://github.com/oasis-tcs/csaf/issues/803 , which has more current information and the updated schema. I recommend closing this issue in favor of the #803