Fixes per github feedback

Author: sei-renae

docs/howto/gathering_info/exploitation.md

@@ -1,18 +1,24 @@
 # Gathering Information About Exploitation
+
 ```python exec="true" idprefix=""
 from ssvc.decision_points.ssvc.exploitation 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.
+## 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.
 However, part (3) of *PoC* would not be represented in such a search, so more information gathering would be needed.
-For part (3), one approach is to construct a mapping of CWE-IDs which 
+For part (3), one approach is to construct a mapping of CWE-IDs which
 always represent vulnerabilities with well-known methods of exploitation.
-We provide a list of possible CWE-IDs for this purpose below.
+We provide a list of possible CWE-IDs for this purpose at the [bottom of this page.](./#cwe-with-poc-examples-list)
+
+!!! note "EPSS Scoring"
+    The Exploit Prediction Scoring System (EPSS) estimates the likelihood of of a Public PoC. See [this page](../../using_epss) for more information on incorporating EPSS scoring to your SSVC model.
 
+## Active
 Gathering information for *active* is a bit harder.
 If the vulnerability has a name or public identifier (such as a CVE-ID), a search of news websites, Twitter, the vendor's vulnerability description, and public vulnerability databases for mentions of exploitation is generally adequate.
 However, if the organization has the ability to detect exploitation attempts—for instance, through reliable and precise IDS signatures based on a public *PoC*—then detection of exploitation attempts also signals that *active* is the right choice.
@@ -22,8 +28,12 @@ Because most organizations do not conduct these processes fully for most inciden
 As long as those organizations also share detection methods and signatures, the results are usually quickly corroborated by the community.
 For these reasons, we assess public reporting by established security community members to be a good information source for *active*; however, one should not assume it is complete.
 
+## None
 The description for *none* says that there is no **evidence** of *active* exploitation.
 This framing admits that an analyst may not be able to detect or know about every attack.
-Acknowledging that *Exploitation* values can change relatively quickly, we recommend conducting these searches frequently: if they can be automated to the organization's satisfaction, perhaps once a day (see also [Guidance on Communicating Results](../../howto/bootstrap/use.md)). 
+Acknowledging that *Exploitation* values can change relatively quickly, we recommend conducting these searches frequently: if they can be automated to the organization's satisfaction, perhaps once a day (see also [Guidance on Communicating Results](../../howto/bootstrap/use.md)).
 An analyst should feel comfortable selecting *none* if they (or their search scripts) have performed searches in the appropriate places for public *PoC*s and *active* exploitation (as described above) and found *none*.
-Acknowledging that *Exploitation*. 
+
+
+## CWE with PoC examples list
+{% include-markdown "../../_includes/cwe-with-poc-examples.md" heading-offset=1 %}

docs/howto/gathering_info/mission_impact.md

@@ -8,9 +8,7 @@ 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.
 There are various sources of guidance on how to gather this information; see for example the FEMA guidance in Continuity Directive 2 [@FCD2_2017] or OCTAVE FORTE [@tucker2018octave].
 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.
-

docs/howto/gathering_info/system_exposure.md

@@ -24,8 +24,9 @@ Apply these heuristics in order and stop when one of them applies.
 - If the vulnerable component is on a network where other hosts can browse the web or receive email, choose *controlled*.
 - If the vulnerable component is in a third party library that is unreachable because the feature is unused in the surrounding product, choose *small*.
 
-The unreachable vulnerable component scenario may be a point of concern for stakeholders like patch suppliers who often find it more cost-effective to simply update the included library to an existing fixed version rather than try to explain to customers why the vulnerable code is unreachable in their own product.
+The unreachable vulnerable component scenario may be a point of concern for stakeholders like [patch suppliers](howto/supplier_tree.md) who often find it more cost-effective to simply update the included library to an existing fixed version rather than try to explain to customers why the vulnerable code is unreachable in their own product.
 In those cases, we suggest the stakeholder reviews the decision outcomes of the tree to ensure the appropriate action is taken (paying attention to [*defer*](../../howto/supplier_tree.md) vs [*scheduled*](../../howto/supplier_tree.md), for example).
 
-If you have suggestions for further heuristics, or potential counterexamples to these,  please describe the example and reasoning in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues).
 
+!!! question "Have an idea for something we missed?"
+    If you have suggestions for further heuristics, or potential counterexamples to these,  please describe the example and reasoning in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues).

docs/howto/gathering_info/technical_impact.md

@@ -10,14 +10,15 @@ 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*.
-If an answer to one of the following questions is _yes_, then control is *total*.
+If an answer to one of the following questions is *yes*, then control is *total*.
 After exploiting the vulnerability,
 
 - can the attacker install and run arbitrary software?
 - can the attacker trigger all the actions that the vulnerable component can perform?
 - does the attacker get an account with full privileges to the vulnerable component (administrator or root user accounts, for example)?
 
 This list is an evolving set of heuristics.
-If you find a vulnerability that should have *total* *Technical Impact* but that does not answer yes to any of 
-these questions, please describe the example and what question we might add to this list in an issue on the
-[SSVC GitHub](https://github.com/CERTCC/SSVC/issues).
+
+!!! question "Have an idea for something we missed?"
+
+    If you find a vulnerability that should have *total* *Technical Impact* but that does not answer yes to any of these questions, please describe the example and what question we might add to this list in an issue on the [SSVC GitHub](https://github.com/CERTCC/SSVC/issues).

docs/howto/gathering_info/value_density.md

@@ -8,7 +8,8 @@ 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).
+!!! question "Have an idea for something we missed?"
+    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).
 
 An analyst might use market research reports or Internet telemetry data to assess an unfamiliar product.
 Organizations such as Gartner produce research on the market position and product comparisons for a large variety of systems.