Moved example to a new threat.

The example was in the wrong place. It had been under a threat
that was meant for attackers that modified signed attestations,
yet it discussed replacing one valid attestation with another.

There wasn't an obivious existing threat to put this under so
I created a new one.

refs slsa-framework#1191

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

docs/spec/draft/threats.md

@@ -717,6 +717,20 @@ corresponding signing key.
 on the package repository and deletes existing provenance. Solution: Verifier
 rejects because provenance is missing.
 
+</details>
+<details><summary>Replace package and VSA with another <span>(expectations)</span></summary>
+
+*Threat:* Replace a package and its VSA with a malicious package and its valid VSA.
+
+*Mitigation*: Verifier checks that the `resourceUri` in the VSA matches the package
+they've requested not just the package they received.
+
+*Example:* Adversary uploads a malicious package to `repo/evil-package`,
+getting a valid VSA for `repo/evil-package`. Adversary then replaces
+`repo/my-package` and its VSA with `repo/evil-package` and its VSA.
+Solution: Verifier rejects because the VSA `resourceUri` field lists
+`repo/evil-package` and not the expected `repo/my-package`.
+
 </details>
 <details><summary>Tamper with artifact after upload <span>(Build L1)</span></summary>
 
@@ -752,12 +766,6 @@ builds a malicious package and then modifies the original VSA's `subject`
 field to match the digest of the malicious package. Solution: Verifier rejects
 because the cryptographic signature is no longer valid.
 
-*Example 3:* Adversary uploads a malicious package to `repo/evil-package`,
-getting a valid VSA for `repo/evil-package`. Adversary then replaces
-`repo/my-package` and its VSA with `repo/evil-package` and its VSA.
-Solution: Verifier rejects because the VSA `resourceUri` field lists
-`repo/evil-package` and not the expected `repo/my-package`.
-
 </details>
 
 ## Usage threats