minor changes

Author: kahboom

docs/compliance/SLSA.md

@@ -1,16 +1,16 @@
 ---
 slug: "/slsa-supply-chain-levels-compliance-for-software-artifacts"
 title: "SLSA ・ Supply-chain Levels for Software Artifacts"
-sidebar_label: ""
+sidebar_label: "SLSA"
 ---
 
 # SLSA
 
 **Supply-chain Levels for Software Artifacts**, or **[SLSA](https://slsa.dev/)** _(pronounced "salsa")_, is a vendor-neutral security framework that provides guidance on building and delivering software securely. Supported by the [Open Source Software Security Foundation](https://openssf.org/), SLSA consists of a specification that developers can reference when identifying areas of potential improvement. It was [created by Google in 2021](https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html) to help software developers fortify their supply chain security by incorporating the best industry practices end-to-end. It also enables consumers to better evaluate the software they adopt, before they adopt it.
 
-SLSA is divided into different tracks and [levels](https://slsa.dev/spec/v1.0/levels), each expanding on the previous. The idea is that, as your security posture matures, you make your way up through the different levels, much like a ladder.
+SLSA is divided into four different **[levels](https://slsa.dev/spec/v1.0/levels)**, which are further broken up into their own tracks, each expanding on the previous. Each level within a track measures a particular aspect of supply chain security. The idea is that, as your security posture matures, you work your way up through the different levels, like a ladder.
 
-## SLSA Level 1: Build Basics
+## SLSA Level 0: Build Basics
 
 The main focus of Level 1 is on automation, as manual processes are error-prone. It requires the build process to be fully scripted, meaning no manual, ad hoc commands. This ensures the builds are at least reproducible.
 
@@ -20,16 +20,15 @@ SLSA 1 is achievable for many teams with minimal effort—if you're using CI/CD
 
 :::
 
-
-## SLSA Level 2: Provenance Proofs
+## SLSA Level 1: 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.
 
-## SLSA Level 3: Tamper Resistance
+## SLSA Level 2: Tamper Resistance
 
 Builds must be performed in a secure environment that prevents tampering. This involves using isolated, authenticated systems (e.g. hardened CI/CD environments).
 
-## SLSA Level 4: Fully Fortified
+## SLSA Level 3: Fully Fortified
 
 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.
 

docs/scrollycoding.mdx

@@ -4,13 +4,15 @@ slug: "/what-is-an-sbom-software-bill-of-materials-and-why-does-it-matter"
 ---
 import { Scrollycoding } from "/src/components/scrollycoding";
 
-# What is a Software Bill of Materials (SBOM)?
+# Software Bill of Materials (SBOM)
 
 In recent years, the relevance of SBOMs has increased rapidly, with regulatory mandates like PCI DSS and other government requirements specifically requiring SBOM adoption for compliance.
 
+## What is an SBOM?
+
 A **Software Bill of Materials**, or **SBOM**, is an inventory file that lists all components within a piece of software, including any dependencies. Those components can include anything from open source libraries, APIs, licenses, and known vulnerabilities.
 
-## Why SBOMs are important in vulnerability management
+## Why are SBOMs in vulnerability management?
 
 The applications we build and use everyday ship with many dependencies. Those dependencies are then likely have _their own_ dependencies, which, in turn, might consist of _their_ own dependencies, and so on. When you consider that any single one of those dependencies can be exploited, it's easy to see why it's important that we are able to track and monitor them.
 
@@ -181,7 +183,7 @@ One of the most critical use cases for SBOMs is in enhancing software supply cha
 
 ## The Future of SBOMs
 
-Governments and organizations worldwide are beginning to mandate SBOM usage. For example, the U.S. Executive Order on Improving the Nation’s Cybersecurity calls for SBOMs in critical software development. As these requirements grow, SBOMs are poised to become a standard practice in software development and deployment.
+Governments and organizations worldwide are beginning to mandate SBOM usage. For example, the U.S. Executive Order on Improving the Nation's Cybersecurity calls for SBOMs in critical software development. As these requirements grow, SBOMs are poised to become a standard practice in software development and deployment.
 
-An SBOM is more than just a technical document; it’s a cornerstone of modern software security and transparency. By adopting SBOMs, organizations can improve security, ensure compliance, and build trust with users and stakeholders. As software ecosystems grow more complex, SBOMs will play an indispensable role in maintaining a secure and resilient digital world.
+An SBOM is more than just a technical document; it's a cornerstone of modern software security and transparency. By adopting SBOMs, organizations can improve security, ensure compliance, and build trust with users and stakeholders. As software ecosystems grow more complex, SBOMs will play an indispensable role in maintaining a secure and resilient digital world.