Skip to content

Prioritizing Patch Creation

Here we describe an example decision model for a Supplier deciding the priority of creating a patch for a vulnerability in their software.

Supplier Patch Creation Priority

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 Supplier and the decision is the priority of creating a patch.

Supplier Units of Work

On the input side of the Supplier process, Suppliers typically receive reports of vulnerabilities in one or more versions of their product. Part of the Supplier's task on initial report intake is to resolve the initial report into a set of products and versions that are affected by the reported vulnerability.

Supplier Unit of Work

For the purposes of SSVC, we consider the unit of work for a Supplier to be combination of the vulnerability with each affected product.

Our working assumption is that for SSVC purposes, the supplier's unit of work is the combination of the vulnerability with each affected product. This implies the need for Suppliers to be able to resolve whatever they receive to that level of granularity in order to make best use of SSVC.

Products will often need to be addressed individually because they may have diverse development processes or usage scenarios. There are a variety of ways a Supplier might need to resolve the set of affected products. For example, they might

Independently Fixable Vulnerabilities

Without belaboring the point, these methods are similar to how CVE Numbering Authorities discern “independently fixable vulnerabilities”.

We also note that Software Bill of Materials (SBOM) seems well-placed to aid in that resolution process for the third-party library scenarios.

  • recognize, on further investigation of the initial report, that additional versions of the product are affected
  • discover that other products are affected due to code sharing or programmer error consistent across products
  • receive reports of vulnerabilities in third party libraries they utilize in one or more of their products
  • receive fix bundles for third party libraries used in one or more of their products (where a fix bundle might resolve multiple vulnerabilities or add new features)

In the end, Suppliers provide remediations and/or mitigations for affected products. A supplier-provided remediation is usually a software update which contains fixes for multiple vulnerabilities and, often, new or improved features. Supplier output is relevant because it will become input to Deployers. SSVC focuses only on the remediation in this case; a set of remediations for multiple vulnerabilities is a fix bundle. Suppliers may also produce mitigations, such as recommended configuration changes, to limit the impact of a vulnerability.

Supplier Decision Outcomes

At a basic level, the decision at a software development organization is whether to issue a work order and what resources to expend to remediate a vulnerability in the organization’s software. Prioritization is required because, at least in the current history of software engineering, the effort to patch all known vulnerabilities will exceed available resources. The organization considers several other factors to build the patch; refactoring a large portion of the code base may be necessary for some patches, while others require relatively small changes. We focus only on the priority of building the patch, and we consider four categories of priority, as outlined in the table below.

Patch Supplier Priority

Supplier Priority Description
Defer Do not work on the patch at present.
Scheduled Develop a fix within regularly scheduled maintenance using supplier resources as normal.
Out-of-Cycle Develop mitigation or remediation out-of-cycle, taking resources away from other projects and releasing the fix as a security patch when it is ready.
Immediate Develop and release a fix as quickly as possible, drawing on all available resources, potentially including drawing on or coordinating resources from other parts of the organization.

Supplier Decision Points

The decision to create a patch is based on the following decision points:

  • Exploitation - A vulnerabilty with known exploitation is more likely to be given a higher priority.
  • Utility - The more useful a vulnerability is to an attacker, the more likely it is to be given a higher priority.
  • Technical Impact - The more severe the technical impact of a vulnerability, the more likely it is to be given a higher priority.
  • Public Safety Impact - The more severe the public safety impact of a vulnerability, the more likely it is to be given a higher priority.

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

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

Utility v1.0.1

The Usefulness of the Exploit to the Adversary

Value Definition
Laborious Automatable:No AND Value Density:Diffuse
Efficient (Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)
Super Effective Automatable:Yes AND Value Density:Concentrated
{
  "namespace": "ssvc",
  "version": "1.0.1",
  "schemaVersion": "1-0-1",
  "key": "U",
  "name": "Utility",
  "description": "The Usefulness of the Exploit to the Adversary",
  "values": [
    {
      "key": "L",
      "name": "Laborious",
      "description": "Automatable:No AND Value Density:Diffuse"
    },
    {
      "key": "E",
      "name": "Efficient",
      "description": "(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)"
    },
    {
      "key": "S",
      "name": "Super Effective",
      "description": "Automatable:Yes AND Value Density:Concentrated"
    }
  ]
}

Technical Impact v1.0.0

The technical impact of the vulnerability.

Value Definition
Partial The exploit gives the adversary limited control over, or information exposure about, the behavior of the software that contains the vulnerability. Or the exploit gives the adversary an importantly low stochastic opportunity for total control.
Total The exploit gives the adversary total control over the behavior of the software, or it gives total disclosure of all information on the system that contains the vulnerability.
{
  "namespace": "ssvc",
  "version": "1.0.0",
  "schemaVersion": "1-0-1",
  "key": "TI",
  "name": "Technical Impact",
  "description": "The technical impact of the vulnerability.",
  "values": [
    {
      "key": "P",
      "name": "Partial",
      "description": "The exploit gives the adversary limited control over, or information exposure about, the behavior of the software that contains the vulnerability. Or the exploit gives the adversary an importantly low stochastic opportunity for total control."
    },
    {
      "key": "T",
      "name": "Total",
      "description": "The exploit gives the adversary total control over the behavior of the software, or it gives total disclosure of all information on the system that contains the vulnerability."
    }
  ]
}

Public Safety Impact v2.0.1

A coarse-grained representation of impact to public safety.

Value Definition
Minimal Safety Impact:Negligible
Significant Safety Impact:(Marginal OR Critical OR Catastrophic)
{
  "namespace": "ssvc",
  "version": "2.0.1",
  "schemaVersion": "1-0-1",
  "key": "PSI",
  "name": "Public Safety Impact",
  "description": "A coarse-grained representation of impact to public safety.",
  "values": [
    {
      "key": "M",
      "name": "Minimal",
      "description": "Safety Impact:Negligible"
    },
    {
      "key": "S",
      "name": "Significant",
      "description": "Safety Impact:(Marginal OR Critical OR Catastrophic)"
    }
  ]
}

Public Safety Impact is a notational convenience

The Public Safety Impact decision point is a simplification of the more detailed Safety Impact decision point.

Supplier Decision Model

The example supplier decision model below shows a prioritization policy for the supplier. We display the decision model as a decision tree, which provides a compact representation of the policy, showing the relative priority of different situations.

Tree Notation

Rectangles are decision points, and triangles represent outcomes. The values for each decision point are different, as described above. Outcomes are priority decisions (defer, scheduled, out-of-cycle, immediate). Outcome triangles are color coded:

  • Defer = gray with green outline
  • Scheduled = yellow
  • Out-of-Cycle = orange
  • Immediate = red with black outline

Table of Values

row Exploitation Utility Technical Impact Public-Safety Impact Priority
1 none laborious partial minimal defer
2 none laborious partial significant scheduled
3 none laborious total minimal scheduled
4 none laborious total significant out-of-cycle
5 none efficient partial minimal scheduled
6 none efficient partial significant out-of-cycle
7 none efficient total minimal scheduled
8 none efficient total significant out-of-cycle
9 none super effective partial minimal scheduled
10 none super effective partial significant out-of-cycle
11 none super effective total minimal out-of-cycle
12 none super effective total significant out-of-cycle
13 PoC laborious partial minimal scheduled
14 PoC laborious partial significant out-of-cycle
15 PoC laborious total minimal scheduled
16 PoC laborious total significant immediate
17 PoC efficient partial minimal scheduled
18 PoC efficient partial significant immediate
19 PoC efficient total minimal out-of-cycle
20 PoC efficient total significant immediate
21 PoC super effective partial minimal out-of-cycle
22 PoC super effective partial significant immediate
23 PoC super effective total minimal out-of-cycle
24 PoC super effective total significant immediate
25 active laborious partial minimal out-of-cycle
26 active laborious partial significant immediate
27 active laborious total minimal out-of-cycle
28 active laborious total significant immediate
29 active efficient partial minimal out-of-cycle
30 active efficient partial significant immediate
31 active efficient total minimal out-of-cycle
32 active efficient total significant immediate
33 active super effective partial minimal immediate
34 active super effective partial significant immediate
35 active super effective total minimal immediate
36 active super effective total significant immediate