Refactor Related Systems & Information Sources docs

[ahouseholder]

We currently have the following content spread across a couple pages:

• Related Systems
  • CVSS
  • EPSS
  • VPR
  • CVSS spin offs
  • vPrioritizer
• Information Sources
  • Exploitation
  • System Exposure
  • Adapting other Information Sources
    • CVSS and Technical Impact
    • CWE and Exploitation
    • CPE and Safety Impact
  • Potential Future Information Feeds
    • Automatable and Value Density

Problems with this:

• CVSS information is spread across a few pages
• CWE info is actually out of date (the Exploitation page now includes the CWE table conjectured in the text)
• Information about Exploitation, System Exposure, Automatable, and Value Density might be better suited to the individual reference pages for those decision points

My suggestions are:

1. Refactor out a whole page CVSS and SSVC which would include the CVSS section from the former and the CVSS and Technical Impact from the latter. It would also add commentary on CVSS supplemental metrics and their relationship to SSVC decision points:

• CVSS Exploit Maturity vs SSVC Exploitation
• Safety
• Value Density
• Automatable

2. Revamp the remaining items in both of the original pages into possibly one or more pages focused on data mapping. This documentation suite is no longer an academic paper, so we don't necessarily need to maintain the equivalent of a related work section except insofar as we want to directly relate SSVC to those other works. (Which we should do, just more in-context than as a distinct section, I think.) The data-mapping focus seems like it might be a better fit for the howto section over topics.

• Some of the content might be better suited to the individual decision point pages in reference/decision_points/ as well. In fact, it might make sense to change the gathering information sections of those pages into more data mapping focused content first. Then, once each decision point that needs it has something about data mapping, we could create a new data mapping page in howto that provides an overview of that process.

I anticipate this issue will affect:

• docs/topics/related_systems.md
• docs/topics/information_sources.md
• possibly some of the docs/references/decision_points/*.md files for specific decision points mentioned.

This issue is itself likely too large to complete as one unit. We should work out what is to be done in this issue then spawn separate issues to address the specifics. (For example, item 1 above is almost certainly a distinct task from item 2, but item 2 might yet fragment into more tasks.)

[j---]

How should we handle information that naturally should be in two places? For example, the relationship between technical impact and CVSSv3 or CVSSv4 probably belongs both in a data mapping section about technical impact and in a section about the relationship between SSVC and CVSS.

[ahouseholder]

How should we handle information that naturally should be in two places? For example, the relationship between technical impact and CVSSv3 or CVSSv4 probably belongs both in a data mapping section about technical impact and in a section about the relationship between SSVC and CVSS.

As a starting idea, I'd say we put it in the proposed CVSS/SSVC page and then link to it from the Technical Impact reference page. If it turns out that there's something specific enough in the end result that it really does belong in the TI page as well, we could consider doing an include into a sidebar:

!!! info inline end "Technical Impact and CVSS"

    {% include-markdown "some-other-file-with-the-details.md" %}

and also include it in the ssvc-cvss page:

...
## Technical Impact and CVSS

    {% include-markdown "some-other-file-with-the-details.md" %}
...

[j---]

I'd say we put it in the proposed CVSS/SSVC page and then link to it from the Technical Impact reference page.

Thanks! This makes sense to me as the first approach.