fix: draft: Fix threat links in verifying-systems, verifying-artifacts (

#1193)

These pages previously had links to the old threats page.

Updated them to reference the corresponding new threats.

fixes #1189

---------

Signed-off-by: Tom Hennen <[email protected]>

docs/spec/draft/verifying-artifacts.md

@@ -120,17 +120,19 @@ Resulting threat mitigation:
 -   [Threat "G"]: Verification by the consumer or otherwise outside of the
     package registry covers compromise of the registry itself. (Verifying within
     the registry at publication time is also valuable, but does not cover Threat
-    "G" or "H".)
--   [Threat "H"]: Verification by the consumer covers compromise of the package
+    "G" or "I".)
+-   [Threat "I"]: Verification by the consumer covers compromise of the package
     in transit. (Many ecosystems also address this threat using package
     signatures or checksums.)
-    -   NOTE: SLSA does not cover adversaries tricking a consumer to use an
-        unintended package, such as through typosquatting.
+    -   NOTE: SLSA does not yet cover adversaries tricking a consumer to use an
+        unintended package, such as through typosquatting. Those threats are
+        discussed in more detail under [Threat "H"].
 
-[Threat "E"]: threats#e-compromise-build-process
-[Threat "F"]: threats#f-upload-modified-package
-[Threat "G"]: threats#g-compromise-package-repo
-[Threat "H"]: threats#h-use-compromised-package
+[Threat "E"]: threats#e-build-process
+[Threat "F"]: threats#f-artifact-publication
+[Threat "G"]: threats#g-distribution-channel
+[Threat "H"]: threats#h-package-selection
+[Threat "I"]: threats#i-usage
 
 [validation-model]: https://github.com/in-toto/attestation/blob/main/docs/validation.md#validation-model
 
@@ -139,7 +141,7 @@ Resulting threat mitigation:
 [verify-step-2]: #check-expectations
 
 Next, check that the package's provenance meets your expectations for that
-package in order to mitigate [threat "C"].
+package in order to mitigate [threat "D"].
 
 In our threat model, the adversary has ability to invoke a build and to publish
 to the registry. The adversary is not able to write to the source repository, nor do
@@ -171,7 +173,7 @@ source repository, then put only the source repository in
 `externalParameters`. Such a design is easier to verify because the source
 repository is constant across builds.
 
-[Threat "C"]: threats#c-build-from-modified-source
+[Threat "D"]: threats#d-external-build-parameters
 
 ### Step 3: (Optional) Check dependencies recursively
 
@@ -180,7 +182,7 @@ repository is constant across builds.
 Finally, recursively check the `resolvedDependencies` as available and to the
 extent desired. Note that SLSA v1.0 does not have any requirements on the
 completeness or verification of `resolvedDependencies`. However, one might wish
-to verify dependencies in order to mitigate [threat "E"] and protect against
+to verify dependencies in order to mitigate [dependency threats] and protect against
 threats further up the supply chain. If `resolvedDependencies` is incomplete,
 these checks can be done on a best-effort basis.
 
@@ -190,7 +192,7 @@ heuristic or exception mechanism is almost always necessary when verifying
 dependencies because there will be transitive dependencies that are SLSA Build
 L0. (For example, consider the compiler's compiler's compiler's ... compiler.)
 
-[Threat "E"]: threats#e-use-compromised-dependency
+[dependency threats]: threats#dependency-threats
 [VSA]: /verification_summary
 [threats]: threats
 

docs/spec/draft/verifying-systems.md

@@ -31,7 +31,7 @@ with binary hash X and a build with external parameters P' would produce an
 artifact with binary hash Y, they wish to produce provenance indicating a build
 with external parameters P produced an artifact with binary hash Y.
 
-See threats [C], [D], [E], and [F] for examples of specific threats.
+See threats [D], [E], [F], and [G] for examples of specific threats.
 
 Note: Platform abuse (e.g. running non-build workloads) and attacks against
 builder availability are out of scope of this document.
@@ -63,10 +63,10 @@ following types of adversaries.
     -   Access the control plane's cryptographic secrets.
     -   Remotely access build environments (e.g. via SSH).
 
-[C]: threats.md#c-build-from-modified-source
-[D]: threats.md#d-use-compromised-dependency
-[E]: threats.md#e-compromise-build-process
-[F]: threats.md#f-upload-modified-package
+[D]: threats.md#d-external-build-parameters
+[E]: threats.md#e-build-process
+[F]: threats.md#f-artifact-publication
+[G]: threats.md#g-distribution-channel
 
 ## Build platform components