Refactor default decision point values from collect.md to includable files

docs/_includes/default_exploitation_values.md

@@ -0,0 +1,4 @@
+!!! tip "Default Exploitation Values"
+
+    [*Exploitation*](../reference/decision_points/exploitation.md) needs no special default; if adequate searches are made for exploit code and none is
+    found, the answer is [*none*](../reference/decision_points/exploitation.md).

docs/_includes/default_mission_impact_values.md

@@ -0,0 +1,5 @@
+!!! tip "Default Mission Impact Values"
+
+    Similarly, with [*Mission Impact*](/reference/decision_points/mission_impact.md), the deployer should assume that the software is in use at the
+    organization for a reason, and that it supports essential functions unless they have evidence otherwise.
+    With a total lack of information, assume [*support crippled*](/reference/decision_points/mission_impact.md) as a default.

docs/_includes/default_safety_values.md

@@ -0,0 +1,6 @@
+!!! tip "Default Safety Values"
+
+    If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a
+    [*marginal*](../reference/decision_points/safety_impact.md) [*Safety Impact*](../reference/decision_points/safety_impact.md).
+    This position is conservative, but software is thoroughly embedded in daily life now, so we suggest that the decision
+    maker provide evidence that no one's well-being will suffer.

docs/_includes/default_system_exposure_values.md

@@ -0,0 +1,5 @@
+!!! tip "Default System Exposure Values"
+
+    If the deployer does not know their exposure,<!--lowercase exposure on purpose, this is the general concept--> that
+    means they do not know where the devices are or how they are controlled, so they should assume
+    [*System Exposure*](../reference/decision_points/system_exposure.md) is [*open*](../reference/decision_points/system_exposure.md).

docs/howto/bootstrap/collect.md

@@ -94,35 +94,19 @@ deployer may want to use that information to favor the latter.
 In the case where no information is available or the organization has not yet matured its initial situational analysis,
 we can suggest something like defaults for some decision points.
 
-!!! tip "Default Exploitation Values"
+{% include-markdown "../../_includes/default_exploitation_values.md" %}
 
-    [*Exploitation*](../../reference/decision_points/exploitation.md) needs no special default; if adequate searches are made for exploit code and none is
-    found, the answer is [*none*](../../reference/decision_points/exploitation.md).
-
-!!! tip "Default System Exposure Values"
-
-    If the deployer does not know their exposure,<!--lowercase exposure on purpose, this is the general concept--> that
-    means they do not know where the devices are or how they are controlled, so they should assume
-    [*System Exposure*](../../reference/decision_points/system_exposure.md) is [*open*](../../reference/decision_points/system_exposure.md).
+{% include-markdown "../../_includes/default_system_exposure_values.md" %}
 
 !!! tip "Default Automatable Values"
 
     If nothing is known about [*Automatable*](../../reference/decision_points/automatable.md), the safer answer to assume is [*yes*](../../reference/decision_points/automatable.md).
     [*Value Density*](../../reference/decision_points/value_density.md) should always be answerable; if the product is uncommon, it is probably
     [*diffuse*](../../reference/decision_points/value_density.md).
 
-!!! tip "Default Safety Values"
-
-    If the decision maker knows nothing about the environment in which the device is used, we suggest assuming a
-    [*marginal*](../../reference/decision_points/safety_impact.md) [*Safety Impact*](../../reference/decision_points/safety_impact.md).
-    This position is conservative, but software is thoroughly embedded in daily life now, so we suggest that the decision
-    maker provide evidence that no one’s well-being will suffer.
-
-!!! tip "Default Mission Impact Values"
+{% include-markdown "../../_includes/default_safety_values.md" %}
 
-    Similarly, with [*Mission Impact*](../../reference/decision_points/mission_impact.md), the deployer should assume that the software is in use at the
-    organization for a reason, and that it supports essential functions unless they have evidence otherwise.
-    With a total lack of information, assume [*support crippled*](../../reference/decision_points/mission_impact.md) as a default.
+{% include-markdown "../../_includes/default_mission_impact_values.md" %}
 
 !!! example "Using Defaults"
 

docs/howto/gathering_info/exploitation.md

@@ -7,6 +7,8 @@ from ssvc.doc_helpers import example_block
 print(example_block(LATEST))
 ```
 
+{% include-markdown "../../_includes/default_exploitation_values.md" %}
+
 ## Public PoC
 [Historical Analysis of Exploit Availability Timelines](https://dl.acm.org/doi/10.5555/3485754.3485760) presents a method for searching the GitHub repositories of open-source exploit databases.
 This method could be employed to gather information about whether *PoC* is true.

docs/howto/gathering_info/mission_impact.md

@@ -12,3 +12,5 @@ At a minimum, understanding mission impact should include gathering information
 There are various sources of guidance on how to gather this information; see for example the FEMA guidance in [Continuity Directive 2](https://www.fema.gov/sites/default/files/2020-07/Federal_Continuity_Directive-2_June132017.pdf) or [OCTAVE FORTE](https://insights.sei.cmu.edu/insider-threat/2018/06/octave-forte-and-fair-connect-cyber-risk-practitioners-with-the-boardroom.html).
 This is part of risk management more broadly.
 It should require the vulnerability management team to interact with more senior management to understand mission priorities and other aspects of risk mitigation.
+
+{% include-markdown "../../_includes/default_mission_impact_values.md" %}

docs/howto/gathering_info/system_exposure.md

@@ -7,6 +7,8 @@ from ssvc.doc_helpers import example_block
 print(example_block(LATEST))
 ```
 
+{% include-markdown "../../_includes/default_system_exposure_values.md" %}
+
 *System Exposure* is primarily used by [Deployers](../../deployer_tree), so the question is about whether some specific system is in fact exposed, not a hypothetical or aggregate question about systems of that type.
 Therefore, it generally has a concrete answer, even though it may vary from vulnerable component to vulnerable component, based on their respective configurations.
 

docs/reference/decision_points/exploitation.md

@@ -11,6 +11,8 @@ print(example_block(LATEST))
 
       See this [HowTo](../../howto/gathering_info/exploitation.md) for advice on gathering information about the Exploitation decision point.
 
+{% include-markdown "../../_includes/default_exploitation_values.md" %}
+
 The intent of this measure is the present state of exploitation of the vulnerability. The intent is not to predict future exploitation but only to acknowledge the current state of affairs. Predictive systems, such as EPSS, could be used to augment this decision or to notify stakeholders of likely changes [@jacobs2021epss].
 
 ## CWE-IDs for *PoC*

docs/reference/decision_points/mission_impact.md

@@ -11,6 +11,8 @@ print(example_block(LATEST))
 
       See this [HowTo](../../howto/gathering_info/mission_impact.md) for advice on gathering information about the Mission Impact decision point.
 
+{% include-markdown "../../_includes/default_mission_impact_values.md" %}
+
 !!! tip "See also"
 
     Mission Impact combines with [Safety Impact](./safety_impact.md) to inform 

docs/reference/decision_points/safety_impact.md

@@ -47,6 +47,8 @@ Aggregation suggests that the stakeholder’s response to this decision point ca
 
 ## Gathering Information About Safety Impact
 
+{% include-markdown "../../_includes/default_safety_values.md" %}
+
 The factors that influence the safety impact level are diverse.
 This paper does not exhaustively discuss how a stakeholder should answer a question; that is a topic for future work.
 At a minimum, understanding safety impact should include gathering information about survivability of the vulnerable component, determining available operator actions to compensate for the vulnerable component, understanding relevant insurance, and determining the viability of existing backup measures.

docs/reference/decision_points/system_exposure.md

@@ -11,6 +11,8 @@ print(example_block(LATEST))
 
       See this [HowTo](../../howto/gathering_info/system_exposure.md) for advice on gathering information about the System Exposure decision point.
 
+{% include-markdown "../../_includes/default_system_exposure_values.md" %}
+
 Measuring the attack surface precisely is difficult, and we do not propose to perfectly delineate between small and controlled access.
 Exposure should be judged against the system in its deployed context, which may differ from how it is commonly expected to be deployed.
 For example, the exposure of a device on a vehicle's CAN bus will vary depending on the presence of a cellular telemetry device on the same bus.

mkdocs.yml

@@ -9,7 +9,6 @@ nav:
     - 'tutorials/ssvc_overview.md'
     - Starting out with SSVC: 'tutorials/starting_points.md'
     - Other Resources: 'tutorials/other_resources.md'
-
   - SSVC How-To:
     - Overview: 'howto/index.md'
     - Getting Started with SSVC:
@@ -177,6 +176,7 @@ theme:
 plugins:
   - include-markdown:
       comments: false
+      rewrite_relative_links: true
   - search
   - table-reader:
       data_path: 'data/csvs'