content: draft: Flesh out "Usage" threat

There are two ways to look at the usage threat:

1. Can the attacker modify the software being delivered to a consumer.
2. Can the consumer use the software insecurly allowing an attacker
   to take advantage of that insecurity to exploit them.

IMO 1 has the same solutions as 'G' (PR slsa-framework#1190).  I could repeat them
here under usage, but instead I've updated 'G' to include modification
in transit, and I've had 'Usage' address 2 above (albeit by just
deferring to CISA's work in this area).

fixes slsa-framework#1182

Signed-off-by: Tom Hennen <tomhennen@google.com>

docs/spec/draft/threats.md

@@ -662,7 +662,8 @@ cryptographic signature is no longer valid.
 ### (G) Distribution channel
 
 An adversary modifies the package on the package registry using an
-administrative interface or through a compromise of the infrastructure.
+administrative interface or through a compromise of the infrastructure
+including modification of the package in transit to the consumer.
 
 The distribution channel threats and mitigations look very similar to the
 Artifact Publication (F) threats and mitigations with the main difference
@@ -787,7 +788,16 @@ solutions.
 
 ### (I) Usage
 
-**TODO:** What should we put here?
+The consumer uses a package in an unsafe manner.
+
+<details><summary>Improper usage</summary>
+
+*Threat:* The software can be used in an insecure manner, allowing an
+adversary to compromise the consumer.
+
+*Mitigation:* This threat is not addressed by SLSA, but may be addressed by
+efforts like [Secure by Design][secure-by-design].
+</details>
 
 ## Dependency threats
 
@@ -1026,6 +1036,7 @@ collision resistance.
 [exists]: requirements.md#provenance-exists
 [isolated]: requirements.md#isolated
 [unforgeable]: requirements.md#provenance-unforgeable
+[secure-by-design]: https://www.cisa.gov/securebydesign
 [supply chain threats]: threats-overview
 [vsa]: verification_summary
 [vsa_verification]: verification_summary#how-to-verify