slsa-framework · lehors · Apr 26, 2024 · Apr 26, 2024
diff --git a/...-slsa-github-worfklows-container-based.md → ...-slsa-github-workflows-container-based.md b/...-slsa-github-worfklows-container-based.md → ...-slsa-github-workflows-container-based.md
diff --git a/docs/_posts/2023-08-28-bring-your-own-builder-github.md b/docs/_posts/2023-08-28-bring-your-own-builder-github.md
@@ -4,9 +4,9 @@ author: "Andres Almiray (JReleaser), Adam Korczynski (Ada Logics), Philip Harris
 is_guest_post: false
 ---
 
-It has been an exciting quarter for supply chain security and SLSA, with the release of the [SLSA v1.0 specification](2023-04-19-slsa-v1-final.md), [SLSA provenance support for npm](https://github.blog/2023-04-19-introducing-npm-package-provenance/), and the announcement of new SLSA Level 3 builders for [Node.js](2023-05-11-bringing-improved-supply-chain-security-to-the-nodejs-ecosystem.md) and [containers](2023-06-13-slsa-github-worfklows-container-based.md)!
+It has been an exciting quarter for supply chain security and SLSA, with the release of the [SLSA v1.0 specification](2023-04-19-slsa-v1-final.md), [SLSA provenance support for npm](https://github.blog/2023-04-19-introducing-npm-package-provenance/), and the announcement of new SLSA Level 3 builders for [Node.js](2023-05-11-bringing-improved-supply-chain-security-to-the-nodejs-ecosystem.md) and [containers](2023-06-13-slsa-github-workflows-container-based.md)!
 
-SLSA already provides and maintains official builders for [Go](2022-06-20-slsa-github-workflows.md), [Node.js](2023-05-11-bringing-improved-supply-chain-security-to-the-nodejs-ecosystem.md) and [Container](2023-06-13-slsa-github-worfklows-container-based.md) based projects. But what if you don't use any of these languages or use custom tooling that isn't supported by the official builders?
+SLSA already provides and maintains official builders for [Go](2022-06-20-slsa-github-workflows.md), [Node.js](2023-05-11-bringing-improved-supply-chain-security-to-the-nodejs-ecosystem.md) and [Container](2023-06-13-slsa-github-workflows-container-based.md) based projects. But what if you don't use any of these languages or use custom tooling that isn't supported by the official builders?
 
 To empower the community to create their own provenance builders and leverage the secure architecture of the official SLSA builders we are releasing the ["Build Your Own Builder" (BYOB) framework](https://github.com/slsa-framework/slsa-github-generator/tree/main#build-your-own-builder) for GitHub Actions. This makes it easy to take an existing GitHub Action (e.g. [JReleaser](https://jreleaser.org/)) and make it produce [SLSA Build Level 3 provenance](/spec/v1.0/requirements#provenance-generation).
 

diff --git a/docs/spec-stages.md b/docs/spec-stages.md
@@ -63,7 +63,7 @@ for other considerations related to an
 This stage indicates that the specification is no longer maintained.
 It has been either rendered obsolete by a newer version or
 abandoned for some reason. The status of the document may provide
-additional information and point to the new document to use intead if
+additional information and point to the new document to use instead if
 there is one.
 
 ## Versioning

diff --git a/docs/spec/v0.1/provenance.md b/docs/spec/v0.1/provenance.md
@@ -428,7 +428,7 @@ Here `entryPoint` references the `filename` from the CloudBuild
   // ... at the path path/to/cloudbuild.yaml.
   "entryPoint": "path/to/cloudbuild.yaml",
   // The only possible user-defined parameters that can affect a BuildTrigger
-  // are the subtitutions in the BuildTrigger.
+  // are the substitutions in the BuildTrigger.
   "arguments": {
     "substitutions": {...}
   }

diff --git a/docs/spec/v0.1/requirements.md b/docs/spec/v0.1/requirements.md
@@ -63,7 +63,7 @@ _○ = REQUIRED unless there is a justification_
 ## Definitions
 
 > See also [Terminology](terminology.md) for general SLSA concepts. The
-> defintions below are only used in this document.
+> definitions below are only used in this document.
 
 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be

diff --git a/docs/spec/v0.1/use-cases.md b/docs/spec/v0.1/use-cases.md
@@ -43,7 +43,7 @@ Example ways an organization might use SLSA internally:
 -   A large company uses SLSA to require two person review for every production
     change, scalably across hundreds or thousands of employees/teams.
 -   An open source project uses SLSA to ensure that compromised credentials
-    cannot be abused to release an unofficial package to a package repostory.
+    cannot be abused to release an unofficial package to a package repository.
 
 **Case study:** [Google (Binary Authorization for Borg)](https://cloud.google.com/docs/security/binary-authorization-for-borg)
 

diff --git a/docs/spec/v0.2/provenance.md b/docs/spec/v0.2/provenance.md
@@ -517,7 +517,7 @@ Here `entryPoint` references the `filename` from the CloudBuild
     "digest": {"sha1": "abc..."}
   },
   // The only possible user-defined parameters that can affect a BuildTrigger
-  // are the subtitutions in the BuildTrigger.
+  // are the substitutions in the BuildTrigger.
   "parameters": {
     "substitutions": {...}
   }

diff --git a/docs/spec/v1.0-rc1/use-cases.md b/docs/spec/v1.0-rc1/use-cases.md
@@ -43,7 +43,7 @@ Example ways an organization might use SLSA internally:
 -   A large company uses SLSA to require two person review for every production
     change, scalably across hundreds or thousands of employees/teams.
 -   An open source project uses SLSA to ensure that compromised credentials
-    cannot be abused to release an unofficial package to a package repostory.
+    cannot be abused to release an unofficial package to a package repository.
 
 **Case study:** [Google (Binary Authorization for Borg)](https://cloud.google.com/docs/security/binary-authorization-for-borg)
 

diff --git a/docs/spec/v1.0-rc2/future-directions.md b/docs/spec/v1.0-rc2/future-directions.md
@@ -1,6 +1,6 @@
 ---
 title: Future directions
-description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versios to re-introduce these notions and add other additional aspects of automatable supply chain security.
+description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versions to re-introduce these notions and add other additional aspects of automatable supply chain security.
 ---
 
 The initial [draft version (v0.1)] of SLSA had a larger scope including

diff --git a/docs/spec/v1.0-rc2/levels.md b/docs/spec/v1.0-rc2/levels.md
@@ -28,7 +28,7 @@ tracks without invalidating previous levels.
 | [Build L3]  | Hardened build service | Tampering during the build
 
 <!-- For comparison: a future Build L4's focus might be reproducibility or
-hermeticity or completness of provenance -->
+hermeticity or completeness of provenance -->
 
 > Note: The [previous version] of the specification used a single unnamed track,
 > SLSA 1–4. For version 1.0 the Source aspects were removed to focus on the

diff --git a/docs/spec/v1.0-rc2/use-cases.md b/docs/spec/v1.0-rc2/use-cases.md
@@ -43,7 +43,7 @@ Example ways an organization might use SLSA internally:
 -   A large company uses SLSA to require two person review for every production
     change, scalably across hundreds or thousands of employees/teams.
 -   An open source project uses SLSA to ensure that compromised credentials
-    cannot be abused to release an unofficial package to a package repostory.
+    cannot be abused to release an unofficial package to a package repository.
 
 **Case study:** [Google (Binary Authorization for Borg)](https://cloud.google.com/docs/security/binary-authorization-for-borg)
 

diff --git a/docs/spec/v1.0/future-directions.md b/docs/spec/v1.0/future-directions.md
@@ -1,6 +1,6 @@
 ---
 title: Future directions
-description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versios to re-introduce these notions and add other additional aspects of automatable supply chain security.
+description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versions to re-introduce these notions and add other additional aspects of automatable supply chain security.
 ---
 
 The initial [draft version (v0.1)] of SLSA had a larger scope including

diff --git a/docs/spec/v1.0/levels.md b/docs/spec/v1.0/levels.md
@@ -28,7 +28,7 @@ tracks without invalidating previous levels.
 | [Build L3]  | Hardened build platform | Tampering during the build
 
 <!-- For comparison: a future Build L4's focus might be reproducibility or
-hermeticity or completness of provenance -->
+hermeticity or completeness of provenance -->
 
 > Note: The [previous version] of the specification used a single unnamed track,
 > SLSA 1–4. For version 1.0 the Source aspects were removed to focus on the

diff --git a/docs/spec/v1.1/future-directions.md b/docs/spec/v1.1/future-directions.md
@@ -1,6 +1,6 @@
 ---
 title: Future directions
-description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versios to re-introduce these notions and add other additional aspects of automatable supply chain security.
+description: The initial draft version (v0.1) of SLSA had a larger scope including protections against tampering with source code and a higher level of build integrity (Build L4). This page collects some early thoughts on how SLSA **might** evolve in future versions to re-introduce these notions and add other additional aspects of automatable supply chain security.
 ---
 
 The initial [draft version (v0.1)] of SLSA had a larger scope including

diff --git a/docs/spec/v1.1/levels.md b/docs/spec/v1.1/levels.md
@@ -28,7 +28,7 @@ tracks without invalidating previous levels.
 | [Build L3]  | Hardened build platform | Tampering during the build
 
 <!-- For comparison: a future Build L4's focus might be reproducibility or
-hermeticity or completness of provenance -->
+hermeticity or completeness of provenance -->
 
 > Note: The [previous version] of the specification used a single unnamed track,
 > SLSA 1–4. For version 1.0 the Source aspects were removed to focus on the