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

@@ -788,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
 
@@ -1027,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