content: Update mitigation section for the Dependency Confusion threa…

…t. (#1226)

Documenting a SLSA-native and build trackccentric mitigation for
Dependency Confusion attacks (#1181)

Would love to hear thoughts/opinions on the best way to reflect
differing levels of adoption / maturity in native provenance
verification across different ecosystems.

---------

Signed-off-by: Meder Kydyraliev <[email protected]>

docs/spec/draft/threats.md

@@ -782,9 +782,18 @@ The consumer requests a package that it did not intend.
 on the victim's internal registry, and wait for a misconfigured victim to fetch
 from the public registry instead of the internal one.
 
-**TODO:** fill out the rest of this section
+*Mitigation:* The mitigation is for the software producer to build internal
+packages on a SLSA Level 2+ compliant build system and define expectations for
+build provenance. Expectations must be verified on installation of the internal
+packages. If a misconfigured victim attempts to install attacker's package with
+an internal name but from the public registry, then verification against
+expectations will fail.
+
+For more information see [Verifying artifacts](/spec/v1.1/verifying-artifacts)
+and [Defender's Perspective: Dependency Confusion and Typosquatting Attacks](/blog/2024/08/dep-confusion-and-typosquatting).
 
 </details>
+
 <details><summary>Typosquatting</summary>
 
 *Threat:* Register a package name that is similar looking to a popular package