Software Supply Chain Security

Ensure your software supply chain is secure and compliant

Try GitLab Free

SLSA Compliance

The GitLab platform can help support users who are working to attain SLSA compliance. The table below describes how the GitLab platform can support these requirements.

SLSA Requirement SLSA Level GitLab Supported

Source: Version controlled 2

Yes

Source: Verified history 3

Yes

Source: Retained indefinitely 3 / 4

Yes

Source: Two-person reviewed 4

Yes

Build: Scripted build 1

Yes

Build: Build service 2

Yes

Build: Build as code 3

Yes

Build: Ephemeral environment 3

Yes

Build: Isolated environment 3

Isolated execution environments are supported. The GitLab runner itself does not support native signing of builds, so if build signing is used, then it would need to be configured as part of the CI build pipeline, which would give the build access to the provenance signing key.

Build: Parameterless 4

Yes

Build: Hermetic 4

Runners can be configured with limited network access . To meet all aspects of this requirement would at a minimum require use of private runners together with setting up a trusted control plane for storing artifacts. Runners require communication with the GitLab server, so the GitLab server may also need to be run on a network without internet connectivity.

Build: Reproducible 4

Yes

Provenance: Available 1

Yes via CI integration

Provenance: Authenticated 2

Yes via CI integration

Provenance: Service generated 2

Users can generate provenance as part of their CI build script; however, the build service itself does not currently generate provenance natively.

Provenance: Non-falsifiable 3

Users can generate provenance as part of their CI build script; however, the build service itself does not currently generate provenance natively.

Provenance: Dependencies complete 4

GitLab's CI options provide the flexibility needed to run a wide variety of custom scripts as part of the build process. Meeting this requirement in GitLab is technically possible, but would require users to create a script to collect the required data and add it into the provenance output.

Provenance Contents: Identifies artifact 1

Yes via CI integration

Provenance Contents: Identifies builder 1

Yes via CI integration

Provenance Contents: Identifies build instructions 1

Yes via CI integration

Provenance Contents: Identifies source code 2

GitLab's CI options provide the flexibility needed to run a wide variety of custom scripts as part of the build process. Meeting this requirement in GitLab is technically possible, but would require users to create a script to collect the required data and add it into the provenance output.

Provenance Contents: Identifies entry point 3

GitLab's CI options provide the flexibility needed to run a wide variety of custom scripts as part of the build process. Meeting this requirement in GitLab is technically possible, but would require users to create a script to collect the required data and add it into the provenance output.

Provenance Contents: Includes all build parameters 3

GitLab's CI options provide the flexibility needed to run a wide variety of custom scripts as part of the build process. Meeting this requirement in GitLab is technically possible, but would require users to create a script to collect the required data and add it into the provenance output.

Provenance Contents: Includes all transitive dependencies 4

GitLab's CI options provide the flexibility needed to run a wide variety of custom scripts as part of the build process. Meeting this requirement in GitLab is technically possible, but would require users to create a script to collect the required data and add it into the provenance output.

Provenance Contents: Includes reproducible info 4

GitLab's CI options provide the flexibility needed to run a wide variety of custom scripts as part of the build process. Meeting this requirement in GitLab is technically possible, but would require users to create a script to collect the required data and add it into the provenance output.

Attestation/Provenance Generation

The GitLab platform can support the generation of attestation or provenance by integrating the CI pipeline with a tool capable of signing the build output. The key for signing can be stored as a protected CI variable and passed into the build environment. The build environment can then leverage a tool such as Cosign to generate the provenance in a way that would support meeting SLSA level 1 requirements.

Additionally, Cosign supports adding additional metadata into the signature output through the -a flag . When combined with GitLab's CI capabilities, users can meet some of the requirements at higher levels of SLSA by passing in data about the builder, build instructions, source code, and other relevant metadata values. For more details on GitLab's future plans to help users achieve higher levels of SLSA natively with GitLab, take a look at our overall software supply chain security vision .