fix: fix various typos in specification files

docs/spec/v0.1/provenance.md

@@ -248,7 +248,7 @@ of the other top-level fields, such as `subject`, see [Statement]._
 `metadata.completeness.arguments` _boolean, optional_
 
 > If true, the `builder` claims that `recipe.arguments` is complete, meaning
-> that all external inputs are propertly captured in `recipe`.
+> that all external inputs are properly captured in `recipe`.
 
 <a id="metadata.completeness.environment"></a>
 `metadata.completeness.environment` _boolean, optional_

docs/spec/v0.1/threats.md

@@ -682,7 +682,7 @@ ad-hoc analysis, and can complement source-based typosquatting solutions.
 
 ## Availability threats
 
-An availabiliy threat is a potential for an adversary to deny someone from
+An availability threat is a potential for an adversary to deny someone from
 reading a source and its associated change history, or from building a package.
 
 <details><summary>(A)(B) Delete the code <span>(SLSA 3)</span></summary>
@@ -704,11 +704,11 @@ attestation showing that some system, such as GitHub, ensures retention and
 availability.
 
 </details>
-<details><summary>(E) A dependency becomes temporarily or permenantly unavailable to the build process <span>(out of scope)</span></summary>
+<details><summary>(E) A dependency becomes temporarily or permanently unavailable to the build process <span>(out of scope)</span></summary>
 
 *Threat:* Unable to perform a build with the intended dependencies.
 
-*Mitigation:* **Outside the scope of SLSA.** That said, some solutions to support Hermetic and Reproducable builds may also reduce the impact of this threat.
+*Mitigation:* **Outside the scope of SLSA.** That said, some solutions to support Hermetic and Reproducible builds may also reduce the impact of this threat.
 <sup>[[Hermetic] [Reproducible] @ SLSA 4]</sup>
 
 </details>

docs/spec/v0.2/provenance.md

@@ -260,7 +260,7 @@ of the other top-level fields, such as `subject`, see [Statement]._
 `metadata.completeness.parameters` _boolean, optional_
 
 > If true, the `builder` claims that `invocation.parameters` is complete, meaning
-> that all external inputs are propertly captured in `invocation.parameters`.
+> that all external inputs are properly captured in `invocation.parameters`.
 
 <a id="metadata.completeness.environment"></a>
 `metadata.completeness.environment` _boolean, optional_

docs/spec/v1.0-rc1/requirements.md

@@ -90,7 +90,7 @@ choose a builder capable of producing Build Level 3 provenance.
 
 The producer MUST build their artifact in a consistent
 manner such that verifiers can form expectations about the build process. In
-some implemenatations, the producer MAY provide explicit metadata to a verifier
+some implementations, the producer MAY provide explicit metadata to a verifier
 about their build process. In others, the verifier will form their expectations
 implicitly (e.g. trust on first use).
 

docs/spec/v1.0-rc2/principles.md

@@ -18,7 +18,7 @@ expensive manual work, and each trusted system expands the attack surface of the
 supply chain. Verifying that an artifact is produced by a trusted system,
 though, is easy to automate.
 
-To simultaniously scale and reduce attack surfaces, it is most efficient to trust a limited
+To simultaneously scale and reduce attack surfaces, it is most efficient to trust a limited
 numbers of systems and then automate verification of the artifacts produced by those systems.
 The attack surface and work to establish trust does not scale with the number of artifacts produced,
 as happens when artifacts each use a different trusted system.

docs/spec/v1.0-rc2/requirements.md

@@ -103,7 +103,7 @@ choose a builder capable of producing Build Level 3 provenance.
 
 The producer MUST build their artifact in a consistent
 manner such that verifiers can form expectations about the build process. In
-some implemenatations, the producer MAY provide explicit metadata to a verifier
+some implementations, the producer MAY provide explicit metadata to a verifier
 about their build process. In others, the verifier will form their expectations
 implicitly (e.g. trust on first use).
 

docs/spec/v1.0-rc2/threats.md

@@ -187,7 +187,7 @@ producer.
 
 The SLSA Build track mitigates these threats when the consumer
 [verifies artifacts](verifying-artifacts.md) against expectations, confirming
-that the artifact they recieved was built in the expected manner.
+that the artifact they received was built in the expected manner.
 
 ### (E) Compromise build process
 

docs/spec/v1.0/faq.md

@@ -87,7 +87,7 @@ Jenkins plugin.
 
 ## Q. What is the difference between a build platform, system, and service?
 
-Build platform and build system have been used interchangably in the past. With
+Build platform and build system have been used interchangeably in the past. With
 the v1.0 specification, however, there has been a unification around the term
 platform as indicated in the [Terminology](terminology.md). The use of the word
 `system` still exists related to software and services within the build platform

docs/spec/v1.0/requirements.md

@@ -102,7 +102,7 @@ choose a builder capable of producing Build Level 3 provenance.
 
 The producer MUST build their artifact in a consistent
 manner such that verifiers can form expectations about the build process. In
-some implemenatations, the producer MAY provide explicit metadata to a verifier
+some implementations, the producer MAY provide explicit metadata to a verifier
 about their build process. In others, the verifier will form their expectations
 implicitly (e.g. trust on first use).
 

docs/spec/v1.0/threats.md

@@ -189,7 +189,7 @@ producer.
 
 The SLSA Build track mitigates these threats when the consumer
 [verifies artifacts](verifying-artifacts.md) against expectations, confirming
-that the artifact they recieved was built in the expected manner.
+that the artifact they received was built in the expected manner.
 
 ### (E) Compromise build process
 

docs/spec/v1.1/faq.md

@@ -87,7 +87,7 @@ Jenkins plugin.
 
 ## Q. What is the difference between a build platform, system, and service?
 
-Build platform and build system have been used interchangably in the past. With
+Build platform and build system have been used interchangeably in the past. With
 the v1.0 specification, however, there has been a unification around the term
 platform as indicated in the [Terminology](terminology.md). The use of the word
 `system` still exists related to software and services within the build platform

docs/spec/v1.1/requirements.md

@@ -102,7 +102,7 @@ choose a builder capable of producing Build Level 3 provenance.
 
 The producer MUST build their artifact in a consistent
 manner such that verifiers can form expectations about the build process. In
-some implemenatations, the producer MAY provide explicit metadata to a verifier
+some implementations, the producer MAY provide explicit metadata to a verifier
 about their build process. In others, the verifier will form their expectations
 implicitly (e.g. trust on first use).
 

docs/spec/v1.1/threats.md

@@ -5,7 +5,7 @@ description: A comprehensive technical analysis of supply chain threats and thei
 
 What follows is a comprehensive technical analysis of supply chain threats and
 their corresponding mitigations in SLSA. For an introduction to the
-supply chain threats that SLSA protects agains, see [Supply chain threats].
+supply chain threats that SLSA protects against, see [Supply chain threats].
 
 The examples on this page are meant to:
 
@@ -189,7 +189,7 @@ producer.
 
 The SLSA Build track mitigates these threats when the consumer
 [verifies artifacts](verifying-artifacts.md) against expectations, confirming
-that the artifact they recieved was built in the expected manner.
+that the artifact they received was built in the expected manner.
 
 ### (E) Compromise build process