Add links from Reference/DP pages to Howto/GI pages. Add versioning to Howto/GI pages.

Author: Renae Metcalf

docs/howto/gathering_info/automatable.md

@@ -1,5 +1,12 @@
 # Gathering Information about Automatable
 
+``` python exec="true" idprefix=""
+from ssvc.decision_points.ssvc.automatable import LATEST
+from ssvc.doc_helpers import example_block
+
+print(example_block(LATEST))
+```
+
 An analyst should be able to sketch the automation scenario and how it either does or does not satisfy each of the four kill chain steps.
 Once one step is not satisfied, the analyst can stop and select [*no*](automatable.md).
 Code that demonstrably automates all four kill chain steps certainly satisfies as a sketch.

docs/howto/gathering_info/exploitation.md

@@ -1,4 +1,10 @@
 # Gathering Information About Exploitation
+```python exec="true" idprefix=""
+from ssvc.decision_points.ssvc.automatable import LATEST
+from ssvc.doc_helpers import example_block
+
+print(example_block(LATEST))
+```
 
 [@householder2020historical] 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

@@ -1,5 +1,12 @@
 # Gathering Information About Mission Impact
 
+```python exec="true" idprefix=""
+from ssvc.decision_points.ssvc.automatable import LATEST
+from ssvc.doc_helpers import example_block
+
+print(example_block(LATEST))
+```
+
 The factors that influence the mission impact level are diverse.
 The material here does not exhaustively discuss how a stakeholder should answer a question; that is a topic for future work.
 At a minimum, understanding mission impact should include gathering information about the critical paths that involve vulnerable components, viability of contingency measures, and resiliency of the systems that support the mission.

docs/howto/gathering_info/system_exposure.md

@@ -1,5 +1,12 @@
 # Gathering Information About System Exposure
 
+```python exec="true" idprefix=""
+from ssvc.decision_points.ssvc.automatable import LATEST
+from ssvc.doc_helpers import example_block
+
+print(example_block(LATEST))
+```
+
 *System Exposure* is primarily used by Deployers, 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/howto/gathering_info/technical_impact.md

@@ -1,5 +1,12 @@
 # Gathering Information About Technical Impact
 
+```python exec="true" idprefix=""
+from ssvc.decision_points.ssvc.automatable import LATEST
+from ssvc.doc_helpers import example_block
+
+print(example_block(LATEST))
+```
+
 Assessing *Technical Impact* amounts to assessing the degree of control over the vulnerable component the attacker stands to gain by exploiting the vulnerability.
 One way to approach this analysis is to ask whether the control gained is *total* or not.
 If it is not total, it is *partial*.

docs/howto/gathering_info/value_density.md

@@ -1,5 +1,12 @@
 # Gathering Information About Value Density
 
+```python exec="true" idprefix=""
+from ssvc.decision_points.ssvc.automatable import LATEST
+from ssvc.doc_helpers import example_block
+
+print(example_block(LATEST))
+```
+
 The heuristics presented in the *Value Density* definitions involve whether the system is usually maintained by a dedicated professional, although we have noted some exceptions (such as encrypted mobile messaging applications).
 If there are additional counterexamples to this heuristic, please describe them and the reasoning why the system should have the alternative decision value in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues).
 

docs/reference/decision_points/automatable.md

@@ -7,6 +7,10 @@ from ssvc.doc_helpers import example_block
 print(example_block(LATEST))
 ```
 
+!!! tip "Gathering Information about Automatable"
+
+      See this [HowTo](../../howto/gathering_info/automatable.md) for advice on gathering information about the Automatable decision point.
+
 !!! tip "See also"
 
     Automatable combines with [Value Density](./value_density.md) to inform 

docs/reference/decision_points/exploitation.md

@@ -7,6 +7,10 @@ from ssvc.doc_helpers import example_block
 print(example_block(LATEST))
 ```
 
+!!! tip "Gathering Information about Exploitation"
+
+      See this [HowTo](../../howto/gathering_info/exploitation.md) for advice on gathering information about the Exploitation decision point.
+
 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

@@ -7,6 +7,10 @@ from ssvc.doc_helpers import example_block
 print(example_block(LATEST))
 ```
 
+!!! tip "Gathering Information about Mission Impact"
+
+      See this [HowTo](../../howto/gathering_info/mission_impact.md) for advice on gathering information about the Mission Impact decision point.
+
 !!! tip "See also"
 
     Mission Impact combines with [Safety Impact](./safety_impact.md) to inform 

docs/reference/decision_points/system_exposure.md

@@ -7,6 +7,10 @@ from ssvc.doc_helpers import example_block
 print(example_block(LATEST))
 ```
 
+!!! tip "Gathering Information about System Exposure"
+
+      See this [HowTo](../../howto/gathering_info/system_exposure.md) for advice on gathering information about the System Exposure decision point.
+
 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.