Updated with RFD as requested by @ccoffin #460
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,173 @@ | ||
| # 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](https://github.com/CVEProject/cve-schema/pull/459) | | ||
|
|
||
| ## Summary | ||
| [summary]: #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 | ||
| [problem-statement]: #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. | ||
sei-vsarvepalli marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - Inconsistent implementations across CNAs and ADPs. | ||
sei-vsarvepalli marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| - 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 | ||
| [proposed-solution]: #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 | ||
| [examples]: #examples | ||
|
|
||
| The test-cases for PR [#459](https://github.com/CVEProject/cve-schema/pull/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 | ||
| ```json | ||
| { | ||
| "timestamp": "2021-09-29T15:29:44Z", | ||
| "schemaVersion": "2.0.0", | ||
| "selections": [ | ||
| { | ||
| "namespace": "ssvc", | ||
sei-vsarvepalli marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| "key": "E", | ||
| "version": "1.1.0", | ||
| "values": [ | ||
| {"key": "A"} | ||
| ] | ||
| } | ||
| ] | ||
| } | ||
| ``` | ||
|
|
||
| A more advanced record looks like below for a similar infomration | ||
|
|
||
| ```json | ||
| { | ||
| "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 | ||
| [impact-assessment]: #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. | ||
sei-vsarvepalli marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| 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 | ||
| [compatibility-and-migration]: #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. | ||
|
There was a problem hiding this comment. How is it possible to parse SSVC data without special/specific parsing logic? This is a new data structure so far as I can tell. There was a problem hiding this comment. The idea is a one consistent parsing logic, if you think the sentence is unclear - please update with a suggestion or PR in GH? No Custom logic. For e.g., the three metric records in https://cveawg.mitre.org/api/cve/CVE-2024-52270 have three different parsers needed with "special" parsing logic. That is what I mean by special. There was a problem hiding this comment. Can we document that parsing logic in this RFD? 👀 There was a problem hiding this comment. Here is the pseudo code - we can add but it is likely you will have further comments - so I leave it here for now. # 1. Load JSON
data = load_json("ssvc_data.json")
# 2. Sort SSVC metrics by timestamp (latest first)
metrics = sort_by(data.metrics, key="timestamp", descending=True)
latest_metric = metrics[0]
# 3. Extract decision points
for dp in latest_metric.selections:
namespace = dp.namespace
version = dp.version
key = dp.key
value_keys = [v.key for v in dp.values]
# 4. If human-friendly resources exist, collect them
if "decision_point_resources" in dp:
friendly_info = dp.decision_point_resources
# 5. Collect outcome if present
if "outcome" in dp:
outcome = dp.outcome
# 6. Represent the collected info
result = {
"namespace": namespace,
"version": version,
"key": key,
"values": value_keys,
"friendly_info": friendly_info if defined else None,
"outcome": outcome if defined else "Unspecified"
}
return resultThere was a problem hiding this comment. Many thanks and indeed I do have more comments. This is great to have as a reference, but with respect to the decision points it looks like it handles arbitrary values. I know there was some discussion of decision point flexibility, but maybe it makes sense to restrict decision point values for the benefit of the CVE reader? What do you think? There was a problem hiding this comment. This all looks quite complex. Again, what sort of restrictions to trees/decision models/points are you open to? The There was a problem hiding this comment. Jon, For tightly constraining the CVE Records SSVC we could restrict the namespace to be the registered ones - For creating your own decision tree: ( I don't think you care! but) The Calculator spits out a lot of information for user friendly reading and understanding. However, if you want to use python here is the example. from datetime import datetime, timezone
from ssvc.decision_tables.cisa.cisa_coordinate_dt import LATEST as decision_table
from ssvc import selection
namespace = "ssvc"
decision_points = ["Exploitation"]
values = [["Public PoC"]]
timestamp = datetime.now()
selections = []
for dp in decision_table.decision_points.values():
if dp.namespace == namespace and dp.name in decision_points:
dp_index = decision_points.index(dp.name)
selected = selection.Selection.from_decision_point(dp)
selected.values = tuple(selection.MinimalDecisionPointValue(key=val.key,name=val.name)
for val in dp.values if val.name in values[dp_index])
selections.append(selected)
out = selection.SelectionList(selections=selections,timestamp=timestamp)
print(out.model_dump_json(exclude_none=True, indent=4))output {
"timestamp": "2025-10-07T19:27:28Z",
"schemaVersion": "2.0.0",
"selections": [
{
"namespace": "ssvc",
"key": "E",
"version": "1.1.0",
"name": "Exploitation",
"values": [
{
"name": "Public PoC",
"key": "P"
}
]
}
]
}There was a problem hiding this comment.
Oh, that sounds great. Lets do it! I think we add a control on the namespace value with the json schema There was a problem hiding this comment. Yes, we should chat in the QWG briefly, that way others are aware before I can make an update to the schema with that big change. There was a problem hiding this comment. Cool. That change would help align to the goal of preferring structure data |
||
|
|
||
| If adoption is slow, additional tooling or guidance may be provided to ease integration. | ||
|
|
||
| ## Supporting Data or Research | ||
| [supporting-data-or-research]: #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)[https://github.com/CERTCC/SSVC/discussions/291] | ||
|
|
||
|
|
||
| ## Related Issues or Proposals | ||
| [related-issues-or-proposals]: #related-issues-or-proposals | ||
|
|
||
| * CVE Schema discussion on extending metrics beyond CVSS. | ||
|
|
||
| * Related work on EPSS and KEV integration into CVE Records. | ||
|
|
||
| ## Recommended Priority | ||
| [recommended-priority]: #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 | ||
| [unresolved-questions]: #unresolved-questions | ||
|
|
||
| No new questions arise except other known concerns in metrics | ||
|
|
||
| ## Future Possibilities | ||
| [future-possibilities]: #future-possibilities | ||
|
|
||
| Tooling for Vulnogram and cveClient to adopt and use SSVC natively | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you expand on the problem that SSVC itself tries to address?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SSVC is a framework for metrics of a vulnerability. Perhaps review https://certcc.github.io/SSVC/tutorials/ssvc_overview/ - some of these questions may be goes into SSVC GitHub? The assumption here is you are aware of SSVC basics I suppose.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels like a bad assumption to make. I would assume most CVE consumers are not familiar with SSVC and so a conversation about its merits and how it works seems like a value add to the CVE community. I have read the intro doc, but my question here is more CVE specific. Could you expand on the problem facing CVE consumers and how SSVC could be used to address their problem?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is realistic to explain SSVC to the level in which all justification of current usage will need to be expanded. The RFD is not a full historic document as I read it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you comment on who's using it and why maybe? I'm not trying to get a super exhaustive explanation, but something which could be helpful to the uninitiated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CISA, Bitsight, VulnCheck, Rapid7 are current consumers of SSVC data. All these are using it for analysis and reporting of vulnerabilities.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, so they're using it by providing supplier decision points?
Sorry but that kinda reads like
they're using it to do a thingto me and I can't parse much from it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Most of the usage that is currently public is in Coordinator and Deployer decision trees. it is being used by Coordinators like CISA to provide information on. vulnerability, and used by Vulnerability Managed Services to prioritize patch management. Currently Supplier decision trees are used privately for supplier's to decide their scheduling of patch release priority, they could publish it depending on their PSIRT and transparency expectation of patch creation/adoption.