diff --git a/docs/spec/draft/assessing-build-platforms.md b/docs/spec/draft/assessing-build-platforms.md
deleted file mode 100644
index dd17f3a0b..000000000
--- a/docs/spec/draft/assessing-build-platforms.md
+++ /dev/null
@@ -1,239 +0,0 @@
----
-title: "Build: Assessing build platforms"
-description: Guidelines for assessing build platform security.
----
-
-One of SLSA's guiding [principles](principles.md) is to "trust platforms, verify
-artifacts". However, consumers cannot trust platforms to produce Build L3
-artifacts and provenance unless they have some proof that the provenance is
-[unforgeable](build-requirements.md#provenance-unforgeable) and the builds are
-[isolated](build-requirements.md#isolated).
-
-This page describes the parts of a build platform that consumers SHOULD assess
-and provides sample questions consumers can ask when assessing a build platform.
-See also [Threats & mitigations](threats.md) and the
-[build model](terminology.md#build-model).
-
-## Threats
-
-### Adversary goal
-
-The SLSA Build track defends against an adversary whose primary goal is to
-inject unofficial behavior into a package artifact while avoiding detection.
-Remember that [verifiers](verifying-artifacts.md) only accept artifacts whose
-provenance matches expectations. To bypass this, the adversary tries to either
-(a) tamper with a legitimate build whose provenance already matches
-expectations, or (b) tamper with an illegitimate build's provenance to make it
-match expectations.
-
-More formally, if a build with external parameters P would produce an artifact
-with binary hash X and a build with external parameters P' would produce an
-artifact with binary hash Y, they wish to produce provenance indicating a build
-with external parameters P produced an artifact with binary hash Y.
-
-See threats [D], [E], [F], and [G] for examples of specific threats.
-
-Note: Platform abuse (e.g. running non-build workloads) and attacks against
-builder availability are out of scope of this document.
-
-### Adversary profiles
-
-Consumers SHOULD also evaluate the build platform's ability to defend against the
-following types of adversaries.
-
-1. Project contributors, who can:
- - Create builds on the build platform. These are the adversary's controlled
- builds.
- - Modify one or more controlled builds' external parameters.
- - Modify one or more controlled builds' environments and run arbitrary
- code inside those environments.
- - Read the target build's source repo.
- - Fork the target build's source repo.
- - Modify a fork of the target build's source repo and build from it.
-2. Project maintainer, who can:
- - Do everything listed under "project contributors".
- - Create new builds under the target build's project or identity.
- - Modify the target build's source repo and build from it.
- - Modify the target build's configuration.
-3. Build platform administrators, who can:
- - Do everything listed under "project contributors" and "project
- maintainers".
- - Run arbitrary code on the build platform.
- - Read and modify network traffic.
- - Access the control plane's cryptographic secrets.
- - Remotely access build environments (e.g. via SSH).
-
-[D]: threats.md#d-external-build-parameters
-[E]: threats.md#e-build-process
-[F]: threats.md#f-artifact-publication
-[G]: threats.md#g-distribution-channel
-
-## Build platform components
-
-Consumers SHOULD consider at least these five elements of the
-[build model](terminology.md#build-model) when assessing build platforms for SLSA
-conformance: external parameters, control plane, build environments, caches,
-and outputs.
-
-
-
-The following sections detail these elements of the build model and give prompts
-for assessing a build platform's ability to produce SLSA Build L3 provenance.
-The assessment SHOULD take into account the security model used to identify the
-transitive closure of the `builder.id` for the
-[provenance model](build-provenance.md#model), specifically around the
-platform's boundaries, actors, and interfaces.
-
-### External parameters
-
-External parameters are the external interface to the builder and include all
-inputs to the build process. Examples include the source to be built, the build
-definition/script to be executed, user-provided instructions to the
-control plane for how to create the build environment (e.g. which operating
-system to use), and any additional user-provided strings.
-
-#### Prompts for assessing external parameters
-
-- How does the control plane process user-provided external parameters?
- Examples: sanitizing, parsing, not at all
-- Which external parameters are processed by the control plane and which are
- processed by the build environment?
-- What sort of external parameters does the control plane accept for
- build environment configuration?
-- How do you ensure that all external parameters are represented in the
- provenance?
-- How will you ensure that future design changes will not add additional
- external parameters without representing them in the provenance?
-
-### Control plane
-
-The control plane is the build platform component that orchestrates each
-independent build execution. It is responsible for setting up each build and
-cleaning up afterwards. At SLSA Build L2+ the control plane generates and signs
-provenance for each build performed on the build platform. The control plane is
-operated by one or more administrators, who have privileges to modify the
-control plane.
-
-#### Prompts for assessing the control plane
-
-- Administration
- - What are the ways an employee can use privileged access to influence a
- build or provenance generation? Examples: physical access, terminal
- access, access to cryptographic secrets
- - What controls are in place to detect or prevent the employee from
- abusing such access? Examples: two-person approvals, audit logging,
- workload identities
- - Roughly how many employees have such access?
- - How are privileged accounts protected? Examples: two-factor
- authentication, client device security policies
- - What plans do you have for recovering from security incidents and platform
- outages? Are they tested? How frequently?
-
-- Provenance generation
- - How does the control plane observe the build to ensure the provenance's
- accuracy?
- - Are there situations in which the control plane will not generate
- provenance for a completed build? What are they?
-
-- Development practices
- - How do you track the control plane's software and configuration?
- Example: version control
- - How do you build confidence in the control plane's software supply
- chain? Example: SLSA L3+ provenance, build from source
- - How do you secure communications between builder components? Example:
- TLS with certificate transparency.
- - Are you able to perform forensic analysis on compromised build
- environments? How? Example: retain base images indefinitely
-
-- Creating build environments
- - How does the control plane share data with build environments? Example:
- mounting a shared file system partition
- - How does the control plane protect its integrity from build
- environments? Example: not mount its own file system partitions on
- build environments
- - How does the control plane prevent build environments from accessing its
- cryptographic secrets? Examples: dedicated secret storage, not mounting
- its own file system partitions to build environments, hardware security
- modules
-
-- Managing cryptographic secrets
- - How do you store the control plane's cryptographic secrets?
- - Which parts of the organization have access to the control plane's
- cryptographic secrets?
- - What controls are in place to detect or prevent employees abusing such
- access? Examples: two-person approvals, audit logging
- - How are secrets protected in memory? Examples: secrets are stored in
- hardware security modules and backed up in secure cold storage
- - How frequently are cryptographic secrets rotated? Describe the rotation
- process.
- - What is your plan for remediating cryptographic secret compromise? How
- frequently is this plan tested?
-
-### Build environment
-
-The build environment is the independent execution context where the build
-takes place. In the case of a distributed build, the build environment is the
-collection of all execution contexts that run build steps. Each build
-environment must be isolated from the control plane and from all other build
-environments, including those running builds from the same tenant or project.
-Tenants are free to modify the build environment arbitrarily. Build
-environments must have a means to fetch input artifacts (source, dependencies,
-etc).
-
-#### Prompts for assessing build environments
-
-- Isolation technologies
- - How are build environments isolated from the control plane and each
- other? Examples: VMs, containers, sandboxed processes
- - How is separation achieved between trusted and untrusted processes?
- - How have you hardened your build environments against malicious tenants?
- Examples: configuration hardening, limiting attack surface
- - How frequently do you update your isolation software?
- - What is your process for responding to vulnerability disclosures? What
- about vulnerabilities in your dependencies?
- - What prevents a malicious build from gaining persistence and influencing
- subsequent builds?
-
-- Creation and destruction
- - What operating system and utilities are available in build environments
- on creation? How were these elements chosen? Examples: A minimal Linux
- distribution with its package manager, OSX with HomeBrew
- - How long could a compromised build environment remain active in the
- build platform?
-
-- Network access
- - Are build environments able to call out to remote execution? If so, how
- do you prevent them from tampering with the control plane or other build
- environments over the network?
- - Are build environments able to open services on the network? If so, how
- do you prevent remote interference through these services?
-
-### Cache
-
-Builders may have zero or more caches to store frequently used dependencies.
-Build environments may have either read-only or read-write access to caches.
-
-#### Prompts for assessing caches
-
-- What sorts of caches are available to build environments?
-- How are those caches populated?
-- How are cache contents validated before use?
-
-### Output storage
-
-Output Storage holds built artifacts and their provenance. Storage may either be
-shared between build projects or allocated separately per-project.
-
-#### Prompts for assessing output storage
-
-- How do you prevent builds from reading or overwriting files that belong to
- another build? Example: authorization on storage
-- What processing, if any, does the control plane do on output artifacts?
-
-## Builder evaluation
-
-Organizations can either self-attest to their answers or seek certification from
-a third-party auditor. Evidence for self-attestation should be published on
-the internet and can include information such as the security model defined as
-part of the provenance. Evidence submitted for third-party certification need not
-be published.
diff --git a/docs/spec/draft/build-env-track-basics.md b/docs/spec/draft/build-env-track-basics.md
index 9da530a3b..5189f0861 100644
--- a/docs/spec/draft/build-env-track-basics.md
+++ b/docs/spec/draft/build-env-track-basics.md
@@ -1,10 +1,26 @@
---
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
+description: This page covers the SLSA Build Environment track and its levels, describing their security objectives and general requirements.
+mermaid: true
---
-## Rationale
+# {Build Environment Track: Basics}
+
+**About this page:** the *Build Environment Track: Basics* page defines its levels, describes their security objectives and general requirements.
+
+**Intended audience:** {add appropriate audience}
+
+**Topics covered:** build track terminology, threats to build environments, explaination for build environment model, level specifics
+
+**Internet standards:** [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119), {other standards as required}
+
+>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).
+
+**For more information, see:** {optional}
+
+## Overview
Today's hosted [build platforms] play a central role in an artifact's supply
chain. Whether it's a cloud-hosted service like GitHub Actions or an internal
@@ -19,105 +35,74 @@ implement and operate fully secure build platforms because they are made up
of many layers of interconnected components and subsystems.
The SLSA Build Environment track aims to address these issues by making it
-possible to validate the integrity and trace the [provenance] of core build
+possible to validate the integrity and trace the provenance of core build
platform components.
-## Track overview
+## Build Environment Track Terminology
-The SLSA Build Environment (BuildEnv) track describes increasing levels of
-integrity and trustworthiness of the provenance of a build's
-execution context. In this track, provenance describes how a build image
-was created, how the hosted build platform deployed a build image in its
-environment, and the compute platform they used.
+These terms apply to the Build Environment track. See the general terminology [list](terms-generic.md) for terms used throughout the SLSA specification.
-| Track/Level | Requirements | Focus | Trust Root
-| ----------- | ------------ | ----- | ----------
-| [BuildEnv L0] | (none) | (n/a) | (n/a)
-| [BuildEnv L1] | Signed build image provenance exists | Tampering during build image distribution | Signed build image provenance
-| [BuildEnv L2] | Attested build environment instantiation | Tampering via the build platform's control plane | The compute platform's host interface
-| [BuildEnv L3] | Hardware-attested build environment | Tampering via the compute platform's host interface | The compute platform's hardware
+| Term | Description |
+| --- | --- |
+| Boot process | In the context of builds, the process of loading and executing the layers of firmware and/or software needed to start up a build environment on the host compute platform. |
+| Build agent | A build platform-provided program that interfaces with the build platform's control plane from within a running build environment. The build agent is also responsible for executing the tenant’s build definition, i.e., running the build. In practice, the build agent may be loaded into the build environment after instantiation, and may consist of multiple components. All build agent components must be measured along with the build image. |
+| Build dispatch | The process of assigning a tenant's build to a pre-deployed build environment on a hosted build platform. |
+| Build ID | An immutable identifier assigned uniquely to a specific execution of a tenant's build. In practice, the build ID may be an identifier, such as a UUID, associated with the build execution. |
+| Build image | The template for a build environment, such as a VM or container image. Individual components of a build image include the root filesystem, pre-installed guest OS and packages, the build executor, and the build agent. |
+| Build image producer | The party that creates and distributes build images. In practice, the build image producer may be the hosted build platform or a third party in a bring-your-own (BYO) build image setting. |
+| Build platform assessment | [Build platforms are assessed](assessing-build-platforms.md) for their ability to meet SLSA requirements at the stated level. |
+| Compute platform | The compute system and infrastructure underlying a build platform, i.e., the host system (hypervisor and/or OS) and hardware. In practice, the compute platform and the build platform may be managed by the same or distinct organizations. |
+| Host interface | The component in the compute platform that the hosted build platform uses to request resources for deploying new build environments, i.e., the VMM/hypervisor or container orchestrator. |
+| Measurement | The cryptographic hash of some component or system state in the build environment, including software binaries, configuration, or initialized run-time data. |
+| Quote | (Virtual) hardware-signed data that contains one or more (virtual) hardware-generated measurements. Quotes may additionally include nonces for replay protection, firmware information, or other platform metadata. (Based on the definition in [section 9.5.3.1](https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf) of the TPM 2.0 spec) |
+| Reference value | A specific measurement used as the good known value for a given build environment component or state. |
-> :warning:
-> The Build Environment track L1+ currently requires a [hosted] build platform.
-> A future version of this track may generalize requirements to cover bare-metal
-> build environments.
+### Build environment track terms to avoid
-> :grey_exclamation:
-> We may consider the addition of an L4 to the Build Environment track, which
-> covers hardware-attested runtime integrity checking during a build.
+| Term | Reason to avoid |
+| --- | --- |
+| image| Disambiguate similar terms. |
+| build job | Disambiguate similar terms. |
+| build executor/runner | Disambiguate similar terms. |
-### Build environment model
+## What the Build Environment Track does
-
+{clean} The SLSA [Build track] defines requirements for the provenance that is produced for the build artifacts. Trustworthiness of the build process largely depends on the trustworthiness of the [build environment] the build runs in. The Build track assumes full trust into the [Build Platform], and provides no requirements to verify integrity of the build environment. BuildEnv track intends to close this gap.
-The Build Environment (BuildEnv) track expands upon the
-[build model](terminology#build-model) by explicitly separating the
-[build image](terminology#build-image) and [compute platform](#compute-platform) from the
-abstract [build environment](#build-environment) and [build platform](terminology#platform).
-Specifically, the BuildEnv track defines the following roles, components, and concepts:
-
-| Primary Term | Description
-| --- | ---
-| Build ID | An immutable identifier assigned uniquely to a specific execution of a tenant's build. In practice, the build ID may be an identifier, such as a UUID, associated with the build execution.
-| Build image | The template for a build environment, such as a VM or container image. Individual components of a build image include the root filesystem, pre-installed guest OS and packages, the build executor, and the build agent.
-| Build image producer | The party that creates and distributes build images. In practice, the build image producer may be the hosted build platform or a third party in a bring-your-own (BYO) build image setting.
-| Build agent | A build platform-provided program that interfaces with the build platform's control plane from within a running build environment. The build agent is also responsible for executing the tenant’s build definition, i.e., running the build. In practice, the build agent may be loaded into the build environment after instantiation, and may consist of multiple components. All build agent components must be measured along with the build image.
-| Build dispatch | The process of assigning a tenant's build to a pre-deployed build environment on a hosted build platform.
-| Compute platform | The compute system and infrastructure underlying a build platform, i.e., the host system (hypervisor and/or OS) and hardware. In practice, the compute platform and the build platform may be managed by the same or distinct organizations.
-| Host interface | The component in the compute platform that the hosted build platform uses to request resources for deploying new build environments, i.e., the VMM/hypervisor or container orchestrator.
-| Boot process | In the context of builds, the process of loading and executing the layers of firmware and/or software needed to start up a build environment on the host compute platform.
-| Measurement | The cryptographic hash of some component or system state in the build environment, including software binaries, configuration, or initialized run-time data.
-| Quote | (Virtual) hardware-signed data that contains one or more (virtual) hardware-generated measurements. Quotes may additionally include nonces for replay protection, firmware information, or other platform metadata. (Based on the definition in [section 9.5.3.1](https://trustedcomputinggroup.org/wp-content/uploads/TPM-2.0-1.83-Part-1-Architecture.pdf) of the TPM 2.0 spec)
-| Reference value | A specific measurement used as the good known value for a given build environment component or state.
-
-**TODO:** Disambiguate similar terms (e.g., image, build job, build executor/runner)
-
-#### Build environment lifecycle
-
-A typical build environment will go through the following lifecycle:
+### What it includes
-1. *Build image creation*: A [build image producer](#build-image-producer)
- creates different [build images](#build-image) through a dedicated build
- process. For the SLSA BuildEnv track, the build image producer outputs
- [provenance](terminology#provenance) describing this process.
-2. *Build environment instantiation*: The [hosted build platform](terminology#platform)
- calls into the [host interface](#host-interface) to create a new instance
- of a build environment from a given build image. The
- [build agent](#build-agent) begins to wait for an incoming
- [build dispatch](#build-dispatch).
- For the SLSA BuildEnv track, the host interface in the compute platform
- attests to the integrity of the environment's initial state during its
- [boot process](#boot-process).
-3. *Build dispatch*: When the tenant dispatches a new build, the hosted
- build platform assigns the build to a created build environment.
- For the SLSA BuildEnv track, the build platform attests to the binding
- between a build environment and [build ID](#build-id).
-4. *Build execution*: Finally, the build agent within the environment executes
- the tenant's build definition.
+ - Build environment is bootstrapped from a [build image], which is expected to be an artifact of a SLSA build pipeline.
+
+ - Build platform verifies image security properties including provenance upon starting up the environment and makes evidence of the verification available to tenants or other auditors.
-### Build environment threats
+ - BuildEnv track assumes full trust in the software that comes with the build image or is installed at runtime.
-The SLSA [Build track] defines requirements for the provenance that is produced for the build artifacts.
-Trustworthiness of the build process largely depends on the trustworthiness of the [build environment] the build runs in.
-The Build track assumes full trust into the [Build Platform], and provides no requirements to verify integrity of the build environment.
-BuildEnv track intends to close this gap.
+ - Malicious software having privileged access within the build environment might be able to circumvent protections provided by the BuildEnv track.
-Build environment is bootstrapped from a [build image], which is expected to be an artifact of a SLSA build pipeline.
-Build platform verifies image security properties including provenance upon starting up the environment and makes evidence of the verification available to tenants or other auditors.
+ - Image providers should manage vulnerabilities in the image components to reduce the risks of such attacks, e.g. by using SLSA Dependency track and hardening images with mandatory access control (MAC) policies.
-BuildEnv track assumes full trust in the software that comes with the build image or is installed at runtime.
-Malicious software having privileged access within the build environment might be able to circumvent protections provided by the BuildEnv track.
-Image providers should manage vulnerabilities in the image components to reduce the risks of such attacks, e.g. by using SLSA Dependency track and hardening images with mandatory access control (MAC) policies.
-Control Plane may perform additional analysis of the image SBOM as it bootstraps the build environment.
+ - Control Plane may perform additional analysis of the image SBOM as it bootstraps the build environment.
Bootstrapping the build environment is a complex process, especially at higher SLSA levels.
+
+## Build environment threats
+
+### Threats and Build Levels
+
[Build L3] usually requires significant changes to existing build platforms to maintain ephemeral build environments.
+
It is not uncommon for the build platforms to rely on public cloud providers to manage the compute resources that power build environments.
+
+#### Trusted Computing Base (TCB) issues
+
This in turn significantly expands the attack surface because added build platform dependencies become part of the [TCB].
+
Cloud providers are big companies with complex infrastructure that often provide limited abilities to scope the context of trust and continuously validate it over time when using their services.
The BuildEnv track addresses build TCB size concerns at [BuildEnv L2] and [BuildEnv L3] levels.
+##### Trusted Computing Base Levels
+
[BuildEnv L1] level assumes full trust into the Build Platform including underlying [Compute Platform] (e.g., public cloud provider).
[BuildEnv L2] level adds capabilities for verifying the Compute Platform providing evidence that the build environment is bootstrapped from the expected image with the expected early boot components (e.g. UEFI firmware) provided by the Compute Platform.
@@ -131,6 +116,8 @@ The [SEV-SNP/TDX threat model] describes this level of trust reduction through t
L3 provides evidence of continuous integrity of the build environment for the whole lifetime.
TEE technologies are not infallible, so physical human access to hardware and side channel attacks are still a risk that is accepted at L3.
+### Build image lifetimes diagram
+
This diagram outlines the lifetime of a build image between its creation and use in bootstrapping a build environment.
A Build Image could be compromised at any stage of its lifetime.
Higher SLSA BuildEnv levels secure the build environment from larger classes of threats.
@@ -142,6 +129,8 @@ flowchart LR
ComputeProvider[[Compute Provider]] ---> |L3|BuildEnvironment[(Build Environment)]
+### Build images and threat levels
+
[BuildEnv L1] protects from threats that happened during the build image *distribution*, i.e. in between image creation and consumption (e.g., pulling image from a shared registry) by the Build Platform.
This covers the case of unauthorized modifications to the image as it is distributed (potentially via untrusted channels).
@@ -161,9 +150,67 @@ Build platforms MAY provide capabilities that let tenants perform remote attesta
However, for the Control Plane to be considered untrusted it should have no back-door access to the build environment (e.g. via SSH).
Besides, Control Plane provides input data to the build environment (i.e. build request message) and security risks associated with compromising inputs have to be considered as well.
-For the example threats refer to the [Build Threats] section.
+For the example threats, refer to the [Build Threats] section.
+
+## Build environment concept model
+
+The Build Environment (BuildEnv) track expands upon the
+[build model](threats-overview.md#build-model) by explicitly separating the
+build image and compute platform from the
+*abstract* build environment and build platform.
+
+
+
+### Build environment lifecycle diagram
+
+The above diagram shows how a typical build environment will go through the following lifecycle:
+
+1. *Build image creation*: A [build image producer](#build-image-producer)
+ creates different [build images](#build-image) through a dedicated build
+ process. For the SLSA BuildEnv track, the build image producer outputs
+ [provenance](terminology#provenance) describing this process.
+2. *Build environment instantiation*: The [hosted build platform](terminology#platform)
+ calls into the [host interface](#host-interface) to create a new instance
+ of a build environment from a given build image. The
+ [build agent](#build-agent) begins to wait for an incoming
+ [build dispatch](#build-dispatch).
+ For the SLSA BuildEnv track, the host interface in the compute platform
+ attests to the integrity of the environment's initial state during its
+ [boot process](#boot-process).
+3. *Build dispatch*: When the tenant dispatches a new build, the hosted
+ build platform assigns the build to a created build environment.
+ For the SLSA BuildEnv track, the build platform attests to the binding
+ between a build environment and [build ID](#build-id).
+4. *Build execution*: Finally, the build agent within the environment executes
+ the tenant's build definition.
+
-## BuildEnv levels
+
+## Build Environment Track Levels
+
+The SLSA Build Environment (BuildEnv) track describes increasing levels of
+integrity and trustworthiness of the provenance of a build's
+execution context. In this track, provenance describes how a build image
+was created, how the hosted build platform deployed a build image in its
+environment, and the compute platform they used.
+
+| Track/Level | Requirements | Focus | Trust Root
+| ----------- | ------------ | ----- | ----------
+| [BuildEnv L0] | (none) | (n/a) | (n/a)
+| [BuildEnv L1] | Signed build image provenance exists | Tampering during build image distribution | Signed build image provenance
+| [BuildEnv L2] | Attested build environment instantiation | Tampering via the build platform's control plane | The compute platform's host interface
+| [BuildEnv L3] | Hardware-attested build environment | Tampering via the compute platform's host interface | The compute platform's hardware
+
+> :warning:
+> The Build Environment track L1+ currently requires a [hosted] build platform.
+> A future version of this track may generalize requirements to cover bare-metal
+> build environments.
+
+> :grey_exclamation:
+> We may consider the addition of an L4 to the Build Environment track, which
+> covers hardware-attested runtime integrity checking during a build.
+
+## Build Environment level specifics
The primary purpose of the Build Environment (BuildEnv) track is to enable
auditing that a build was run in the expected [execution context].
@@ -389,6 +436,9 @@ host environment, even in the face of a compromised host interface
+
+
+
## Considerations for Distributed Builds
TODO
diff --git a/docs/spec/draft/build-provenance.md b/docs/spec/draft/build-provenance.md
index 920587c87..54e3eb1f4 100644
--- a/docs/spec/draft/build-provenance.md
+++ b/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
---
diff --git a/docs/spec/draft/build-requirements.md b/docs/spec/draft/build-requirements.md
index df9947d0a..8fcea1acb 100644
--- a/docs/spec/draft/build-requirements.md
+++ b/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.
---
diff --git a/docs/spec/draft/build-threats-mitigation.md b/docs/spec/draft/build-threats-mitigation.md
new file mode 100644
index 000000000..5e343235d
--- /dev/null
+++ b/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
+
+
+
diff --git a/docs/spec/draft/build-track-basics.md b/docs/spec/draft/build-track-basics.md
index eccbc36b6..0fc994e92 100644
--- a/docs/spec/draft/build-track-basics.md
+++ b/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.
---
diff --git a/docs/spec/draft/build-verification.md b/docs/spec/draft/build-verification.md
new file mode 100644
index 000000000..54016c50c
--- /dev/null
+++ b/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
+
+