Revised dependency track files

docs/spec/draft/build-env-provenance.md

@@ -0,0 +1,8 @@
+---
+title: Build Environment: Attestation Formats description: The SLSA build environment attestation formats ...
+---
+
+The SLSA build environment attestation formats ...
+
+## Build Environment: attestation formats
+

docs/spec/draft/build-env-requirements.md

@@ -0,0 +1,9 @@
+---
+title: Build Environment: Requirements
+description: The SLSA build environment requirements ...
+---
+
+The SLSA build environment requirements ...
+
+## Build Environment: Requirements 
+

docs/spec/draft/build-env-threat-mit.md

@@ -0,0 +1,9 @@
+---
+title: Build Environment:   Threats and Mitigation
+description: The SLSA build environment threats and mitigation...
+---
+
+The SLSA build environment threats and mitigatiion ...
+
+## Build Environment: Threats and Mitigation
+

docs/spec/draft/build-env-track-basics.md

@@ -1,7 +1,7 @@
 ---
 title: Build Environment track
 description: This page gives an overview of the SLSA Build Environment track and its levels, describing their security objectives and general requirements.
-mermaid: true
+mermaid: true 
 ---
 
 ## Rationale

docs/spec/draft/build-env-verification.md

@@ -0,0 +1,10 @@
+---
+title: Build Environment: verification systems
+description: The SLSA build environment verification systems ...
+---
+
+The SLSA build environment verification systems ...
+
+## Build Environment: verification systems
+
+

docs/spec/draft/build-provenance.md

@@ -1,5 +1,5 @@
 ---
-title: "Build: Provenance"
+title: "Build: Provenance" 
 description: Description of SLSA build provenance specification for verifying where, when, and how something was produced.
 layout: standard
 ---

docs/spec/draft/build-requirements.md

@@ -1,5 +1,5 @@
 ---
-title: "Build: Requirements for producing artifacts"
+title: Build: Requirements for producing artifacts
 description: This page covers the detailed technical requirements for producing artifacts at each SLSA level. The intended audience is platform implementers and security engineers.
 ---
 

docs/spec/draft/build-threats-mitigation.md

@@ -0,0 +1,11 @@
+---
+title: SLSA Build Track threats and mitigations
+description: This page covers Supply Chain threats and mitigations for the SLSA Build Track.
+---
+
+This page covers Supply Chain threats and mitigations for the SLSA Build Track.
+
+## Build Track threats and concepts
+
+
+

docs/spec/draft/build-track-basics.md

@@ -1,5 +1,5 @@
 ---
-title: "Build: Track Basics"
+title: "Build: Track Basics" 
 description: The SLSA build track is organized into a series of levels that provide increasing supply chain security guarantees. This gives you confidence that software hasn’t been tampered with and can be securely traced back to its source. This page is a descriptive overview of the SLSA build track levels, describing their intent.
 ---
 

docs/spec/draft/build-verification.md

@@ -0,0 +1,10 @@
+---
+title: SLSA Build Track verification recommendations
+description: This page covers the verfication recommendations for the SLSA the Build Track specification.
+---
+
+This page covers the verfication recommendations for the SLSA the Build Track specification.
+
+## Build Track: verification recommendations
+
+

docs/spec/draft/dependency-track.md

@@ -1,37 +1,43 @@
 ---
 title: Dependency Track
-description: This page describes the SLSA Dependency track, which enables a software producer to measure, control, and reduce risk introduced from third party dependencies.
+description: This page shows how the SLSA Dependency track enables a software producer to measure, control, and reduce risk introduced from third party dependencies.
 ---
 
-# Basics
+# {Dependency Track: Consuming Dependencies}
 
-## Objective
+**About this page:** the *Dependency Track: Consuming Dependencies* page shows how this track enables a software producer to measure, control, and reduce risk introduced from third party dependencies.
 
-Enable a software producer to measure, control, and reduce risk introduced from third party dependencies.
+**Intended audience:** {add appropriate audience}
 
-## Audience
+**Topics covered:** dependency track terminology, track level summary, track requirements
 
-The Dependency Track is primarily aimed at enterprises/organizations, with medium to large-sized organizations benefiting the most from adoption of the dependency track levels. Organizations include enterprises, but also large open source projects that want to manage third party dependency risk.
+**Internet standards:** [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119), {other standards as required}
 
-## Scope
+>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
+"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
+interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119).
 
-The scope of the SLSA Dependency Track is to properly manage and securely consume build dependencies into the developer workflow to mitigate against supply chain threats targeting the open source ecosystem.
+**For more information, see:** {optional}
 
----
+## Overview
 
-## Definitions
+The Dependency track is primarily aimed at enterprises/organizations, with medium to large-sized organizations benefiting the most from adoption of the dependency track levels. Organizations include enterprises, but also large open source projects that want to manage third party dependency risk.
 
-| Primary Term | Description
-| --- | ---
-| Build dependencies | Software artifacts fetched or otherwise made available to the build environment during the build of the artifact. This includes open and closed source binary dependencies.
-| Package registry | An entity responsible for mapping package names to artifacts within a packaging ecosystem. Most ecosystems support multiple registries, usually a single global registry and multiple private registries.
-| Artifact repository manager | A storage solution that manages your artifact lifecycle and supports different software package management systems while providing consistency to your CI/CD workflow
-| Dependency security metadata feed | A metadata feed that provides security or risk information about each dependency to assist consumers in making judgements about the safety of their dependencies
-| Package source files | A language-specific config file in a source code repo that identifies the package registry feeds or artifact repository manager feeds to consume dependencies from
+The scope of the SLSA Dependency Track is to properly manage and securely consume build dependencies into the developer workflow to mitigate against supply chain threats targeting the open source ecosystem.
 
----
+## Dependency Track Terminology
+
+These terms apply to the Dependency track. See the general terminology [list](terms-generic.md) for terms used throughout the SLSA specification.
+
+| Term | Description |
+| --- | --- |
+| Artifact repository manager | A storage solution that manages your artifact lifecycle and supports different software package management systems while providing consistency to your CI/CD workflow. |
+| Build dependencies | Software artifacts fetched or otherwise made available to the build environment during the build of the artifact. This includes open and closed source binary dependencies. |
+| Dependency security metadata feed | A metadata feed that provides security or risk information about each dependency to assist consumers in making judgements about the safety of their dependencies. |
+| Package registry | An entity responsible for mapping package names to artifacts within a packaging ecosystem. Most ecosystems support multiple registries, usually a single global registry and multiple private registries. |
+| Package source files | A language-specific config file in a source code repo that identifies the package registry feeds or artifact repository manager feeds to consume dependencies from. |
 
-## Levels
+## Dependency Track Level Summary
 
 | Level | Requirements
 | --- | ---
@@ -41,9 +47,9 @@ The scope of the SLSA Dependency Track is to properly manage and securely consum
 | Dependency L3 | Dependencies consumed from sources under producer's control
 | Dependency L4 | Proactive defence against upstream attacks
 
----
+## Dependency Track Level Specifics
 
-## Level 0: No mitigations to dependency threats
+### Level 0: No mitigations to dependency threats
 
 **Summary:**
 
@@ -57,7 +63,7 @@ N/A
 
 N/A
 
-## Level 1: Inventory of dependencies exists
+### Level 1: Inventory of dependencies exists
 
 **Summary:**
 
@@ -75,7 +81,7 @@ All third party build dependencies (including transitive) are identified.
 -   An inventory is a prerequisite to identify and manage known vulnerabilities.
 -   Implementing a centralized inventory can enable efficient incident response and risk exposure measurement.
 
-## Level 2: Known vulnerabilities have been triaged
+### Level 2: Known vulnerabilities have been triaged
 
 **Summary:**
 
@@ -93,12 +99,9 @@ Artifacts are released with no unknown 'known' vulnerabilities. Outcomes of the
 -   Proceed with the release and remediate vulnerabilities in the next release, following normal release cycle
 -   Proceed with the release and remediate vulnerabilities by expediting the next patch release.
 
-**Note:**
-
--   Does NOT mean the artifact is free of vulnerabilities, but at the time of release all known vulnerabilities are triaged.
--   Race condition: new vulnerability can, theoretically, be published on the same day as the release.
+**Note:** This does NOT mean the artifact is free of vulnerabilities, but at the time of release all known vulnerabilities are triaged. Also covers race conditions: new vulnerability can, theoretically, be published on the same day as the release.
 
-## Level 3: Dependencies consumed from locations under producer's control
+### Level 3: Dependencies consumed from locations under producer's control
 
 **Summary:**
 
@@ -112,11 +115,9 @@ Availability risks of upstream sources being removed or taken down (e.g. left-pa
 
 The build process consumes all third party build dependencies only from artifact producer-controlled locations, allowing for control of how dependencies enter the supply chain, reducing the attackable surface.  This also enables developers to continue to build even if upstream resources are unavailable.
 
-**Note:**
-
-Compliance with this level enables the ability to achieve Level 4 compliance.
+**Note:** Compliance with this level enables the ability to achieve Level 4 compliance.
 
-## Level 4: Proactive defence against upstream attack
+### Level 4: Proactive defence against upstream attack
 
 **Summary:**
 
@@ -135,13 +136,9 @@ Malicious attacks on upstream sources such as package managers, compromised pack
 
 Reduced likelihood of a released artifact including a malicious or compromised third-party dependency.
 
-**Note:**
-
-This capability builds on Level 3.
-
----
+**Note:** This capability builds upon Level 3.
 
-## Requirements
+## Dependency Track Requirements
 
 | Requirement | Description | Example | L1 | L2 | L3 | L4
 | --- | --- | --- | --- | --- | --- | ---