Skip to content

Coordinator Publication Decision

Coordinators have to make two decisions about publication of information about a vulnerability. The first is whether to coordinate the vulnerability, which we discuss in Coordination Triage. The second decision is whether to publish information about a vulnerability. While other stakeholders may also have to make a publication decision, here we focus on the coordinator's decision.

Coordinator Publication Decision

As noted in Enumerating Decisions, the root of a decision model's identity is the combination of the stakeholder and the decision being modeled. In this case, the stakeholder is the Coordinator and the decision is whether to publish an advisory about the vulnerability.

Policy Constraints and Publication Decisions

Other Stakeholders' Publication Decisions

Other stakeholders may also have to make a publication decision. For example, a supplier may have to decide whether to publish information about a vulnerability in their product. A deployer may have to decide whether to publish information about a vulnerability in their infrastructure. A vulnerability finder may have to decide whether to publish information about a vulnerability they have discovered. Each of these decisions is likely to be different from the coordinator's decision.

The decision to publish information about a vulnerability is a policy choice, and is likely to differ from organization to organization. Two points where CERT/CC policy clearly influences the publication decision are embargo periods and scope.

Publication and Embargo Periods

As a matter of policy, CERT/CC will support an embargo from the public of information about a vulnerability through its choice not to publish that information while a number of conditions hold:

  • A negotiated embargo timer has not expired. The CERT/CC default embargo period is 45 days.
  • Other exceptions have not been met, including active exploitation of the vulnerability in the wild or other public discussion of the vulnerability details.

Regardless, the decision described in this section assumes the embargo period is over, one way or another.

Triage Decisions and Publication

The second point is related to the Coordination Triage Decision and the status of the vulnerability. CERT/CC only expects to publish about vulnerabilities with a coordinate status. While an issue that is tracked or declined may be reevaluated at a later date and status changed to coordinate, unless that happens we would not publish about the vulnerability. Other organizations, such as NVD, would have different publication criteria and may want to include decision points or the decision itself from the Coordination Triage Decision in their publication decision.

Coordinator Publication Units of Work

Coordinator Publication Unit of Work

The unit of work for the coordinator publication decision a single publication. For CERT/CC, this corresponds to a CERT Vulnerability Note.

In the CERT/CC's vulnerability coordination practice, a single report leads to a single coordination case which leads to a single publication. Therefore the unit of work for the publication decision is often the same as the unit of work for the coordination triage decision.

That is sometimes not the case, however. For example, there could be multiple reports of multiple vulnerabilities and the coordinator might choose to publish a single advisory covering all of them if the vulnerabilities are variations on a central theme and have a common set of affected products.

Multiple Reports, Single Advisory

There are numerous examples of multiple reported vulnerabilities being consolidated into a single publication in the CERT/CC's history. A few recent cases include:

  • VU#132380 Vulnerabilities in EDK2 NetworkPkg IP stack implementation.
  • VU#434994 Multiple race conditions due to TOCTOU flaws in various UEFI Implementations
  • VU#811862 Image files in UEFI can be abused to modify boot behavior

Another possibility is that a single report could lead to multiple advisories, for example if the product is a library that is used in multiple other products, and the coordinator chooses to publish separate advisories based on some other criteria.

Single Report, Multiple Advisories

Occasionally, a single report leads to multiple advisories. For example

  • VU#854306 Multiple vulnerabilities in SNMPv1 request handling
  • VU#107186 Multiple vulnerabilities in SNMPv1 trap handling

arrived as a single report and were published as separate vulnerability notes because they affected different aspects of the libraries in question. Although this example pre-dates SSVC by many years, it is illustrative of the situation where a single report leads to multiple advisories.

Coordinator Publication Decision Outcomes

For the CERT/CC, the publication decision is binary: publish or do not publish.

Coordinator Publish Priority

Publish Priority Description
Do not publish Do not publish information about the vulnerability.
Publish Publish information about the vulnerability.

The Publication Decision is Time Sensitive

The publication decision is always a decision at a point in time. As discussed in Guidance on Communicating Results, a SSVC decision may change over time as the inputs to that decision change. A decision to publish cannot be revoked, since the publication is likely to be archived or at least remembered. However, a decision to not publish is a decision not to publish at the time the decision was made. It is not a decision never to publish in the future.

One benefit of encoding the decision process in SSVC is the analysts can all agree on what new information would change the decision and prioritize maintaining awarenss of just those decision points.

CERT/CC Publication Decision Outcomes Over Time

The CERT/CC has a long history of publishing information about vulnerabilities. In the past, the CERT/CC had multiple publication vehicles, including Vulnerability Notes, CERT Advisories, and Current Activity entries. Each of these had different publication criteria. Had we been using SSVC at the time, we might have modeled the publication decision differently for each of these vehicles. Or we might have modeled the decision as a single decision with multiple outcomes, each of which would lead to a different publication vehicle. This is an example of how SSVC can be customized to the needs of the organization using it.

Coordinator Publication Decision Points

The publication decision reuses the Exploitation decision point and adds two new ones (Supplier Involvement and Public Value Added).

  • Supplier Involvement - If the supplier is involved and likely to publish already, there is less need for the CERT/CC to publish.
  • Exploitation - If the vulnerability is being actively exploited, the CERT/CC is more likely to publish.
  • Public Value Added - If there is already significant public discussion of the vulnerability, there might not be much for the CERT/CC to add, making us less likely to publish.

More detail about each of these decision points is provided at the links above, here we provide a brief summary of each.

Supplier Involvement v1.0.0

What is the state of the supplier’s work on addressing the vulnerability?

Value Definition
Fix Ready The supplier has provided a patch or fix.
Cooperative The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time.
Uncooperative/Unresponsive The supplier has not responded, declined to generate a remediation, or no longer exists.
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "schemaVersion": "1-0-1",
  "key": "SI",
  "name": "Supplier Involvement",
  "description": "What is the state of the supplier\u2019s work on addressing the vulnerability?",
  "values": [
    {
      "key": "FR",
      "name": "Fix Ready",
      "description": "The supplier has provided a patch or fix."
    },
    {
      "key": "C",
      "name": "Cooperative",
      "description": "The supplier is actively generating a patch or fix; they may or may not have provided a mitigation or work-around in the mean time."
    },
    {
      "key": "UU",
      "name": "Uncooperative/Unresponsive",
      "description": "The supplier has not responded, declined to generate a remediation, or no longer exists."
    }
  ]
}

Exploitation v1.1.0

The present state of exploitation of the vulnerability.

Value Definition
None There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability.
Public PoC One of the following is true: (1) Typical public PoC exists in sources such as Metasploit or websites like ExploitDB; or (2) the vulnerability has a well-known method of exploitation.
Active Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting.
{
  "namespace": "ssvc",
  "version": "1.1.0",
  "schemaVersion": "1-0-1",
  "key": "E",
  "name": "Exploitation",
  "description": "The present state of exploitation of the vulnerability.",
  "values": [
    {
      "key": "N",
      "name": "None",
      "description": "There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability."
    },
    {
      "key": "P",
      "name": "Public PoC",
      "description": "One of the following is true: (1) Typical public PoC exists in sources such as Metasploit or websites like ExploitDB; or (2) the vulnerability has a well-known method of exploitation."
    },
    {
      "key": "A",
      "name": "Active",
      "description": "Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting."
    }
  ]
}

Public Value Added v1.0.0

How much value would a publication from the coordinator benefit the broader community?

Value Definition
Limited Minimal value added to the existing public information because existing information is already high quality and in multiple outlets.
Ampliative Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc.
Precedence The publication would be the first publicly available, or be coincident with the first publicly available.
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "schemaVersion": "1-0-1",
  "key": "PVA",
  "name": "Public Value Added",
  "description": "How much value would a publication from the coordinator benefit the broader community?",
  "values": [
    {
      "key": "L",
      "name": "Limited",
      "description": "Minimal value added to the existing public information because existing information is already high quality and in multiple outlets."
    },
    {
      "key": "A",
      "name": "Ampliative",
      "description": "Amplifies and/or augments the existing public information about the vulnerability, for example, adds additional detail, addresses or corrects errors in other public information, draws further attention to the vulnerability, etc."
    },
    {
      "key": "P",
      "name": "Precedence",
      "description": "The publication would be the first publicly available, or be coincident with the first publicly available."
    }
  ]
}

Coordinator Publication Decision Model

An example coordinator publication decision model is shown below. The policy described by the model is based on CERT/CC publication decisions. Other organizations may have different publication criteria and may want to include other decision points in their publication decision model.

Table of Values

row Supplier involvement Exploitation Value added Priority
1 fix ready none precedence publish
2 fix ready none ampliative don't publish
3 fix ready none limited don't publish
4 fix ready PoC precedence publish
5 fix ready PoC ampliative don't publish
6 fix ready PoC limited don't publish
7 fix ready active precedence publish
8 fix ready active ampliative publish
9 fix ready active limited don't publish
10 cooperative none precedence publish
11 cooperative none ampliative don't publish
12 cooperative none limited don't publish
13 cooperative PoC precedence publish
14 cooperative PoC ampliative don't publish
15 cooperative PoC limited don't publish
16 cooperative active precedence publish
17 cooperative active ampliative publish
18 cooperative active limited don't publish
19 uncoop/unresponsive none precedence publish
20 uncoop/unresponsive none ampliative don't publish
21 uncoop/unresponsive none limited don't publish
22 uncoop/unresponsive PoC precedence publish
23 uncoop/unresponsive PoC ampliative publish
24 uncoop/unresponsive PoC limited don't publish
25 uncoop/unresponsive active precedence publish
26 uncoop/unresponsive active ampliative publish
27 uncoop/unresponsive active limited publish