You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
# SLSA: Your Blueprint for Securing the Software Supply Chain
8
8
9
-
**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.
9
+
Ever wonder how to stop supply chain attacks like SolarWinds or Log4Shell in their tracks? Enter **Supply-chain Levels for Software Artifacts**, or **[SLSA](https://slsa.dev/)**_(pronounced "salsa")_. This framework is your recipe for hardening the software you build, deliver, and consume—step by step.
10
10
11
-
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.
11
+
[Created by Google](https://security.googleblog.com/2021/06/introducing-slsa-end-to-end-framework.html) and supported by the [Open Source Software Security Foundation](https://openssf.org/), SLSA is the industry's answer to supply chain chaos. With four progressive levels, it helps you secure your software artifacts from tampering and build trust with end users.
12
12
13
-
## SLSA Level 0: Build Basics
13
+
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.
14
+
15
+
## Why does SLSA matter?
16
+
17
+
Software supply chains are more vulnerable than ever:
18
+
- Dependencies sneak in unnoticed.
19
+
- Build environments are ripe for tampering.
20
+
- Provenance (the “who, what, where” of your code) is often nonexistent.
21
+
22
+
SLSA fixes these issues by providing a ladder of security maturity. Whether you're a developer or an organization, each level of SLSA improves your security posture.
23
+
24
+
## SLSA Levels & Tracks
25
+
26
+
SLSA is divided into four different **[levels](https://slsa.dev/spec/v1.0/levels)**. Each level within a track measures a particular aspect of supply chain security (e.g. build, source, dependencies).
27
+
28
+
Levels are further broken up into their own tracks, each expanding on the previous. The idea is that, as your security posture matures, you work your way up through the different levels, like a ladder.
29
+
30
+
-**Levels** define the overall maturity of your security practices.
31
+
-**Tracks** identify specific areas of improvement (i.e. "source" ensures code integrity, while "build" ensures artifact integrity).
32
+
33
+
34
+
### SLSA Level 0: The Starting Line
35
+
36
+
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.
37
+
38
+
The build process might be manual, dependencies aren't tracked, and there's no way to verify the integrity of your artifacts.
39
+
40
+
- Risk: Tampering is undetectable, and no one knows how your software was built.
41
+
- Goal: Recognize this as the starting point and commit to improvement.
42
+
43
+
### SLSA Level 1
14
44
15
45
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.
16
46
47
+
Requirements:
48
+
- A defined build process (e.g. CI/CD pipelines).
49
+
- Artifacts can be recreated reliably.
50
+
51
+
Example: Running `make` commands directly on your local machine and manually uploading binaries to a server.
52
+
53
+
Example tools might include Jenkins, GitHub Actions, or GitLab CI.
54
+
17
55
:::tip[Did you know?]
18
56
19
-
SLSA 1 is achievable for many teams with minimal effort—if you're using CI/CD pipelines, you might already be there!
57
+
SLSA L1 is achievable for many teams with minimal effort—if you're using CI/CD pipelines, you might already be there!
20
58
21
59
:::
22
60
23
-
## SLSA Level 1: Provenance Proofs
61
+
SLSA L1 is a means to an end, and should be seen as a stepping stone towards improving your overall approach to security.
62
+
63
+
64
+
### SLSA Level 2: Provenance Proofs
24
65
25
66
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.
26
67
27
-
## SLSA Level 2: Tamper Resistance
68
+
Builds must be performed in a secure environment that prevents tampering, which involves using isolated, authenticated systems (e.g. hardened CI/CD environments).
69
+
70
+
### SLSA Level 3: Fully Fortified
28
71
29
-
Builds must be performed in a secure environment that prevents tampering. This involves using isolated, authenticated systems (e.g. hardened CI/CD environments).
72
+
This is the gold standard. At Level 3:
73
+
- Builds are hermetic (completely isolated from the outside world).
74
+
- Dependencies are verified and controlled.
75
+
- Build environments are hardened to prevent tampering.
30
76
31
-
## SLSA Level 3: Fully Fortified
77
+
Additional practices include:
78
+
- Two-person review for every change.
79
+
- Strict control over source and dependencies.
80
+
- Requirements:
81
+
- All Level 2 controls.
82
+
- Builds must be tamper-proof and reproducible in a hermetic environment.
83
+
- Example Tools:
84
+
- Containerized builds (e.g., using Docker or Bazel).
85
+
- Cloud-native build systems like GCP Cloud Build or AWS CodeBuild.
32
86
33
87
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.
@@ -12,7 +13,7 @@ In recent years, the relevance of SBOMs has increased rapidly, with regulatory m
12
13
13
14
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.
14
15
15
-
## Why are SBOMs in vulnerability management?
16
+
## Why are SBOMs important in vulnerability management?
16
17
17
18
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.
0 commit comments