Updated with RFD as requested by @ccoffin

[sei-vsarvepalli]

Added RFD's to document the changes and capture example of the SSVC 2.0.0 record as requested by QWG.

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.

[sei-vsarvepalli]

Feedback from meeting on October 2 2025:

1. Provide minimalist example even in the advanced record to ensure there is a clear understanding of what minimal information needs to be parsed by consume even in the "advanced record" @jayjacobs updated the CVE example
2. Add any information on operational usage of SSVC by the community users and their feedback (added to RFD document)

[darakian]

Can you expand on the problem that SSVC itself tries to address?

[sei-vsarvepalli]

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.

[darakian]

The assumption here is you are aware of SSVC basics I suppose.

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?

[sei-vsarvepalli]

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.

[darakian]

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.

[sei-vsarvepalli]

CISA, Bitsight, VulnCheck, Rapid7 are current consumers of SSVC data. All these are using it for analysis and reporting of vulnerabilities.

[darakian]

Ok, so they're using it by providing supplier decision points?

All these are using it for analysis and reporting of vulnerabilities.

Sorry but that kinda reads like they're using it to do a thing to me and I can't parse much from it.

[sei-vsarvepalli]

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.

[darakian]

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.

[sei-vsarvepalli]

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.

[darakian]

Can we document that parsing logic in this RFD? 👀

[sei-vsarvepalli]

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 result

[darakian]

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?

[darakian]

This all looks quite complex. Again, what sort of restrictions to trees/decision models/points are you open to? The import tree option on this calculator opens a file upload dialog which I would guess allows for arbitrary logic. Without documentation arbitrary logic isn't helpful to the reader.

[sei-vsarvepalli]

Jon,

For tightly constraining the CVE Records SSVC we could restrict the namespace to be the registered ones - ssvc , nist - see https://certcc.github.io/SSVC/reference/code/namespaces/#base-namespace for the full list. This means companies (e.g., Yahoo) working on their own decision trees cannot publish any customization they develop in this schema format - CERT/CC will have to adopt and control it.

For creating your own decision tree: ( I don't think you care! but)
You can go to the SSVC Explorer to create your own tree to import. Or Just a CSV file upload. our pypi site also has examples for a "weather" decision tree that you can follow to create your own.

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"
                }
            ]
        }
    ]
}

[darakian]

For tightly constraining the CVE Records SSVC we could restrict the namespace to be the registered ones - ssvc , nist - see https://certcc.github.io/SSVC/reference/code/namespaces/#base-namespace for the full list. This means companies (e.g., Yahoo) working on their own decision trees cannot publish any customization they develop in this schema format - CERT/CC will have to adopt and control it.

Oh, that sounds great. Lets do it! I think we add a control on the namespace value with the json schema oneOf keyword 👍

[sei-vsarvepalli]

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.

[darakian]

Cool. That change would help align to the goal of preferring structure data
#423 (comment)

[darakian]

I left a number of specific comments and I know I'm coming from a point of ignorance, but I'm not sure I understand the goal(s) of SSVC. I read through this RFD and the actual PR (which got merged in record time 🎉) and there's a lot of language explaining what is changing but very little that explains the why.

Could you expand on the value to an uninitiated consumer of these records? I can see the value of knowing that an exploit module exists out in some open source tool or whatever, but could this information be encoded in such a way that it compliments information we already store? The technical impact decision point in particular seems like it could be inferred from the CVSS CIA triad (all H => total).

Thoughts?

[sei-vsarvepalli]

technical impact

Can you give an example of the "information we already store" in CVE records that duplicates SSVC?

It is also clear you have some input for SSVC itself unrelated to CVE record questions, so can you please create an issue in SSVC GitHub perhaps with a suggestion or question.

[darakian]

Can you give an example of the "information we already store" in CVE records that duplicates SSVC?

The one that comes to mind is an advisory with a CVSS score where the CIA values are all H. Eg. Total loss of confidentiality, integrity, and availability. This would also imply a technical impact rating of total correct?

[sei-vsarvepalli]

Can you give an example of the "information we already store" in CVE records that duplicates SSVC?

The one that comes to mind is an advisory with a CVSS score where the CIA values are all H. Eg. Total loss of confidentiality, integrity, and availability. This would also imply a technical impact rating of total correct?

I understand why it might seem that certain CVSS vector elements, like all CIA values being set to H, could imply an SSVC outcome such as "Technical Impact = Total." However, "implied" does not mean "assessed." In SSVC, each decision point (such as Technical Impact, Exploitation, or Mission Impact) is explicitly and independently evaluated based on the evidence and the organization’s (CNA or ADP) policy framework. The assessment is not necessarily derived or inferred from other scoring systems like CVSS. Technical Impact is defined here https://certcc.github.io/SSVC/reference/decision_points/technical_impact/ to address very specific example.

[darakian]

Could it ever be the case that one would come to the conclusion that an SSVC technical impact should be total and simultaneously come to the conclusion that a CVSS impact would not be all H?

[sei-vsarvepalli]

Could it ever be the case that one would come to the conclusion that an SSVC technical impact should be total and simultaneously come to the conclusion that a CVSS impact would not be all H?

Please read up https://www.bitsight.com/blog/do-we-need-yet-another-vulnerability-scoring-system-ssvc-thats-yass - they exactly talk about this question. However, the information even if as you say the score is implied, it is still not duplicative. There are also other Technical Impact values - it also seems nonsensical to talk about each combination of possibility of CIA to Technical Impact, as they are not the same. Hopefully that part is clear.

For technical impact the vast majority of the vulnerabilities with “total” impact have “high” impact on Confidentiality, Integrity and Availability (88%), though it’s not universally true.

You can also read the recent paper that may help you understand current SSVC metrics https://arxiv.org/pdf/2508.13644v1

[darakian]

I feel like I'm more confused now. Your first link states

For technical impact the vast majority of the vulnerabilities with “total” impact have “high” impact on Confidentiality, Integrity and Availability (88%), though it’s not universally true.

But then doesn't get into why this may be the case. Perhaps the remaining 12% were scored in error? It does seem like there's a very high correlation so maybe these are measuring the same thing and a future cve spec could encode the underlying concept more directly.

I quite liked the paper and it does seem to indicate that there's a difference in observable scores, but it also seems like its a real downer on the metrics period. The conclusion

8 Conclusions
This paper presents the first large-scale, empirical evaluation of
four prominent vulnerability scoring systems—CVSS, EPSS, SSVC,
and the Exploitability Index—using a real-world dataset of 600 vul-
nerabilities from Microsoft’s Patch Tuesday disclosures. Our study
was designed to fill a critical gap left by prior work, which has been
largely qualitative, by providing quantitative evidence of how these
systems perform in an operational context. The findings demon-
strate considerable and systemic disagreement among the systems,
which exhibit little to no correlation or categorical agreement when
scoring the same vulnerabilities. We found that all four systems
produce overly broad priority groups that complicate triage efforts
and that predictive systems like EPSS often fail to flag known ex-
ploited vulnerabilities ahead of time, with fewer than 20% of CISA
KEV CVEs receiving a high-confidence score before exploitation
was public.
The central implication of this research is that these widely used
scoring systems are not interchangeable and their conflicting guid-
ance reveals a deeper, systemic issue: a lack of a shared conceptual
model of risk across the vulnerability management ecosystem. The
observed divergence is a direct result of each system’s unique de-
sign goals—measuring inherent severity versus predicting threat
likelihood versus recommending a specific action. Given these find-
ings, we caution practitioners against relying on any one system
as the sole basis for prioritization; scores should be treated as ad-
visory inputs to a broader, context-aware process. Ultimately, our
study highlights an urgent need for the research community to
develop more transparent, interpretable, and task-specific frame-
works that are empirically grounded and better aligned with the
practical realities of cybersecurity operations.

I agree with it, but I feel like its maybe not making the case for SSVC. Fun note, I went to grad school with one of the authors, so I'll reached out and see if I can get more of their perspective directly.

[zmiele]

@sei-vsarvepalli I'm afraid I won't be able to attend today's discussion, but I'd been really looking forward to it, I'll try to jot down some thoughts here.

I apologize that it's a little long-winded, the tl;dr is that while I'm finding SSVC very interesting and a lot of potential utility, what SSVC provides and CVE records should provide doesn't seem to align.

As I've been reading more about SSVC there are some things I really like about it and want to experiment with using it internally for a few things, but I'm having a hard time imagining what value I'd get by ingesting this from another stakeholder that I wouldn't rather see in a CSAF document or something I'm getting from that stakeholder directly. I wonder if adding these to CVE records is meaningful in a way that SSVC can't already provide from other sources, and I'm struggling to imagine how.

I also worry for opportunity for consumer confusion. One concern I have is definitely the very broad flexibility, and I know it's been mentioned already in discussion about restricting the accepted namespaces (which is an idea I support), but I also worry about misuse of those namespaces by CNAs or ADPs who are not that type of stakeholder. For example, should I be able to provide information of every stakeholder type that the record format supports? If multiple data providers provide conflicting decisions in the same record, what should I take away as a consumer?

That last part also leads me back to something that I have also had a hard time shaking while thinking about this, it really is (as the name states!) stakeholder focused and not quite directly vulnerability focused. I worry about the utility there for consumers looking for CVE information and not how everyone is reacting to it. I know that some of the values do describe the CVE itself, but they are also covering other decision factors that are not metrics about a vulnerability. It would seem to me that those metrics are likely already able to be expressed in the records, and if not those specific metrics should be added.

I could see some interesting opportunities here though, especially with the idea that more ADP types gives opportunity for providers to share more information that while vulnerability-centric, is clearly through the lens/perspective of the ADP. At that point though I'm not sure that metrics is the right place for SSVC to be. The way that SSVC resolves to an outcome and doesn't strictly describe the vulnerability itself leaves me feeling that it shouldn't be in the metrics category at all.

[sei-vsarvepalli]

@sei-vsarvepalli I'm afraid I won't be able to attend today's discussion, but I'd been really looking forward to it, I'll try to jot down some thoughts here.

I apologize that it's a little long-winded, the tl;dr is that while I'm finding SSVC very interesting and a lot of potential utility, what SSVC provides and CVE records should provide doesn't seem to align.

As I've been reading more about SSVC there are some things I really like about it and want to experiment with using it internally for a few things, but I'm having a hard time imagining what value I'd get by ingesting this from another stakeholder that I wouldn't rather see in a CSAF document or something I'm getting from that stakeholder directly. I wonder if adding these to CVE records is meaningful in a way that SSVC can't already provide from other sources, and I'm struggling to imagine how.

I also worry for opportunity for consumer confusion. One concern I have is definitely the very broad flexibility, and I know it's been mentioned already in discussion about restricting the accepted namespaces (which is an idea I support), but I also worry about misuse of those namespaces by CNAs or ADPs who are not that type of stakeholder. For example, should I be able to provide information of every stakeholder type that the record format supports? If multiple data providers provide conflicting decisions in the same record, what should I take away as a consumer?

That last part also leads me back to something that I have also had a hard time shaking while thinking about this, it really is (as the name states!) stakeholder focused and not quite directly vulnerability focused. I worry about the utility there for consumers looking for CVE information and not how everyone is reacting to it. I know that some of the values do describe the CVE itself, but they are also covering other decision factors that are not metrics about a vulnerability. It would seem to me that those metrics are likely already able to be expressed in the records, and if not those specific metrics should be added.

I could see some interesting opportunities here though, especially with the idea that more ADP types gives opportunity for providers to share more information that while vulnerability-centric, is clearly through the lens/perspective of the ADP. At that point though I'm not sure that metrics is the right place for SSVC to be. The way that SSVC resolves to an outcome and doesn't strictly describe the vulnerability itself leaves me feeling that it shouldn't be in the metrics category at all.

Hello Zack,

thanks for your feedback. We will discuss this in the meeting. To be clear on the duplicative and unauthoritative information from ADP or other providers, the problem is not just SSVC it could also be CVSS or affectd products even and any other information provided by multiple providers.

On the meeting I will definitely bring up the namespace discussion as requested.

On your third concern, on various "decision points" of SSVC and what is relevant and specific to a vulnerability vs the environment. The published SSVC metrics in a CVE record should only be about the vulnerability. This problem is true for CVSS and any other metric as well. It cannot include Asset Impact or such metrics that are not part of the relevant SSVC decision tree anyway for vulnerability reports.

[ccoffin]

Hi Vijay,

Here are my current notes and observations from my testing and from the QWG meeting yesterday. I think all of this rests on whether we want to retain strict compatibility with SSVC, or we modify and trim to meet the needs of a CVE Record. My current thought is that we should go that latter route and implement one or more of the following changes.

1. Should we include SSVC 1.x schema? I think this depends on whether there is any consumer demand for this. Maybe we should query the CWG. I would also be curious about what the CISA ADP would use given a choice. SSVC 1.x schema is closer to what the CIS ADP uses today. Would they be willing to move the the 2.x schema?

2. One of my initial observations was around the use of the 1.x required "id" property, and i think we identified that 2.x changed this to "target_ids" and it is optional. Because the SSVC will be included within a CVE Record where it already identifies a CVE ID, i don't believe it would ever make sense to include an id or target_ids list. It would obviously be redundant when listing a CVE ID, and providing other types of IDs would likely cause confusion. Referencing another ID should be done at a higher level within the container and shouldn't be specific to SSVC in the case of a CVE. My vote would be to remove these from the CVE Record Format schema implementation of SSVC 1.x and 2.x.

3. The required role property in SSVC 1.x should be removed or made optional within SSVC. The reasoning is that the container itself is form a specific ADP and that identifies the entity and their role. However, i do think we need to investigate adding a similar property at the container level.

4. The namespace in both 1.x and 2.x should probably be limited to SSVC, CVSS, and CISA initially. This will allows us to define the specific decision points that are allowed currently. We should probably avoid custom decision points from custom namespaces until we better understand how producers and consumers will use SSVC.

5. The schemaVersion property appears to be redundant for the 1.x schema. It may also be redundant in the case of 2.x, though i'm unclear on how often the SSVC schema might be updated in the future and whether it makes sense to keep it there. Thoughts?

6. Should each decision point require a version? I don't think we discussed this in much detail in the meeting. Wondering if the version should be optional for a CVE Record. Note that the overall SSVC entry also has a timestamp to reflect changes.

I think those are all of the items i was thinking about. Let me know if you think i missed something from the call yesterday.

Chris