SLSA compliance

Last updated: Mar 24, 2026

The SLSA (Supply-chain Levels for Software Artifacts) framework helps organizations measure the level of assurance that the software artifacts they produce actually contain and use what they intended (integrity), by ensuring that the whole build and release process, and all of the involved sources and dependencies, cannot be tampered with.

In this document, we use version 0.1 of the specification.

Our current SLSA level is 2. The following is a detail of the levels achieved on each of the requirements:

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

For clarity, this is how SLSA definitions map into our infrastructure:

Source: Git repository at fluidattacks/universe
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 chroot into an empty temporary directory, provides private versions of /proc, /dev, /dev/shm, and /dev/pts, and uses a private PID, mount, network, IPC, and UTS namespace to isolate itself from other processes in the system.
Steps: Instructions declared in the corresponding Makes configuration files written using the Nix programming language and shell scripting, versioned as code in the source.

Source requirements

Version controlled

Every change to the source is tracked in a version control system that meets the following requirements:

Change history: There exists a record of the history of changes that went into the revision. Each change contains the identities of the uploader and reviewers (if any), timestamps of the reviews (if any) and submission, the change description/justification, the content of the change, and the parent revisions. Example: MR 28742.
Immutable reference: There exists a way to indefinitely reference a particular, immutable revision. Example: 1e1cb90fe224fb033b582829aad903cfef4ae9b9.

Verified history

Every change in the revision's history needs to pass through a merge request.

To create or approve a merge request, both the author and the reviewer need to be strongly authenticated into GitLab. The authentication process requires 2FA, and the dates of the change are recorded in the merge request.

Only users who were previously granted access by a platform Admin can create or review merge requests. Example: MR 28742.

Retained indefinitely

The revision and its change history are preserved indefinitely and cannot be deleted or modified (not even with multi-party approval).

At the moment, no legal requirement impedes us to preserve indefinitely our change history, and no obliteration policy is in effect. In fact, our source code is Free and Open Source Software: change history.

Two person reviewed

Every change within the revision's history must be approved by at least one trusted individual before submission. Moreover, each of these trusted individuals must authenticate into the platform using 2FA before granting approval.

Build requirements

Scripted build

All build steps were fully defined using GitLab CI/CD and Nix.

Manual commands are not necessary to invoke the build script. A new build is triggered automatically each time new changes are pushed to the repository. Examples: 1, 2, and 3.

Build service

All build steps run on GitLab CI/CD.

Build as code

All build steps have been stored and versioned in the Git repository: .gitlab-ci.yml.

Ephemeral environment

Our build service runs each build step inside a container that is provisioned solely for each build and not reused from a prior build. Example: container image.

Additionally, the Nix package manager provides an ephemeral environment to each of the derivations.

Isolated

Our build service ensures that the build steps run in an isolated environment free of influence from other build instances, whether prior or concurrent, by using containerization technologies.

Builds are executed using the Nix package manager, which prevents builds from accessing any external environment variables, network resources, sockets, or paths in the file system. It provides private versions of /proc, /dev, /dev/shm, and /dev/pts, and uses a private PID, mount, network, IPC, and UTS namespace to isolate the build from other builds happening concurrently in the system.

Input-addressed build caches are used to speed up the pipeline.

Parameter-less

The build output cannot be affected by user parameters other than the build entry point and the top-level source location.

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

Hermetic

Builds are executed using the Nix package manager, which prevents builds from accessing any external environment variables, network resources, sockets, or paths in the file system.

All transitive build steps, sources, and dependencies are fully declared up front with immutable references.

The Nix package manager:

Fetches all of the declared artifacts into a trusted control plane (the /nix/store).
Mounts into the build sandbox the specific /nix/store paths required by it.
Allows a build to fetch artifacts over the network if and only if the expected artifact integrity is specified.
Validates the integrity of each artifact before allowing a build to use it, and fails the build if the verification fails.
Denies network connectivity if no expected hash is specified.

Reproducible

All of our build scripts are intended to be reproducible. The reproducibility guarantees of our build scripts are those of the Nix package manager. If a build fails to be reproducible, we do not explicitly define why.

Provenance requirements

In SLSA, "Provenance" is a piece of verifiable information about software artifacts describing where, when and how they were produced.

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

At Fluid Attacks, consumers and builders are the same entity. We don't use artifacts or packages as a means of distribution. Instead, consumers use Makes, a source identifier, and the target artifact identifier, and then all sources, dependencies and intermediate artifacts are built locally in the consumer machine using the Nix package manager by following the steps and environment defined as-code in the source.

Available

Provenance is produced by Makes, and exposed by the build service as a JSON document together with the artifacts produced by the build.

Only builds that produce artifacts generate provenance, because if a build does not produce artifacts, then there wouldn't be something to verify the provenance of.

Authenticated

The authenticity of the provenance comes from the fact that it can be downloaded from the build service itself, and therefore, the authenticity claim is as strong as the Build and Source Requirements are secure.

The integrity of the provenance is displayed in the logs and generated by Makes.

Service generated

The data in the provenance is exposed by the build service and is generated by Makes.

Regular users of the service are not able to inject or alter the contents because a build is fully determined and automated by its configuration, and the configuration comes directly from the source.

Non-falsifiable

The provenance cannot be falsified by the build service's users:

There is no secret material to demonstrate the non-falsifiable nature of the provenance.
Even if such secret material existed, builds are run in a hermetic environment, and therefore they wouldn't be available to the build steps.
Every field in the provenance is generated by the build service in a trusted control plane, which is fully defined by the build configuration, which comes directly from the source, and therefore is as secure as the source is.

Dependencies complete

The provenance contains all the dependencies that were available while running the build steps. This is guaranteed by the fact that builds are hermetic. So for a build to succeed, all of its dependencies must be declared, and therefore the build tools (Makes and Nix), which fetched them at build time, have strong knowledge of their existence.