remove disclaimers about the lack of a source track. link to the sour…

…ce track from the threats page.

docs/spec/draft/about.md

@@ -1,6 +1,6 @@
 ---
 title: About SLSA
-description: With supply chain attacks on the rise, a shared vocabulary and universal framework is needed to provide incremental guidance to harden supply chains for more secure software production. This page introduces the main concepts behind SLSA and explains how it can help anyone involved in producing, consuming, or providing infrastructure for software. 
+description: With supply chain attacks on the rise, a shared vocabulary and universal framework is needed to provide incremental guidance to harden supply chains for more secure software production. This page introduces the main concepts behind SLSA and explains how it can help anyone involved in producing, consuming, or providing infrastructure for software.
 ---
 
 This page is an introduction to SLSA and its concepts. If you're new
@@ -102,9 +102,7 @@ chain between them.
 
 We talk about SLSA in terms of [tracks and levels](levels.md).
 A SLSA track focuses on a particular aspect of a supply chain, such as the Build
-Track. SLSA v1.0 consists of only a single track ([Build](levels.md#build-track)), but future versions of
-SLSA will add tracks that cover other parts of the software supply chain, such
-as how source code is managed.
+Track.
 
 Within each track, ascending levels indicate increasingly hardened security
 practices. Higher levels provide better guarantees against supply chain threats,
@@ -130,9 +128,7 @@ important to consider together with SLSA such as:
     source code followed secure coding practices.
 -   Producer trust: SLSA does not address organizations that intentionally
     produce malicious software, but it can reduce insider risks within an
-    organization you trust. SLSA's Build Track protects against tampering during
-    or after the build, and [future SLSA tracks](future-directions.md) intend to
-    protect against unauthorized modifications of source code and dependencies.
+    organization you trust.
 -   Transitive trust for dependencies: the SLSA level of an artifact is
     independent of the level of its dependencies. You can use SLSA recursively to
     also judge an artifact's dependencies on their own, but there is

docs/spec/draft/future-directions.md

@@ -36,20 +36,12 @@ following requirements, which **may or may not** be part of a future Build L4:
 
 ## Source track
 
-A Source track could provide protection against tampering of the source code
+A Source track will provide protection against tampering of the source code
 prior to the build.
 
-The initial [draft version (v0.1)](../v0.1/requirements.md#source-requirements)
-of SLSA included the following source requirements, which **may or may not**
-form the basis for a future Source track:
-
--   Strong authentication of author and reviewer identities, such as 2-factor
-    authentication using a hardware security key, to resist account and
-    credential compromise.
--   Retention of the source code to allow for after-the-fact inspection and
-    future rebuilds.
--   Mandatory two-person review of all changes to the source to prevent a single
-    compromised actor or account from introducing malicious changes.
+The current [draft version (v1.1)](source-requirements.md) describes levels
+of increasing tamper resistance and ways consumers might verify properties
+of source revisions using SLSA source provenance attestations.
 
 </section>
 

docs/spec/draft/threats.md

@@ -56,6 +56,10 @@ to the source code that does not reflect the intent of the software producer.
 This includes modification of the source data at rest as well as insider threats,
 when an authorized individual introduces an unauthorized change.
 
+The SLSA Source track mitigates these threats when the consumer
+[verifies source revisions](verifying-source.md) against expectations, confirming
+that the revision they received was produced in the expected manner.
+
 ### (A) Producer
 
 The producer of the software intentionally produces code that harms the
@@ -73,7 +77,7 @@ When transparency is not possible, consumers may choose not to consume the artif
 Tools like the [OSSF Scorecard](https://github.com/ossf/scorecard) can help to quantify the risk of consuming artifacts from specific producers, but do not fully remove it.
 For example, a consumer may choose to only consume source artifacts from repositories that have a high score on the OSSF Scorecard.
 
-*Example:* A producer with an otherwise good reputation decides suddenly to produce a malicious artifact with the intent to harm their consumers. 
+*Example:* A producer with an otherwise good reputation decides suddenly to produce a malicious artifact with the intent to harm their consumers.
 
 </details>