From b27d56e7b358c63a657815456739326fe20e1f68 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 12 Mar 2026 16:05:39 -0400 Subject: [PATCH 01/11] resolves #1033: Add SSVC doc explaining "human-scale bottleneck" idea --- docs/howto/ssvc-human-scale-bottleneck.md | 58 +++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 docs/howto/ssvc-human-scale-bottleneck.md diff --git a/docs/howto/ssvc-human-scale-bottleneck.md b/docs/howto/ssvc-human-scale-bottleneck.md new file mode 100644 index 00000000..38fd07f1 --- /dev/null +++ b/docs/howto/ssvc-human-scale-bottleneck.md @@ -0,0 +1,58 @@ +# **SSVC: The Human-Scale Bottleneck in Automated Vulnerability Response** + +As vulnerability response processes become increasingly saturated with automation—from AI-driven data collection to sophisticated analysis—the **Stakeholder-Specific Vulnerability Categorization (SSVC)** model is intentionally designed to serve as a crucial, human-scale bottleneck. This approach ensures that while the process is efficient and automated, the core decision-making remains transparent, accountable, and aligned with organizational risk appetite, providing a necessary bridge between technical data and business policy. + +# **Condensing Complexity into Human-Scale Decisions** + +The initial stages of vulnerability response—data collection and analysis—often involve vast amounts of information, advanced data sharing formats, and powerful analytical tools, increasingly including AI agents and Large Language Models (LLMs). SSVC's core function is to condense this extensive, complex dataset into a small, manageable set of **decision points**. + +These decision points possess several key characteristics that make them suitable for human oversight and policy definition: + +* **Densely Defined and Ordinal:** Each decision point uses values that are ordered (ordinal variables), moving from least likely to most likely to imply action (e.g., Low, Medium, High). This ordering provides a clear, qualitative progression without the mathematical properties of intervals. +* **Orthogonal and Independent:** The chosen decision points capture unique dimensions of the problem. By minimizing conceptual overlap, the model ensures that each dimension contributes independently to the final outcome, keeping the overall decision table compact and easier to reason about. The goal is to have completely independent decision points to reduce ambiguity. +* **Chunky Values:** To prevent the decision space from becoming unmanageable, decision points are limited to a small number of values, typically two to five. This restriction keeps the size of the final decision table small, as the total table size is the product of the value counts for each decision point. + +## **The Decision Table: Policy as Code** + +By defining a set of orthogonal, ordered decision points, SSVC creates a **partial order** over the entire input space—an enumeration of all possible combinations of decision point values. This partial order is then mapped onto a predefined set of **outcome sets** via a **decision table**. + +The decision table serves as the codified organizational policy. The outcomes are also ordered and typically represent service-level expectations (SLEs), priorities (e.g., Low, Medium, Critical), or prescribed actions (e.g., Defer, Scheduled, Out-of-Cycle, Immediate). This mapping of inputs to output values defines the policy. + +Key criteria for the decision table design include: + +| Criterion | Rationale | +| :---- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **Small Size** | Avoids complexity; keeps the number of questions required for analysis minimal (ideally 2-7 inputs, not dozens). Collecting and discriminating between dozens of values comes at an unnecessary cost. | +| **Orthogonal Inputs** | Ensures inputs are independent, reducing ambiguity and overlap. | +| **Chunky Values** | Limiting values per input (2-5) prevents exponential growth of the table size ($3 \times 3 \times 3 = 27$ rows; $4 \times 3 \times 3 \times 3 = 108$ rows). | +| **Understandability** | Decision points must be understandable to non-technical risk owners, focusing on business impact rather than technical specifics (e.g., "Criticality of Affected System" instead of "Buffer Overflow vs. SQL Injection"). | + +## **The Role of the Human in a Machine-Driven World** + +The concept of SSVC as a human-scale bottleneck means that the complexity of the automated threat landscape is filtered through a framework **designed by humans, for humans, and understood by humans**. + +**1\. Accountability and Risk Alignment:** +The decision table provides an explicit, non-ambiguous link between technical vulnerability characteristics and organizational risk appetite. This structure facilitates crucial conversations between technical implementers (responsible for patching) and risk owners (CISO, IT management, senior management), transferring responsibility from technical staff making proxy judgments to risk owners defining explicit policy. + +* **Before SSVC:** Technical staff make proxy judgments based on complex scores (e.g., CVSS 7.6 vs. 5.9), which risk owners often don't fully comprehend. +* **With SSVC:** Decisions are explained using comprehensible terms: "We are responding immediately because this has **High Technical Impact** and affects a **Critical Central Server**. This aligns with our established policy." The risk owner can also explain this policy up to their management. + +**2\. Governance and Policy Refinement:** +The SSVC model is designed for straightforward modification, enabling policy owners to easily adapt their response posture when needed. Changes are typically managed through predictable steps. This process ensures that when a risk owner desires a change, the modification to the policy (the decision table) can be clearly executed and understood. + +| Modification Type | Impact on Table Size and Complexity | +| :---- | :---- | +| **Adjusting Outcome Labels** | Simple fix; maintain existing inputs and values. Requires technical check to ensure partial order causality is maintained (e.g., low-risk inputs cannot have high-priority outcomes). | +| **Adding/Reducing Values** | Small, measurable change. Adding a value increases the table size additively (e.g., $3 \times 3 \times 3 = 27$ to $4 \times 3 \times 3 = 36$). | +| **Adding a Decision Point** | Multiplicative increase in table size (e.g., $3 \times 3 \times 3 = 27$ to $3 \times 3 \times 3 \times 3 = 81$). Requires a more involved policy review. | + +## **SSVC is Not a Process Bottleneck** + +Crucially, SSVC being a "human-scale bottleneck" does **not** mean it forces a human to manually review every decision. The decision table, once defined, is entirely automatable. + +Automation can exist throughout the entire response workflow: + +* **Input Automation:** AI or LLMs can perform the "reading comprehension test" of analyzing raw vulnerability data and mechanically selecting the correct values for the SSVC decision points. +* **Output Automation:** The prioritized outcome from the SSVC table (e.g., "Immediate") can feed directly into automated patching, ticketing, or software fix development systems. + +SSVC acts as a fixed, non-ambiguous interface. The "human scale" element is in the **design and governance** of this interface, ensuring human accountability and understanding of the decision-making logic. The table's fixed structure means there is no ambiguity from a human's understanding standpoint—you know what the output will be based on the defined inputs and policy. It is the locus where technical reality meets organizational policy. The human is in the loop defining the decision space, not necessarily every single decision. \ No newline at end of file From 8b48d446e4f4a5e939e39c5500c5e23987053c87 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 12 Mar 2026 16:13:30 -0400 Subject: [PATCH 02/11] Apply suggestions from code review Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- docs/howto/ssvc-human-scale-bottleneck.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/howto/ssvc-human-scale-bottleneck.md b/docs/howto/ssvc-human-scale-bottleneck.md index 38fd07f1..d445be66 100644 --- a/docs/howto/ssvc-human-scale-bottleneck.md +++ b/docs/howto/ssvc-human-scale-bottleneck.md @@ -2,7 +2,7 @@ As vulnerability response processes become increasingly saturated with automation—from AI-driven data collection to sophisticated analysis—the **Stakeholder-Specific Vulnerability Categorization (SSVC)** model is intentionally designed to serve as a crucial, human-scale bottleneck. This approach ensures that while the process is efficient and automated, the core decision-making remains transparent, accountable, and aligned with organizational risk appetite, providing a necessary bridge between technical data and business policy. -# **Condensing Complexity into Human-Scale Decisions** +## **Condensing Complexity into Human-Scale Decisions** The initial stages of vulnerability response—data collection and analysis—often involve vast amounts of information, advanced data sharing formats, and powerful analytical tools, increasingly including AI agents and Large Language Models (LLMs). SSVC's core function is to condense this extensive, complex dataset into a small, manageable set of **decision points**. @@ -14,7 +14,7 @@ These decision points possess several key characteristics that make them suitabl ## **The Decision Table: Policy as Code** -By defining a set of orthogonal, ordered decision points, SSVC creates a **partial order** over the entire input space—an enumeration of all possible combinations of decision point values. This partial order is then mapped onto a predefined set of **outcome sets** via a **decision table**. +By defining a set of orthogonal, ordered decision points, SSVC induces a **partial order** on the entire input space (the Cartesian product of all decision point values). The resulting ordered set of input combinations is then mapped, via a **decision table**, onto a predefined **outcome set** of ordered outcomes. The decision table serves as the codified organizational policy. The outcomes are also ordered and typically represent service-level expectations (SLEs), priorities (e.g., Low, Medium, Critical), or prescribed actions (e.g., Defer, Scheduled, Out-of-Cycle, Immediate). This mapping of inputs to output values defines the policy. From 304a59b144f9508f7c3a31cd32e5fd1f22c4d694 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 12 Mar 2026 16:28:55 -0400 Subject: [PATCH 03/11] add ssvc human scale bottleneck page to nav --- mkdocs.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/mkdocs.yml b/mkdocs.yml index 50276ec9..65ee8318 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -43,6 +43,7 @@ nav: - Value Density: 'howto/gathering_info/value_density.md' - Customizing SSVC: 'howto/tree_customization.md' - Acuity Ramp: 'howto/acuity_ramp.md' + - SSVC as a Human-Scale Bottleneck: 'howto/ssvc-human-scale-bottleneck.md' - Using EPSS with SSVC: - 'howto/using_epss/index.md' - EPSS Probability as input to Exploitation: 'howto/using_epss/epss_probability.md' From b2e7af7632ad6bf5da9011f69677d79e40647053 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 12 Mar 2026 16:30:32 -0400 Subject: [PATCH 04/11] markdownlint --fix --- docs/howto/ssvc-human-scale-bottleneck.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/howto/ssvc-human-scale-bottleneck.md b/docs/howto/ssvc-human-scale-bottleneck.md index d445be66..d43c10f1 100644 --- a/docs/howto/ssvc-human-scale-bottleneck.md +++ b/docs/howto/ssvc-human-scale-bottleneck.md @@ -8,9 +8,9 @@ The initial stages of vulnerability response—data collection and analysis—of These decision points possess several key characteristics that make them suitable for human oversight and policy definition: -* **Densely Defined and Ordinal:** Each decision point uses values that are ordered (ordinal variables), moving from least likely to most likely to imply action (e.g., Low, Medium, High). This ordering provides a clear, qualitative progression without the mathematical properties of intervals. -* **Orthogonal and Independent:** The chosen decision points capture unique dimensions of the problem. By minimizing conceptual overlap, the model ensures that each dimension contributes independently to the final outcome, keeping the overall decision table compact and easier to reason about. The goal is to have completely independent decision points to reduce ambiguity. -* **Chunky Values:** To prevent the decision space from becoming unmanageable, decision points are limited to a small number of values, typically two to five. This restriction keeps the size of the final decision table small, as the total table size is the product of the value counts for each decision point. +- **Densely Defined and Ordinal:** Each decision point uses values that are ordered (ordinal variables), moving from least likely to most likely to imply action (e.g., Low, Medium, High). This ordering provides a clear, qualitative progression without the mathematical properties of intervals. +- **Orthogonal and Independent:** The chosen decision points capture unique dimensions of the problem. By minimizing conceptual overlap, the model ensures that each dimension contributes independently to the final outcome, keeping the overall decision table compact and easier to reason about. The goal is to have completely independent decision points to reduce ambiguity. +- **Chunky Values:** To prevent the decision space from becoming unmanageable, decision points are limited to a small number of values, typically two to five. This restriction keeps the size of the final decision table small, as the total table size is the product of the value counts for each decision point. ## **The Decision Table: Policy as Code** @@ -34,8 +34,8 @@ The concept of SSVC as a human-scale bottleneck means that the complexity of the **1\. Accountability and Risk Alignment:** The decision table provides an explicit, non-ambiguous link between technical vulnerability characteristics and organizational risk appetite. This structure facilitates crucial conversations between technical implementers (responsible for patching) and risk owners (CISO, IT management, senior management), transferring responsibility from technical staff making proxy judgments to risk owners defining explicit policy. -* **Before SSVC:** Technical staff make proxy judgments based on complex scores (e.g., CVSS 7.6 vs. 5.9), which risk owners often don't fully comprehend. -* **With SSVC:** Decisions are explained using comprehensible terms: "We are responding immediately because this has **High Technical Impact** and affects a **Critical Central Server**. This aligns with our established policy." The risk owner can also explain this policy up to their management. +- **Before SSVC:** Technical staff make proxy judgments based on complex scores (e.g., CVSS 7.6 vs. 5.9), which risk owners often don't fully comprehend. +- **With SSVC:** Decisions are explained using comprehensible terms: "We are responding immediately because this has **High Technical Impact** and affects a **Critical Central Server**. This aligns with our established policy." The risk owner can also explain this policy up to their management. **2\. Governance and Policy Refinement:** The SSVC model is designed for straightforward modification, enabling policy owners to easily adapt their response posture when needed. Changes are typically managed through predictable steps. This process ensures that when a risk owner desires a change, the modification to the policy (the decision table) can be clearly executed and understood. @@ -52,7 +52,7 @@ Crucially, SSVC being a "human-scale bottleneck" does **not** mean it forces a h Automation can exist throughout the entire response workflow: -* **Input Automation:** AI or LLMs can perform the "reading comprehension test" of analyzing raw vulnerability data and mechanically selecting the correct values for the SSVC decision points. -* **Output Automation:** The prioritized outcome from the SSVC table (e.g., "Immediate") can feed directly into automated patching, ticketing, or software fix development systems. +- **Input Automation:** AI or LLMs can perform the "reading comprehension test" of analyzing raw vulnerability data and mechanically selecting the correct values for the SSVC decision points. +- **Output Automation:** The prioritized outcome from the SSVC table (e.g., "Immediate") can feed directly into automated patching, ticketing, or software fix development systems. -SSVC acts as a fixed, non-ambiguous interface. The "human scale" element is in the **design and governance** of this interface, ensuring human accountability and understanding of the decision-making logic. The table's fixed structure means there is no ambiguity from a human's understanding standpoint—you know what the output will be based on the defined inputs and policy. It is the locus where technical reality meets organizational policy. The human is in the loop defining the decision space, not necessarily every single decision. \ No newline at end of file +SSVC acts as a fixed, non-ambiguous interface. The "human scale" element is in the **design and governance** of this interface, ensuring human accountability and understanding of the decision-making logic. The table's fixed structure means there is no ambiguity from a human's understanding standpoint—you know what the output will be based on the defined inputs and policy. It is the locus where technical reality meets organizational policy. The human is in the loop defining the decision space, not necessarily every single decision. From cdc25c24238792467704517b465f20e69d00bf44 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 12 Mar 2026 16:31:56 -0400 Subject: [PATCH 05/11] wording --- docs/howto/ssvc-human-scale-bottleneck.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/howto/ssvc-human-scale-bottleneck.md b/docs/howto/ssvc-human-scale-bottleneck.md index d43c10f1..bb87682a 100644 --- a/docs/howto/ssvc-human-scale-bottleneck.md +++ b/docs/howto/ssvc-human-scale-bottleneck.md @@ -32,7 +32,7 @@ Key criteria for the decision table design include: The concept of SSVC as a human-scale bottleneck means that the complexity of the automated threat landscape is filtered through a framework **designed by humans, for humans, and understood by humans**. **1\. Accountability and Risk Alignment:** -The decision table provides an explicit, non-ambiguous link between technical vulnerability characteristics and organizational risk appetite. This structure facilitates crucial conversations between technical implementers (responsible for patching) and risk owners (CISO, IT management, senior management), transferring responsibility from technical staff making proxy judgments to risk owners defining explicit policy. +The decision table provides an explicit, unambiguous link between technical vulnerability characteristics and organizational risk appetite. This structure facilitates crucial conversations between technical implementers (responsible for patching) and risk owners (CISO, IT management, senior management), transferring responsibility from technical staff making proxy judgments to risk owners defining explicit policy. - **Before SSVC:** Technical staff make proxy judgments based on complex scores (e.g., CVSS 7.6 vs. 5.9), which risk owners often don't fully comprehend. - **With SSVC:** Decisions are explained using comprehensible terms: "We are responding immediately because this has **High Technical Impact** and affects a **Critical Central Server**. This aligns with our established policy." The risk owner can also explain this policy up to their management. @@ -55,4 +55,4 @@ Automation can exist throughout the entire response workflow: - **Input Automation:** AI or LLMs can perform the "reading comprehension test" of analyzing raw vulnerability data and mechanically selecting the correct values for the SSVC decision points. - **Output Automation:** The prioritized outcome from the SSVC table (e.g., "Immediate") can feed directly into automated patching, ticketing, or software fix development systems. -SSVC acts as a fixed, non-ambiguous interface. The "human scale" element is in the **design and governance** of this interface, ensuring human accountability and understanding of the decision-making logic. The table's fixed structure means there is no ambiguity from a human's understanding standpoint—you know what the output will be based on the defined inputs and policy. It is the locus where technical reality meets organizational policy. The human is in the loop defining the decision space, not necessarily every single decision. +SSVC acts as a fixed, unambiguous interface. The "human scale" element is in the **design and governance** of this interface, ensuring human accountability and understanding of the decision-making logic. The table's fixed structure means there is no ambiguity from a human's understanding standpoint—you know what the output will be based on the defined inputs and policy. It is the locus where technical reality meets organizational policy. The human is in the loop defining the decision space, not necessarily every single decision. From 8eac5474314df133ae50d36f3dab1520ab5b1a10 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 12 Mar 2026 16:43:52 -0400 Subject: [PATCH 06/11] add diagram and links to other pages --- docs/howto/ssvc-human-scale-bottleneck.md | 51 +++++++++++++++++++++-- 1 file changed, 48 insertions(+), 3 deletions(-) diff --git a/docs/howto/ssvc-human-scale-bottleneck.md b/docs/howto/ssvc-human-scale-bottleneck.md index bb87682a..741eff26 100644 --- a/docs/howto/ssvc-human-scale-bottleneck.md +++ b/docs/howto/ssvc-human-scale-bottleneck.md @@ -2,9 +2,34 @@ As vulnerability response processes become increasingly saturated with automation—from AI-driven data collection to sophisticated analysis—the **Stakeholder-Specific Vulnerability Categorization (SSVC)** model is intentionally designed to serve as a crucial, human-scale bottleneck. This approach ensures that while the process is efficient and automated, the core decision-making remains transparent, accountable, and aligned with organizational risk appetite, providing a necessary bridge between technical data and business policy. +```mermaid +flowchart LR + +subgraph dm[Data Mapping] + collect[Collect Lots of Data] +end +subgraph ssvc[SSVC
Human-Scale] + dps[SSVC Decision Points] + model[SSVC Decision Table] +end +subgraph use[Respond] + apply[Decisions] +end +gov[Governance
Human-Scale] +collect -->|maps
onto| dps +dps -->|input to| model +model -->|defines| apply +gov -->|refines| ssvc +use -->|informs| gov +``` + +On the left, [Data Mapping](bootstrap/collect.md) funnels large-scale data collection into the small set of SSVC decision points. +On the right, [Use & Respond](bootstrap/use.md) fans the model's outputs out into operational decisions at scale. +SSVC sits in the middle as the human-scale interface where organizational policy is defined and refined. + ## **Condensing Complexity into Human-Scale Decisions** -The initial stages of vulnerability response—data collection and analysis—often involve vast amounts of information, advanced data sharing formats, and powerful analytical tools, increasingly including AI agents and Large Language Models (LLMs). SSVC's core function is to condense this extensive, complex dataset into a small, manageable set of **decision points**. +The initial stages of vulnerability response—[data collection and mapping](bootstrap/collect.md)—often involve vast amounts of information, advanced data sharing formats, and powerful analytical tools, increasingly including AI agents and Large Language Models (LLMs). SSVC's core function is to condense this extensive, complex dataset into a small, manageable set of **decision points**. These decision points possess several key characteristics that make them suitable for human oversight and policy definition: @@ -40,19 +65,39 @@ The decision table provides an explicit, unambiguous link between technical vuln **2\. Governance and Policy Refinement:** The SSVC model is designed for straightforward modification, enabling policy owners to easily adapt their response posture when needed. Changes are typically managed through predictable steps. This process ensures that when a risk owner desires a change, the modification to the policy (the decision table) can be clearly executed and understood. +The SSVC governance loop—described in detail in the [Prepare](bootstrap/prepare.md#establish-governance) step of the Getting Started guide—is what makes this refinement practical. Because the decision table is small and explicit, conversations about policy changes stay grounded: + +> *"Why did we respond that way?"* +> *"Because conditions A, B, and C were all met."* +> *"I think we should have responded differently in that case."* +> *"Should we add a new condition D to every decision, or just re-label the outcome for the row where (A, B, C) applies?"* + +This kind of structured conversation is exactly what SSVC is designed to enable. A lightweight governance process periodically reviews each element of the model: + +- Are the **outcomes** still relevant to the organization? +- Are the **decision points** capturing the right dimensions of the problem? +- Does the **decision table** still reflect how the organization wants to make decisions? + - Have there been cases where the table led to a decision that was later regretted? + - Are there new constraints or requirements not yet captured? +- Is the **[data mapping](bootstrap/collect.md)** still appropriate—are the right data sources being used to assign values to decision points? + +Depending on the review, adjustments can be made to any layer of the model. The impact of those adjustments is predictable: + | Modification Type | Impact on Table Size and Complexity | | :---- | :---- | | **Adjusting Outcome Labels** | Simple fix; maintain existing inputs and values. Requires technical check to ensure partial order causality is maintained (e.g., low-risk inputs cannot have high-priority outcomes). | | **Adding/Reducing Values** | Small, measurable change. Adding a value increases the table size additively (e.g., $3 \times 3 \times 3 = 27$ to $4 \times 3 \times 3 = 36$). | | **Adding a Decision Point** | Multiplicative increase in table size (e.g., $3 \times 3 \times 3 = 27$ to $3 \times 3 \times 3 \times 3 = 81$). Requires a more involved policy review. | +Crucially, governance should involve the right stakeholders. Risk owners must be involved in reviewing and adjusting the decision table itself, while vulnerability management and IT security teams are best positioned to review the data mapping and decision point definitions. Operational feedback from [Use & Respond](bootstrap/use.md) provides the empirical basis for identifying where the model needs refinement. + ## **SSVC is Not a Process Bottleneck** Crucially, SSVC being a "human-scale bottleneck" does **not** mean it forces a human to manually review every decision. The decision table, once defined, is entirely automatable. Automation can exist throughout the entire response workflow: -- **Input Automation:** AI or LLMs can perform the "reading comprehension test" of analyzing raw vulnerability data and mechanically selecting the correct values for the SSVC decision points. -- **Output Automation:** The prioritized outcome from the SSVC table (e.g., "Immediate") can feed directly into automated patching, ticketing, or software fix development systems. +- **Input Automation:** AI or LLMs can perform the "reading comprehension test" of analyzing raw vulnerability data and mechanically selecting the correct values for the SSVC decision points. See [Data Mapping](bootstrap/collect.md) for how to connect data sources to decision point values. +- **Output Automation:** The prioritized outcome from the SSVC table (e.g., "Immediate") can feed directly into automated patching, ticketing, or software fix development systems. See [Use & Respond](bootstrap/use.md) for how to operationalize SSVC outcomes at scale. SSVC acts as a fixed, unambiguous interface. The "human scale" element is in the **design and governance** of this interface, ensuring human accountability and understanding of the decision-making logic. The table's fixed structure means there is no ambiguity from a human's understanding standpoint—you know what the output will be based on the defined inputs and policy. It is the locus where technical reality meets organizational policy. The human is in the loop defining the decision space, not necessarily every single decision. From 590777311284508f4d06f98cbe02a707031fc45d Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Thu, 12 Mar 2026 19:37:21 -0400 Subject: [PATCH 07/11] refine diagram --- docs/howto/ssvc-human-scale-bottleneck.md | 31 ++++++++++++++++------- 1 file changed, 22 insertions(+), 9 deletions(-) diff --git a/docs/howto/ssvc-human-scale-bottleneck.md b/docs/howto/ssvc-human-scale-bottleneck.md index 741eff26..f7f393d2 100644 --- a/docs/howto/ssvc-human-scale-bottleneck.md +++ b/docs/howto/ssvc-human-scale-bottleneck.md @@ -3,28 +3,41 @@ As vulnerability response processes become increasingly saturated with automation—from AI-driven data collection to sophisticated analysis—the **Stakeholder-Specific Vulnerability Categorization (SSVC)** model is intentionally designed to serve as a crucial, human-scale bottleneck. This approach ensures that while the process is efficient and automated, the core decision-making remains transparent, accountable, and aligned with organizational risk appetite, providing a necessary bridge between technical data and business policy. ```mermaid +--- +title: SSVC as the Human-Scale Bottleneck in Vulnerability Response +--- flowchart LR -subgraph dm[Data Mapping] +subgraph dc[Data Mapping] collect[Collect Lots of Data] end -subgraph ssvc[SSVC
Human-Scale] +subgraph ssvc[SSVC operates at human-scale] + subgraph ssvcdt[Decision Model] dps[SSVC Decision Points] model[SSVC Decision Table] + end + gov[Governance] end -subgraph use[Respond] +subgraph use[Use & Respond] apply[Decisions] + do[Actions] + effects[Results] end -gov[Governance
Human-Scale] -collect -->|maps
onto| dps dps -->|input to| model model -->|defines| apply -gov -->|refines| ssvc -use -->|informs| gov +apply -->|lead to| do +do -->|produce| effects +dc -->|informs| dps +effects -->|informs| gov +gov -->|refines| ssvcdt +gov -->|refines| dc ``` -On the left, [Data Mapping](bootstrap/collect.md) funnels large-scale data collection into the small set of SSVC decision points. -On the right, [Use & Respond](bootstrap/use.md) fans the model's outputs out into operational decisions at scale. +On the input side, [Data Mapping](bootstrap/collect.md) funnels large-scale +data +collection into the small set of SSVC decision points. +On the output side, [Use & Respond](bootstrap/use.md) fans the model's outputs +out into operational decisions at scale. SSVC sits in the middle as the human-scale interface where organizational policy is defined and refined. ## **Condensing Complexity into Human-Scale Decisions** From 427f4e0ab2f362babf4a5b19758ad079c0e310e6 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Mon, 30 Mar 2026 15:03:01 -0400 Subject: [PATCH 08/11] revise ssvc-human-scale-bottleneck.md --- docs/howto/ssvc-human-scale-bottleneck.md | 230 +++++++++++++++------- 1 file changed, 157 insertions(+), 73 deletions(-) diff --git a/docs/howto/ssvc-human-scale-bottleneck.md b/docs/howto/ssvc-human-scale-bottleneck.md index f7f393d2..5480bff7 100644 --- a/docs/howto/ssvc-human-scale-bottleneck.md +++ b/docs/howto/ssvc-human-scale-bottleneck.md @@ -1,116 +1,200 @@ # **SSVC: The Human-Scale Bottleneck in Automated Vulnerability Response** -As vulnerability response processes become increasingly saturated with automation—from AI-driven data collection to sophisticated analysis—the **Stakeholder-Specific Vulnerability Categorization (SSVC)** model is intentionally designed to serve as a crucial, human-scale bottleneck. This approach ensures that while the process is efficient and automated, the core decision-making remains transparent, accountable, and aligned with organizational risk appetite, providing a necessary bridge between technical data and business policy. +The *Stakeholder-Specific Vulnerability Categorization (SSVC)** +framework is designed to provide a human-scale decision bottleneck in the +vulnerability response process. ```mermaid --- title: SSVC as the Human-Scale Bottleneck in Vulnerability Response --- flowchart LR - -subgraph dc[Data Mapping] - collect[Collect Lots of Data] -end -subgraph ssvc[SSVC operates at human-scale] - subgraph ssvcdt[Decision Model] - dps[SSVC Decision Points] - model[SSVC Decision Table] + subgraph dc[Data Mapping] + collect[Collect Lots of Data] + end + subgraph ssvc[SSVC operates at human-scale] + subgraph ssvcdt[Decision Model] + dps[SSVC Decision Points] + model[SSVC Decision Table] + end + gov[Governance] + end + subgraph use[Use & Respond] + apply[Decisions] + do[Actions] + effects[Results] end - gov[Governance] -end -subgraph use[Use & Respond] - apply[Decisions] - do[Actions] - effects[Results] -end -dps -->|input to| model -model -->|defines| apply -apply -->|lead to| do -do -->|produce| effects -dc -->|informs| dps -effects -->|informs| gov -gov -->|refines| ssvcdt -gov -->|refines| dc + dps -->|input to| model + model -->|defines| apply + apply -->|lead to| do + do -->|produce| effects + dc -->|informs| dps + effects -->|informs| gov + gov -->|refines| ssvcdt + gov -->|refines| dc ``` - -On the input side, [Data Mapping](bootstrap/collect.md) funnels large-scale -data +Vulnerability response is increasingly driven by automation. +On the input side, [Data Mapping](bootstrap/collect.md) funnels large-scale +data collection into the small set of SSVC decision points. -On the output side, [Use & Respond](bootstrap/use.md) fans the model's outputs +On the output side, [Use & Respond](bootstrap/use.md) fans the model's outputs out into operational decisions at scale. -SSVC sits in the middle as the human-scale interface where organizational policy is defined and refined. +SSVC sits in the middle as the human-scale interface where organizational policy +is defined and refined into decision support tools that can be automated. +This approach ensures that while the process is efficient and automated, the +core decision-making remains transparent, accountable, and aligned with +organizational risk appetite, providing a necessary bridge between technical +data and business policy. ## **Condensing Complexity into Human-Scale Decisions** -The initial stages of vulnerability response—[data collection and mapping](bootstrap/collect.md)—often involve vast amounts of information, advanced data sharing formats, and powerful analytical tools, increasingly including AI agents and Large Language Models (LLMs). SSVC's core function is to condense this extensive, complex dataset into a small, manageable set of **decision points**. - -These decision points possess several key characteristics that make them suitable for human oversight and policy definition: - -- **Densely Defined and Ordinal:** Each decision point uses values that are ordered (ordinal variables), moving from least likely to most likely to imply action (e.g., Low, Medium, High). This ordering provides a clear, qualitative progression without the mathematical properties of intervals. -- **Orthogonal and Independent:** The chosen decision points capture unique dimensions of the problem. By minimizing conceptual overlap, the model ensures that each dimension contributes independently to the final outcome, keeping the overall decision table compact and easier to reason about. The goal is to have completely independent decision points to reduce ambiguity. -- **Chunky Values:** To prevent the decision space from becoming unmanageable, decision points are limited to a small number of values, typically two to five. This restriction keeps the size of the final decision table small, as the total table size is the product of the value counts for each decision point. +The initial stages of vulnerability +response—[data collection and mapping](bootstrap/collect.md)—often involve large +amounts of information, various data sharing formats (e.g., [CSAF](https://www. +csaf. +io/), [CVE JSON](https://cveproject.github.io/cve-schema/schema/docs/)), and +diverse analytical tools, increasingly including AI features like Large +Language Models (LLMs). SSVC's +core function is to condense this extensive, complex dataset into a small, +manageable set of [decision points](/reference/decision_points/index.md). + +These decision points possess several key characteristics that make them +suitable for human oversight and policy definition: + +- **Densely Defined and Ordinal:** Each decision point uses values that are + ordered (ordinal variables), moving from least likely to most likely to imply + action (e.g., Low, Medium, High). This ordering provides a clear, qualitative + progression without the mathematical properties of intervals. +- **Orthogonal and Independent:** The chosen decision points capture unique + dimensions of the problem. By minimizing conceptual overlap, the model ensures + that each dimension contributes independently to the final outcome, keeping + the overall decision table compact and easier to reason about. The goal is to + have completely independent decision points to reduce ambiguity. +- **Chunky Values:** To prevent the decision space from becoming unmanageable, + decision points are limited to a small number of values, typically two to + five. This restriction keeps the size of the final decision table small, as + the total table size is the product of the value counts for each decision + point. ## **The Decision Table: Policy as Code** -By defining a set of orthogonal, ordered decision points, SSVC induces a **partial order** on the entire input space (the Cartesian product of all decision point values). The resulting ordered set of input combinations is then mapped, via a **decision table**, onto a predefined **outcome set** of ordered outcomes. +By defining a set of orthogonal, ordered decision points, SSVC induces a +*partial order* on the entire input space (the Cartesian product of all +decision point values). The resulting ordered set of input combinations is then +mapped, via a [decision table](/topics/decision_trees.md), onto a predefined +[outcome set](/reference/decision_points/outcomes) of ordered +outcomes. -The decision table serves as the codified organizational policy. The outcomes are also ordered and typically represent service-level expectations (SLEs), priorities (e.g., Low, Medium, Critical), or prescribed actions (e.g., Defer, Scheduled, Out-of-Cycle, Immediate). This mapping of inputs to output values defines the policy. +The decision table serves as the codified organizational policy. The outcomes +are also ordered and typically represent service-level expectations (SLEs), +priorities (e.g., Low, Medium, Critical), or prescribed actions (e.g., Defer, +Scheduled, Out-of-Cycle, Immediate). This mapping of inputs to output values +defines the policy. Key criteria for the decision table design include: -| Criterion | Rationale | -| :---- |:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| **Small Size** | Avoids complexity; keeps the number of questions required for analysis minimal (ideally 2-7 inputs, not dozens). Collecting and discriminating between dozens of values comes at an unnecessary cost. | +| Criterion | Rationale | +|:----------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| **Small Size** | Avoids complexity; keeps the number of questions required for analysis minimal (ideally 2-7 inputs, not dozens). Collecting and discriminating between dozens of values comes at an unnecessary cost. | | **Orthogonal Inputs** | Ensures inputs are independent, reducing ambiguity and overlap. | -| **Chunky Values** | Limiting values per input (2-5) prevents exponential growth of the table size ($3 \times 3 \times 3 = 27$ rows; $4 \times 3 \times 3 \times 3 = 108$ rows). | +| **Chunky Values** | Limiting values per input (2-5) prevents exponential growth of the table size ($3 \times 3 \times 3 = 27$ rows; $4 \times 3 \times 3 \times 3 = 108$ rows). | | **Understandability** | Decision points must be understandable to non-technical risk owners, focusing on business impact rather than technical specifics (e.g., "Criticality of Affected System" instead of "Buffer Overflow vs. SQL Injection"). | -## **The Role of the Human in a Machine-Driven World** +## The Role of the Human in a Machine-Driven World -The concept of SSVC as a human-scale bottleneck means that the complexity of the automated threat landscape is filtered through a framework **designed by humans, for humans, and understood by humans**. +The concept of SSVC as a human-scale bottleneck means that the complexity of the +automated threat landscape is filtered through a framework designed by humans, +for humans, and understood by humans. -**1\. Accountability and Risk Alignment:** -The decision table provides an explicit, unambiguous link between technical vulnerability characteristics and organizational risk appetite. This structure facilitates crucial conversations between technical implementers (responsible for patching) and risk owners (CISO, IT management, senior management), transferring responsibility from technical staff making proxy judgments to risk owners defining explicit policy. +### Accountability and Risk Alignment -- **Before SSVC:** Technical staff make proxy judgments based on complex scores (e.g., CVSS 7.6 vs. 5.9), which risk owners often don't fully comprehend. -- **With SSVC:** Decisions are explained using comprehensible terms: "We are responding immediately because this has **High Technical Impact** and affects a **Critical Central Server**. This aligns with our established policy." The risk owner can also explain this policy up to their management. +The decision table provides an explicit, unambiguous link between technical +vulnerability characteristics and organizational risk appetite. This structure +facilitates crucial conversations between technical staff—who are responsible +for developing or deploying mitigations and fixes—and risk owners +(CISO, IT management, senior management), +transferring responsibility from technical staff making proxy judgments to risk +owners defining explicit policy. -**2\. Governance and Policy Refinement:** -The SSVC model is designed for straightforward modification, enabling policy owners to easily adapt their response posture when needed. Changes are typically managed through predictable steps. This process ensures that when a risk owner desires a change, the modification to the policy (the decision table) can be clearly executed and understood. +- **Before SSVC:** Technical staff make proxy judgments based on complex + scores (e.g., CVSS 7.6 vs. 5.9), which risk owners often don't fully + comprehend. +- **With SSVC:** Decisions are explained using comprehensible terms: "We are + responding immediately because this has **High Technical Impact** and affects + a **Critical Central Server**. This aligns with our established policy." The + risk owner can also explain this policy up to their management. -The SSVC governance loop—described in detail in the [Prepare](bootstrap/prepare.md#establish-governance) step of the Getting Started guide—is what makes this refinement practical. Because the decision table is small and explicit, conversations about policy changes stay grounded: +### Governance and Policy Refinement -> *"Why did we respond that way?"* -> *"Because conditions A, B, and C were all met."* -> *"I think we should have responded differently in that case."* -> *"Should we add a new condition D to every decision, or just re-label the outcome for the row where (A, B, C) applies?"* +SSVC is designed for straightforward modification, enabling +policy owners to easily adapt their response posture when needed. Changes +can be managed through predictable steps. This process ensures that when a risk owner +desires a change, the modification to the decision table can be +clearly executed and understood. -This kind of structured conversation is exactly what SSVC is designed to enable. A lightweight governance process periodically reviews each element of the model: +The SSVC governance process—described in detail in +the [Prepare](bootstrap/prepare.md#establish-governance) step of the Getting +Started guide—is what makes this refinement practical. Because the decision +table is small and explicit, conversations about policy changes stay grounded: -- Are the **outcomes** still relevant to the organization? -- Are the **decision points** capturing the right dimensions of the problem? -- Does the **decision table** still reflect how the organization wants to make decisions? - - Have there been cases where the table led to a decision that was later regretted? +> *"Why did we respond that way?"* +> "Because conditions A, B, and C were all met." +> *"I think we should have responded differently in that case."* +> "Should we add a new condition D to every decision, or just re-label the +outcome for the row where (A, B, C) applies?" + +This kind of structured conversation is exactly what SSVC is designed to enable. +A lightweight governance process periodically reviews each element of the model: + +- Are the *outcomes* still relevant to the organization? +- Are the *decision points* capturing the right dimensions of the problem? +- Does the *decision table* still reflect how the organization wants to make + decisions? + - Have there been cases where the table led to a decision that was later + regretted? - Are there new constraints or requirements not yet captured? -- Is the **[data mapping](bootstrap/collect.md)** still appropriate—are the right data sources being used to assign values to decision points? +- Is the [data mapping](bootstrap/prepare.md) still appropriate—are the + right data sources being used to assign values to decision points? -Depending on the review, adjustments can be made to any layer of the model. The impact of those adjustments is predictable: +Depending on the review, adjustments can be made to any layer of the model. The +impact of those adjustments is predictable: -| Modification Type | Impact on Table Size and Complexity | -| :---- | :---- | +| Modification Type | Impact on Table Size and Complexity | +|:-----------------------------|:--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | **Adjusting Outcome Labels** | Simple fix; maintain existing inputs and values. Requires technical check to ensure partial order causality is maintained (e.g., low-risk inputs cannot have high-priority outcomes). | -| **Adding/Reducing Values** | Small, measurable change. Adding a value increases the table size additively (e.g., $3 \times 3 \times 3 = 27$ to $4 \times 3 \times 3 = 36$). | -| **Adding a Decision Point** | Multiplicative increase in table size (e.g., $3 \times 3 \times 3 = 27$ to $3 \times 3 \times 3 \times 3 = 81$). Requires a more involved policy review. | +| **Adding/Reducing Values** | Small, measurable change. Adding a value increases the table size additively (e.g., $3 \times 3 \times 3 = 27$ to $4 \times 3 \times 3 = 36$). | +| **Adding a Decision Point** | Multiplicative increase in table size (e.g., $3 \times 3 \times 3 = 27$ to $3 \times 3 \times 3 \times 3 = 81$). Requires a more involved policy review. | -Crucially, governance should involve the right stakeholders. Risk owners must be involved in reviewing and adjusting the decision table itself, while vulnerability management and IT security teams are best positioned to review the data mapping and decision point definitions. Operational feedback from [Use & Respond](bootstrap/use.md) provides the empirical basis for identifying where the model needs refinement. +Crucially, governance should involve the right stakeholders. Risk owners must be +involved in reviewing and adjusting the decision table itself, while +vulnerability management and IT security teams are best positioned to review the +data mapping and decision point definitions. Operational feedback +from observing [Use & Respond](bootstrap/use.md) provides the empirical +basis for +identifying where the model needs refinement. -## **SSVC is Not a Process Bottleneck** +## SSVC is Not a Process Bottleneck -Crucially, SSVC being a "human-scale bottleneck" does **not** mean it forces a human to manually review every decision. The decision table, once defined, is entirely automatable. +Crucially, SSVC being a "human-scale bottleneck" does **not** mean it forces a +human to manually review every decision. The decision table, once defined, is +entirely automatable. Automation can exist throughout the entire response workflow: -- **Input Automation:** AI or LLMs can perform the "reading comprehension test" of analyzing raw vulnerability data and mechanically selecting the correct values for the SSVC decision points. See [Data Mapping](bootstrap/collect.md) for how to connect data sources to decision point values. -- **Output Automation:** The prioritized outcome from the SSVC table (e.g., "Immediate") can feed directly into automated patching, ticketing, or software fix development systems. See [Use & Respond](bootstrap/use.md) for how to operationalize SSVC outcomes at scale. - -SSVC acts as a fixed, unambiguous interface. The "human scale" element is in the **design and governance** of this interface, ensuring human accountability and understanding of the decision-making logic. The table's fixed structure means there is no ambiguity from a human's understanding standpoint—you know what the output will be based on the defined inputs and policy. It is the locus where technical reality meets organizational policy. The human is in the loop defining the decision space, not necessarily every single decision. +- **Input Automation:** AI (e.g., an LLM) can perform the "reading + comprehension test" + of analyzing raw vulnerability data and mechanically selecting the correct + values for the SSVC decision points. See [Data Mapping](bootstrap/collect.md) + for how to connect data sources to decision point values. +- **Output Automation:** The prioritized outcome from the SSVC table (e.g., " + Immediate") can feed directly into automated patching, ticketing, or software + fix development systems. See [Use & Respond](bootstrap/use.md) for how to + operationalize SSVC outcomes at scale. + +SSVC acts as a fixed, unambiguous interface. The "human scale" element is in the +*design and governance* of this interface, ensuring human accountability and +understanding of the decision-making logic. The table's fixed structure means +there is no ambiguity—you know what the +output will be based on the defined inputs and policy. It is the locus where +technical reality meets organizational policy. The human is in the loop defining +the decision space, not necessarily making every single decision. From 49b1af348828a40ba5eb547fb39d9688ba45931f Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Mon, 30 Mar 2026 15:15:49 -0400 Subject: [PATCH 09/11] Address unresolved reviewer comments on PR #1087 - Move file from docs/howto/ to docs/topics/ (parallels decision_points_as_bricks.md, addresses Diataxis how-to vs. explanation concern) - Update mkdocs.yml nav: remove from howto, add to topics alongside decision_points_as_bricks.md - Fix intro: add 'designed by humans, for humans' thesis and 'not a process bottleneck' clarification at top of document (threads at lines 68, 107) - Add diagram scope clarification: make explicit that Decision Model = SSVC scope, Data Mapping and Use & Respond are adjacent but outside scope (thread at line 36) - Fix 'layer' jargon: replace 'any layer of the model' with explicit enumeration of outcomes, decision points, decision table, and data mapping (thread at line 97) - Fix Use & Respond contradiction: remove direct feedback link that conflicted with use.md documentation; restate as 'observing real-world results' (line 105) - Add prepare.md hyperlink to Input Automation section (thread at line 113) - Fix all relative links: bootstrap/ -> ../howto/bootstrap/ after file move Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- .../ssvc-human-scale-bottleneck.md | 44 ++++++++++++------- mkdocs.yml | 2 +- 2 files changed, 28 insertions(+), 18 deletions(-) rename docs/{howto => topics}/ssvc-human-scale-bottleneck.md (84%) diff --git a/docs/howto/ssvc-human-scale-bottleneck.md b/docs/topics/ssvc-human-scale-bottleneck.md similarity index 84% rename from docs/howto/ssvc-human-scale-bottleneck.md rename to docs/topics/ssvc-human-scale-bottleneck.md index 5480bff7..351c36de 100644 --- a/docs/howto/ssvc-human-scale-bottleneck.md +++ b/docs/topics/ssvc-human-scale-bottleneck.md @@ -1,8 +1,12 @@ # **SSVC: The Human-Scale Bottleneck in Automated Vulnerability Response** -The *Stakeholder-Specific Vulnerability Categorization (SSVC)** -framework is designed to provide a human-scale decision bottleneck in the -vulnerability response process. +The **Stakeholder-Specific Vulnerability Categorization (SSVC)** framework is +designed to provide a human-scale decision bottleneck in the vulnerability +response process. SSVC is a framework **designed by humans, for humans, and +understood by humans**: the *design and governance* of the decision logic is the +human-scale work, not the execution of individual decisions. Crucially, this +does **not** mean that a human must manually review every vulnerability +decision—the decision table, once defined, can be entirely automated. ```mermaid --- @@ -33,11 +37,11 @@ flowchart LR gov -->|refines| ssvcdt gov -->|refines| dc ``` -Vulnerability response is increasingly driven by automation. -On the input side, [Data Mapping](bootstrap/collect.md) funnels large-scale +Vulnerability response is increasingly driven by automation. +On the input side, [Data Mapping](../howto/bootstrap/collect.md) funnels large-scale data collection into the small set of SSVC decision points. -On the output side, [Use & Respond](bootstrap/use.md) fans the model's outputs +On the output side, [Use & Respond](../howto/bootstrap/use.md) fans the model's outputs out into operational decisions at scale. SSVC sits in the middle as the human-scale interface where organizational policy is defined and refined into decision support tools that can be automated. @@ -46,10 +50,15 @@ core decision-making remains transparent, accountable, and aligned with organizational risk appetite, providing a necessary bridge between technical data and business policy. +In the diagram above, the `Decision Model` subgraph (containing SSVC Decision +Points and the Decision Table) represents the SSVC scope. Data Mapping and +Use & Respond are adjacent processes that interface with SSVC on either side +but are outside its core scope. + ## **Condensing Complexity into Human-Scale Decisions** The initial stages of vulnerability -response—[data collection and mapping](bootstrap/collect.md)—often involve large +response—[data collection and mapping](../howto/bootstrap/collect.md)—often involve large amounts of information, various data sharing formats (e.g., [CSAF](https://www. csaf. io/), [CVE JSON](https://cveproject.github.io/cve-schema/schema/docs/)), and @@ -133,7 +142,7 @@ desires a change, the modification to the decision table can be clearly executed and understood. The SSVC governance process—described in detail in -the [Prepare](bootstrap/prepare.md#establish-governance) step of the Getting +the [Prepare](../howto/bootstrap/prepare.md#establish-governance) step of the Getting Started guide—is what makes this refinement practical. Because the decision table is small and explicit, conversations about policy changes stay grounded: @@ -153,10 +162,11 @@ A lightweight governance process periodically reviews each element of the model: - Have there been cases where the table led to a decision that was later regretted? - Are there new constraints or requirements not yet captured? -- Is the [data mapping](bootstrap/prepare.md) still appropriate—are the +- Is the [data mapping](../howto/bootstrap/prepare.md) still appropriate—are the right data sources being used to assign values to decision points? -Depending on the review, adjustments can be made to any layer of the model. The +Depending on the review, adjustments can be made to any element of the +model—outcomes, decision points, the decision table, or data mapping. The impact of those adjustments is predictable: | Modification Type | Impact on Table Size and Complexity | @@ -168,10 +178,9 @@ impact of those adjustments is predictable: Crucially, governance should involve the right stakeholders. Risk owners must be involved in reviewing and adjusting the decision table itself, while vulnerability management and IT security teams are best positioned to review the -data mapping and decision point definitions. Operational feedback -from observing [Use & Respond](bootstrap/use.md) provides the empirical -basis for -identifying where the model needs refinement. +data mapping and decision point definitions. Observing the real-world results of +SSVC-driven decisions—as they flow back through operations—provides the +empirical basis for identifying where the model needs refinement. ## SSVC is Not a Process Bottleneck @@ -184,11 +193,12 @@ Automation can exist throughout the entire response workflow: - **Input Automation:** AI (e.g., an LLM) can perform the "reading comprehension test" of analyzing raw vulnerability data and mechanically selecting the correct - values for the SSVC decision points. See [Data Mapping](bootstrap/collect.md) - for how to connect data sources to decision point values. + values for the SSVC decision points. The [data mapping](../howto/bootstrap/collect.md) + established during [Prepare](../howto/bootstrap/prepare.md) defines how to + connect data sources to decision point values. - **Output Automation:** The prioritized outcome from the SSVC table (e.g., " Immediate") can feed directly into automated patching, ticketing, or software - fix development systems. See [Use & Respond](bootstrap/use.md) for how to + fix development systems. See [Use & Respond](../howto/bootstrap/use.md) for how to operationalize SSVC outcomes at scale. SSVC acts as a fixed, unambiguous interface. The "human scale" element is in the diff --git a/mkdocs.yml b/mkdocs.yml index 65ee8318..bddc0cbc 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -43,7 +43,6 @@ nav: - Value Density: 'howto/gathering_info/value_density.md' - Customizing SSVC: 'howto/tree_customization.md' - Acuity Ramp: 'howto/acuity_ramp.md' - - SSVC as a Human-Scale Bottleneck: 'howto/ssvc-human-scale-bottleneck.md' - Using EPSS with SSVC: - 'howto/using_epss/index.md' - EPSS Probability as input to Exploitation: 'howto/using_epss/epss_probability.md' @@ -66,6 +65,7 @@ nav: - Scope: 'topics/scope.md' - SSVC and Asset Management: 'topics/asset_management.md' - Putting the Pieces Together: 'topics/decision_points_as_bricks.md' + - SSVC as a Human-Scale Bottleneck: 'topics/ssvc-human-scale-bottleneck.md' - Worked Example: 'topics/worked_example.md' - Evaluation: 'topics/evaluation_of_draft_trees.md' - Related Systems: 'topics/related_systems.md' From 0e7b699b2f0cfa763110aeddac6a3bc8673c83b0 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Mon, 30 Mar 2026 15:33:50 -0400 Subject: [PATCH 10/11] Add human-on-the-loop terminology to intro and conclusion Introduces the standard AI/autonomy term 'human-on-the-loop' in two places to connect it explicitly to the 'human-scale bottleneck' concept: - Introduction: adds one sentence defining the term after establishing that the decision table can be fully automated - Conclusion: replaces the closing sentence with an explicit 'human-on-the-loop' framing that ties accountability to policy governance, not per-decision review Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --- docs/topics/ssvc-human-scale-bottleneck.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/docs/topics/ssvc-human-scale-bottleneck.md b/docs/topics/ssvc-human-scale-bottleneck.md index 351c36de..4644cd11 100644 --- a/docs/topics/ssvc-human-scale-bottleneck.md +++ b/docs/topics/ssvc-human-scale-bottleneck.md @@ -7,6 +7,10 @@ understood by humans**: the *design and governance* of the decision logic is the human-scale work, not the execution of individual decisions. Crucially, this does **not** mean that a human must manually review every vulnerability decision—the decision table, once defined, can be entirely automated. +In AI and autonomous systems terminology, this makes SSVC a +**"human-on-the-loop"** pattern: humans are not required to approve every +decision, but they are responsible for designing, governing, and monitoring +the framework that makes those decisions. ```mermaid --- @@ -206,5 +210,8 @@ SSVC acts as a fixed, unambiguous interface. The "human scale" element is in the understanding of the decision-making logic. The table's fixed structure means there is no ambiguity—you know what the output will be based on the defined inputs and policy. It is the locus where -technical reality meets organizational policy. The human is in the loop defining -the decision space, not necessarily making every single decision. +technical reality meets organizational policy. SSVC embodies the +**"human-on-the-loop"** pattern: the human is responsible for the decision +framework—not every individual decision. This keeps humans accountable for +the policy while freeing them from the operational volume that automation +handles best. From 89dcca8c00b981d94da5d12e330b06074dfb6dc0 Mon Sep 17 00:00:00 2001 From: "Allen D. Householder" Date: Mon, 30 Mar 2026 15:45:48 -0400 Subject: [PATCH 11/11] Refine terminology and formatting in ssvc-human-scale-bottleneck.md --- docs/topics/ssvc-human-scale-bottleneck.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/topics/ssvc-human-scale-bottleneck.md b/docs/topics/ssvc-human-scale-bottleneck.md index 4644cd11..e64a0508 100644 --- a/docs/topics/ssvc-human-scale-bottleneck.md +++ b/docs/topics/ssvc-human-scale-bottleneck.md @@ -1,14 +1,14 @@ -# **SSVC: The Human-Scale Bottleneck in Automated Vulnerability Response** +# SSVC: The Human-Scale Bottleneck in Automated Vulnerability Response -The **Stakeholder-Specific Vulnerability Categorization (SSVC)** framework is +The Stakeholder-Specific Vulnerability Categorization (SSVC) framework is designed to provide a human-scale decision bottleneck in the vulnerability -response process. SSVC is a framework **designed by humans, for humans, and -understood by humans**: the *design and governance* of the decision logic is the +response process. SSVC is a framework *designed by humans*, and +*understood by humans*: the design and governance of the decision logic is the human-scale work, not the execution of individual decisions. Crucially, this -does **not** mean that a human must manually review every vulnerability +does *not* mean that a human must manually review every vulnerability decision—the decision table, once defined, can be entirely automated. In AI and autonomous systems terminology, this makes SSVC a -**"human-on-the-loop"** pattern: humans are not required to approve every +*human-on-the-loop* pattern: humans are not required to approve every decision, but they are responsible for designing, governing, and monitoring the framework that makes those decisions. @@ -59,7 +59,7 @@ Points and the Decision Table) represents the SSVC scope. Data Mapping and Use & Respond are adjacent processes that interface with SSVC on either side but are outside its core scope. -## **Condensing Complexity into Human-Scale Decisions** +## Condensing Complexity into Human-Scale Decisions The initial stages of vulnerability response—[data collection and mapping](../howto/bootstrap/collect.md)—often involve large @@ -89,7 +89,7 @@ suitable for human oversight and policy definition: the total table size is the product of the value counts for each decision point. -## **The Decision Table: Policy as Code** +## The Decision Table: Policy as Code By defining a set of orthogonal, ordered decision points, SSVC induces a *partial order* on the entire input space (the Cartesian product of all @@ -211,7 +211,7 @@ understanding of the decision-making logic. The table's fixed structure means there is no ambiguity—you know what the output will be based on the defined inputs and policy. It is the locus where technical reality meets organizational policy. SSVC embodies the -**"human-on-the-loop"** pattern: the human is responsible for the decision +*human-on-the-loop* pattern: the human is responsible for the decision framework—not every individual decision. This keeps humans accountable for the policy while freeing them from the operational volume that automation handles best.