From 421ff2b10f388cb85022e4c5a8440bb6daf50c04 Mon Sep 17 00:00:00 2001 From: Zachariah Cox Date: Wed, 4 Dec 2024 17:13:40 -0500 Subject: [PATCH] remove disclaimers about the lack of a source track. link to the source track from the threats page. --- docs/spec/draft/about.md | 10 +++------- docs/spec/draft/future-directions.md | 16 ++++------------ docs/spec/draft/threats.md | 6 +++++- 3 files changed, 12 insertions(+), 20 deletions(-) diff --git a/docs/spec/draft/about.md b/docs/spec/draft/about.md index b27a90f03..27fed2f11 100644 --- a/docs/spec/draft/about.md +++ b/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 diff --git a/docs/spec/draft/future-directions.md b/docs/spec/draft/future-directions.md index 699bf39df..54a3e61d9 100644 --- a/docs/spec/draft/future-directions.md +++ b/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. diff --git a/docs/spec/draft/threats.md b/docs/spec/draft/threats.md index 14c36a27e..55cbecfda 100644 --- a/docs/spec/draft/threats.md +++ b/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.