ADR 003: Generate and sign SLSA attestation in glgo

Architecture Decision Record for where to generate and sign SLSA attestations.

Context

SLSA (Supply chain Levels for Software Artifacts) is a security framework that helps ensure the integrity of software artifacts. As part of implementing SLSA Level 3 compliance, GitLab needs to generate signed attestations for artifacts produced by CI/CD pipelines with provenance generated by GitLab. The final output is a Sigstore bundle which can be used to verify the provenance of an artifact.

Currently, SLSA attestations can be generated in the GitLab Runner. However, this approach doesn’t meet SLSA Level 3 requirements, which specify that atteststations must be generated and signed by the control plane (within the trust boundary) and not by a tenant of the build platform.

This ADR documents the decision on where to generate and sign SLSA attestations within GitLab’s architecture.

Options Considered

1. CI/CD component (Current Implementation)

Pros:

  • Visibility: advertised in the CI/CD catalog
  • Maintenance: new releases can be published at any time
  • Cosign integration: it’s possible to run the cosign CLI, which is the reference implementation
  • KMS integration: see Using external secrets in CI

Cons

  • Components must be mirrored in order to be using with self-managed or Dedicated instances.

Blockers:

  • Not in control plane.

2. Runner

Pros:

  • Cosign integration: it’s possible to run the cosign CLI, which is the reference implementation

Blockers:

  • Not in control plane.

3. GitLab Rails

Pros:

  • Deployment and maintenance: it ships with GitLab
  • Easy setup: can be enabled in GitLab UI
  • Compliance: can be enforced regardless of what’s defined in the CI/CD configuration file in control plane (as defined by SLSA)

Cons:

  • Unlike CI/CD jobs the backend can’t execute commands like cosign
  • Would require the signing to be done in Ruby, and the sigstore-ruby gem isn’t mature enough, and does not support signing (although code does exist).

4. glgo

Pros:

  • Very good isolation.
  • It’s already being deployed as part of gitLab.com
  • Communication b/w glgo and the Rails backend is secured using tokens.
  • We can integrate sigstore-go or cosign.
  • Can interact with OpenBao and other KMS.

Cons:

  • We can’t directly support self-managed distribution. However, by open sourcing glgo and providing deployment instructions, we provide a path forward for these customers.

Decision

We will generate and sign SLSA attestations in glgo.

This option gives us the fastest path to production for gitlab.com while still providing a path forward for self-managed customers.

Consequences

Positive

  • SLSA Level 3 compliance is achievable.
  • Attestation generation and signing can be delivered for gitlab.com customers
  • No additional services or infrastructure required.

Negative

  • glgo is not included for self-managed or Dedicated customers today, and additional effort will be required to make it available in the future.
Last modified June 25, 2025: Add ADR 003 to SLSA design doc (64094004)
View page source - Edit this page - please contribute. Creative Commons License