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 (ssvc:E:1.1.0)

The present state of exploitation of the vulnerability.

Value	Definition
None (N)	There is no evidence of active exploitation and no public proof of concept (PoC) of how to exploit the vulnerability.
Public PoC (P)	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 (A)	Shared, observable, reliable evidence that the exploit is being used in the wild by real attackers; there is credible public reporting.

Exploitation (ssvc:E:1.1.0) JSON Example

{
  "name": "Exploitation",
  "description": "The present state of exploitation of the vulnerability.",
  "namespace": "ssvc",
  "version": "1.1.0",
  "schemaVersion": "1-0-1",
  "key": "E",
  "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 (ssvc:U:1.0.1)

The Usefulness of the Exploit to the Adversary

Value	Definition
Laborious (L)	Automatable:No AND Value Density:Diffuse
Efficient (E)	(Automatable:Yes AND Value Density:Diffuse) OR (Automatable:No AND Value Density:Concentrated)
Super Effective (S)	Automatable:Yes AND Value Density:Concentrated

Utility (ssvc:U:1.0.1) JSON Example

{
  "name": "Utility",
  "description": "The Usefulness of the Exploit to the Adversary",
  "namespace": "ssvc",
  "version": "1.0.1",
  "schemaVersion": "1-0-1",
  "key": "U",
  "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 (ssvc:TI:1.0.0)

The technical impact of the vulnerability.

Value	Definition
Partial (P)	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 (T)	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.

Technical Impact (ssvc:TI:1.0.0) JSON Example

{
  "name": "Technical Impact",
  "description": "The technical impact of the vulnerability.",
  "namespace": "ssvc",
  "version": "1.0.0",
  "schemaVersion": "1-0-1",
  "key": "TI",
  "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 (ssvc:PSI:2.0.1)

A coarse-grained representation of impact to public safety.

Value	Definition
Minimal (M)	Safety Impact:Negligible
Significant (S)	Safety Impact:(Marginal OR Critical OR Catastrophic)

Public Safety Impact (ssvc:PSI:2.0.1) JSON Example

{
  "name": "Public Safety Impact",
  "description": "A coarse-grained representation of impact to public safety.",
  "namespace": "ssvc",
  "version": "2.0.1",
  "schemaVersion": "1-0-1",
  "key": "PSI",
  "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