Skip to content

0459-SSVC-2-0-0-add.md

Latest commit

 

History

History
173 lines (126 loc) · 6.22 KB

0459-SSVC-2-0-0-add.md

File metadata and controls

173 lines (126 loc) · 6.22 KB

Adding SSVC 2.0.0 as optional structured metrics to CVE metrics block

Field Value
RFD Submitter Vijay Sarvepalli (CERT/CC)
RFD Pull Request RFD #0459

Summary

This proposal adds support for ** Stakeholder-Specific Vulnerability Categorization (SSVC) 2.0.0** as an optional structured element under the CVE metrics block.

Currently, SSVC data is included inconsistently in the unstructured "other" field, which limits its machine readability, interoperability, and adoption. By providing a formal schema location for SSVC, CVE Records will be able to more reliably capture and distribute this emerging prioritization framework.

Note: this proposal was previously approved in a QWG chaired by Jay Jacobs and Chris Coffin around December 2024 and initially merged in Jan 17 2025, but continued to evolve as SSVC has continued to evolve.

Problem Statement

  • SSVC is operationally used by organizations (e.g., CISA, VulnCheck, CERT/CC) to prioritize vulnerability response.
  • Today, SSVC values are often published only in custom structured, reducing consistency and limiting automated analysis.
  • Embedding SSVC data in the "other" field of CVE Records creates barriers to adoption:
    • Lack of machine readability and tooling support.
    • Inconsistent implementations across CNAs and ADPs.
    • Increased cost for downstream consumers to parse and normalize data.

Without a structured, standardized location in the CVE schema, SSVC cannot fulfill its intended role as a practical complement to CVSS and other metrics.

Proposed Solution

  • Add an optional ssvc object under the metrics block of the CVE Record schema.
  • Specify versioned support (both schema versions 1.0.0 and 2.0.0 are included).
  • Ensure fields capture the core SSVC decision points and outcomes in a standardized way.
  • Maintain backwards compatibility with existing CVE Records (non-breaking change).

This ensures that CVE Records can cleanly incorporate SSVC alongside other structured metrics such as CVSS and EPSS.

Examples

The test-cases for PR #459 illustrate how SSVC data can be expressed. For example:

https://certcc.github.io/SSVC/data/schema_examples/CVE-1900-1234-Decision_Point_Value_Selection-2-0-0.json A minimal record looks like below

{
    "timestamp": "2021-09-29T15:29:44Z",
    "schemaVersion": "2.0.0",
    "selections": [
	{
	    "namespace": "ssvc",
	    "key": "E",
	    "version": "1.1.0",
	    "values": [
		{"key": "A"}
	    ]
	}
     ]
}

A more advanced record looks like below for a similar infomration

{
    "timestamp": "2021-09-29T15:29:44Z",
    "schemaVersion": "2.0.0",
    "selections": [
        {
            "namespace": "ssvc",
            "key": "E",
            "version": "1.1.0",
            "values": [
                {"key": "A"}
            ]
        },
	{
	    "namespace": "ssvc",
	    "name": "Automatable",
	    "key": "A",
	    "version": "2.0.0",
	    "values": [
		{"name": "Yes", "key": "Y"}
	    ]
	},
	{
	    "namespace": "ssvc",
	    "name": "Technical Impact",
	    "key": "TI",
	    "version": "1.0.0",
	    "values": [
		{"name": "Total","key":"T"}
	    ]
	}
    ],
    "decision_point_resources": [{
        "summary": "A JSON file containing SSVC update to Exploitation Decision Point",
       "uri": "https://certcc.github.io/SSVC/data/json/decision_points/ssvc/exploitation_1_1_0.json"
    }],
    "references": [{
        "summary": "An exploitation example was published for this vulnerability",
        "uri": "https://example.com/report"
    }]
}

Impact Assessment

For CNAs/ADPs: Provides a formal schema location to include SSVC, reducing ambiguity and effort in data publication.

For Consumers: Simplifies automated ingestion of SSVC data, reducing the need for scraping or custom parsers.

For the CVE Program: Strengthens the role of CVE Records as a hub for standardized vulnerability metadata, aligning with the needs of defenders and decision-makers.

Compatibility and Migration

Backwards compatible: Existing CVE Records and tooling remain unaffected.

Adoption is optional: CNAs/ADPs can choose whether to include SSVC.

Migration path: CNAs currently embedding SSVC in "other" fields can gradually shift to using the structured ssvc block.

Success Metrics [success-metrics]: #success-metrics

RFD will be considered successful if:

  • At least one ADP (e.g., CISA, VulnCheck, CERT/CC) adopts the new structured ssvc block within one year.

  • Major consumer tools (CVE Services,vuln enrichment pipelines, dashboards) can automatically parse SSVC data without special parsing logic.

If adoption is slow, additional tooling or guidance may be provided to ease integration.

Supporting Data or Research

CISA Vulnrichment and VulnCheck both actively publish SSVC prioritization data, but not in a standardized, machine-readable format.

VulnCheck currently has SSVC coverage for 244,866 CVEs, while CISA Vulnrichment covers 64,142 CVEs.

See: Automating SSVC (VulnCheck blog)[[https://www.vulncheck.com/blog/automating-ssvc]

See: SSVC community which captures usage of SSVC in the real-world at (SSVC Dicssions Sightings)[CERTCC/SSVC#291]

Related Issues or Proposals

  • CVE Schema discussion on extending metrics beyond CVSS.

  • Related work on EPSS and KEV integration into CVE Records.

Recommended Priority

Medium.

SSVC is not yet universal, but adoption is growing rapidly.

Providing structured schema support now will prevent fragmentation and reduce downstream costs.

Unresolved Questions

No new questions arise except other known concerns in metrics

Future Possibilities

Tooling for Vulnogram and cveClient to adopt and use SSVC natively