SLSA compliance

Last updated: Nov 4, 2026

The SLSA (Supply-chain Levels for Software Artifacts) framework helps organizations measure the level of assurance that their software artifacts contain and use only what they intended (integrity). To do this, it makes sure that no one can tamper with the full build and release process. It also makes sure that no one can tamper with the sources and dependencies of this process.

This document uses version 0.1 of the specification.

The current SLSA level of Fluid Attacks is 2. This table shows the level that Fluid Attacks gets in each requirement:

Requirement	Level
Source - Version controlled	4
Source - Verified history	4
Source - Retained indefinitely	4
Source - Two person reviewed	3
Build - Scripted build	4
Build - Build service	4
Build - Build as code	4
Build - Ephemeral environment	4
Build - Isolated	2
Build - Parameter-less	4
Build - Hermetic	4
Build - Reproducible	3
Provenance - Available	4
Provenance - Authenticated	4
Provenance - Service generated	4
Provenance - Non-falsifiable	4
Provenance - Dependencies complete	4
Common - Security	4
Common - Access	3
Common - Superusers	3

This is how the SLSA definitions map to the infrastructure of Fluid Attacks:

Platform: GitLab CI/CD and the Nix package manager
Build service: GitLab CI/CD and related infrastructure
Build: A Nix derivation
Environment: A sandbox that does a chroot into an empty temporary directory. It gives private versions of /proc, /dev, /dev/shm, and /dev/pts. It uses a private PID, mount, network, IPC, and UTS namespace to isolate itself from other processes in the system.
Steps: Instructions in the related Makes configuration files. These files use the Nix programming language and shell scripts, and the source keeps them as versioned code.

Source requirements

Version controlled

A version control system tracks each change to the source. This system satisfies these requirements:

Change history: A record of the history of changes in the revision exists. Each change contains the identities of the uploader and reviewers (if applicable), and the timestamps of the reviews (if applicable) and of the submission. It also contains the description and justification of the change, the content of the change, and the parent revisions.
Immutable reference: There is a way to reference a specific, immutable revision indefinitely.

Verified history

Each change in the history of the revision must be in a merge request.

To create or approve a merge request, the author and the reviewer must use strong authentication in GitLab. The authentication process requires 2FA, and the merge request records the dates of the change.

Only users that a platform Admin gave access to can create or review merge requests. Example: MR 28742.

Retained indefinitely

Fluid Attacks keeps the revision and its change history indefinitely. No one can delete or change them. Not even multi-party approval can allow this.

At this time, no legal requirement prevents Fluid Attacks from the indefinite storage of its change history, and no obliteration policy applies.

Two person reviewed

A minimum of one trusted individual must approve each change in the history of the revision before submission. Also, each of these trusted individuals must use 2FA to log in to the platform before they give approval.

Build requirements

Scripted build

GitLab CI/CD and Nix fully define all the build steps.

Manual commands are not necessary to start the build script. A new build starts automatically each time a developer pushes new changes to the repository. Examples: 1, 2, and 3.

Build service

All build steps run on GitLab CI/CD.

Build as code

Fluid Attacks stores and versions all the build steps in the Git repository: .gitlab-ci.yml.

Ephemeral environment

The build service of Fluid Attacks runs each build step in a container that it provisions only for that build. It does not use a container from a previous build again. Example: container image.

Also, the Nix package manager gives an ephemeral environment to each derivation.

Isolated

The build service of Fluid Attacks uses containerization technologies. Thus, the build steps run in an isolated environment, without influence from concurrent build instances. On the component runners (exploits, integrates, runs, sifts, skims, and views), the builds share a persistent Nix store with previous builds on the same machine. On the other runners, previous builds have no influence.

The Nix package manager executes the builds. It prevents access from builds to any external environment variables, network resources, sockets, or paths in the file system. It gives private versions of /proc, /dev, /dev/shm, and /dev/pts. It uses a private PID, mount, network, IPC, and UTS namespace. Thus, it isolates the build from other builds that run at the same time in the system.

Input-addressed build caches make the pipeline faster.

Parameter-less

User parameters cannot affect the build output, except the build entry point and the top-level source location.

To change the build output, a change to the source code must occur first.

Hermetic

The Nix package manager executes the builds. It prevents access from builds to any external environment variables, network resources, sockets, or paths in the file system.

Fluid Attacks fully declares all transitive build steps, sources, and dependencies before the build, with immutable references.

The Nix package manager does these actions:

It fetches all the declared artifacts into a trusted control plane (the /nix/store).
It mounts into the build sandbox the specific /nix/store paths that the build requires.
It lets a build fetch artifacts over the network if, and only if, the build specifies the expected artifact integrity.
It validates the integrity of each artifact before a build can use it. If the verification fails, the build fails.
It denies network connectivity if the build does not specify an expected hash.

Reproducible

All the build scripts of Fluid Attacks are intended to be reproducible. The reproducibility guarantees of these build scripts are the guarantees of the Nix package manager. If a build is not reproducible, Fluid Attacks does not explicitly define why.

Provenance requirements

In SLSA, "Provenance" is verifiable information about software artifacts that describes where, when, and how the build produced them.

The purpose of this requirement is to protect consumers from the use of a compromised package:

At Fluid Attacks, consumers and builders are the same entity. Fluid Attacks does not use artifacts or packages for distribution. Consumers use Makes, a source identifier, and the target artifact identifier. Then, the Nix package manager builds all the sources, dependencies, and intermediate artifacts locally in the consumer machine. It follows the steps and environment that the source defines as code.

Available

Makes produces the provenance. The build service shows it as a JSON document together with the artifacts that the build produces.

Only builds that produce artifacts generate provenance. If a build does not produce artifacts, there is nothing to verify the provenance of.

Authenticated

Users can download the provenance from the build service directly. The authenticity of the provenance comes from this fact. This authenticity is as strong as the security of the Build and Source Requirements.

The logs show the integrity of the provenance, and Makes generates it.

Service generated

The build service shows the data in the provenance, and Makes generates it.

Regular users of the service cannot inject or change the contents. The configuration of a build fully determines and automates the build, and this configuration comes directly from the source.

Non-falsifiable

The users of the build service cannot falsify the provenance:

There is no secret material to show the non-falsifiable nature of the provenance.
If such secret material existed, it would not be available to the build steps, because builds run in a hermetic environment.
The build service generates each field in the provenance in a trusted control plane. The build configuration fully defines this control plane, and this configuration comes directly from the source. Thus, it is as secure as the source.

Dependencies complete

The provenance contains all the dependencies that were available during the build steps. The hermetic builds guarantee this. For a successful build, the build must declare all its dependencies. Thus, the build tools (Makes and Nix), which fetched them at build time, know that they exist.