fix: slsa page

Author: kahboom

docs/compliance/SLSA.md

@@ -33,12 +33,11 @@ Levels are further broken up into their own tracks, each expanding on the previo
 
 ### SLSA Level 0: The Starting Line
 
-This is the Wild West of software development, where most software starts. No automation, no reproducibility, no trust. It’s like baking a cake without writing down the recipe—you might get something tasty once, but good luck doing it again the same way.
+This is the Wild West of software development, where most software starts. No automation, no reproducibility, no trust. It's a bit like baking a cake without writing down the recipe—you might get something tasty once, but good luck doing it again the same way.
 
-The build process might be manual, dependencies aren't tracked, and there's no way to verify the integrity of your artifacts.
+The build process might be manual, dependencies aren't tracked, and there's no way to verify the integrity of your artifacts. The risk here is that tampering is undetectable, and no one knows how your software was built. Ultimately, however, the goal is to recognize this as the starting point, and commit to improvement.
 
-- Risk: Tampering is undetectable, and no one knows how your software was built.
-- Goal: Recognize this as the starting point and commit to improvement.
+An example at this level might be running `make` commands directly on your local machine and manually uploading binaries to a server.
 
 ### SLSA Level 1
 
@@ -48,8 +47,6 @@ Requirements:
 - A defined build process (e.g. CI/CD pipelines).
 - Artifacts can be recreated reliably.
 
-Example: Running `make` commands directly on your local machine and manually uploading binaries to a server.
-
 Example tools might include Jenkins, GitHub Actions, or GitLab CI.
 
 :::tip[Did you know?]
@@ -58,33 +55,22 @@ SLSA L1 is achievable for many teams with minimal effort—if you're using CI/CD
 
 :::
 
-SLSA L1 is a means to an end, and should be seen as a stepping stone towards improving your overall approach to security. 
+SLSA L1 is a means to an end, and should be seen as a stepping stone towards improving your overall approach to security.
 
 
 ### SLSA Level 2: Provenance Proofs
 
-Level 2 introduces the concept of [provenance](/what-is-software-provenance-and-why-is-it-important-for-security), a verifiable statement of what, how, and where something was built. Build systems must generate signed provenance documents.
+Level 2 introduces the concept of [provenance](/what-is-software-provenance-and-why-is-it-important-for-security), a verifiable statement of _what_, _how_, and _where_ something was built.
 
-Builds must be performed in a secure environment that prevents tampering, which involves using isolated, authenticated systems (e.g. hardened CI/CD environments).
+Build systems must generate signed provenance documents. Builds must also be performed in a secure environment that prevents tampering, which involves using isolated, authenticated systems (e.g. hardened CI/CD environments).
 
 ### SLSA Level 3: Fully Fortified
 
-This is the gold standard. At Level 3:
-- Builds are hermetic (completely isolated from the outside world).
-- Dependencies are verified and controlled.
-- Build environments are hardened to prevent tampering.
-
-Additional practices include:
-- Two-person review for every change.
-- Strict control over source and dependencies. 
-- Requirements:
-  - All Level 2 controls.
-  - Builds must be tamper-proof and reproducible in a hermetic environment. 
-- Example Tools:
-  - Containerized builds (e.g., using Docker or Bazel).
-  - Cloud-native build systems like GCP Cloud Build or AWS CodeBuild.
-
-This level adds two-person review for all changes and hermetic builds, meaning builds are completely isolated from the outside world. Every dependency must be verified.
+SLSA L3 is the gold standard. This level adds a two-person review for any changes and requires reproducible tamper-proof builds in a hermetic environment (meaning builds are completely isolated from the outside world). Each and every dependency must be verified. At Level 3:
 
+- Builds are hermetic
+- Dependencies are verified and controlled
+- Build environments are hardened to prevent tampering
 
+Example tools at this level might include containerized builds using, for example, Docker. Cloud-native build systems like GCP Cloud Build or AWS CodeBuild are also popular options.