Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Software Supply Chain Security

Ensure your software supply chain is secure and compliant

Try GitLab Free

Securing the software supply chain is too often an afterthought. However, high-profile attacks are proving too costly to allow security to be kicked down the road in the software development process. GitLab can help by providing an end-to-end secure platform to help protect multiple attack surfaces, including protection for internal code, external sources, and even the build process itself. Additionally, GitLab can be used to manage and automatically enforce continuous software compliance requirements.

Software Supply Chain Security with GitLab

Software Supply Chain Security at GitLab


Dependency List

External Source Code Protection



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 .

Open in Web IDE View source