Supply Chain Risk Management Strategy

Introduction

This page outlines GitLab’s comprehensive strategy for identifying, assessing, and mitigating risks within our software supply chain. Our risk-based approach is designed to protect both our own data and our customers’ data while progressively advancing towards higher levels of Supply chain Levels for Software Artifacts (SLSA) compliance.

Goals and Objectives

• Identify and mitigate risks to GitLab’s internal data assets throughout the supply chain
• Safeguard our customers’ data by ensuring the integrity and security of our software delivery pipeline
• Achieve and maintain progressively higher levels of SLSA compliance through risk-focused improvements
• Establish comprehensive visibility and traceability to detect supply chain threats and vulnerabilities
• Implement a proactive risk management framework to address emerging supply chain threats
• Create a measurable approach to reduce supply chain attack surfaces
• Support and enhance the Product Security Risk Register (PSRR) with structured supply chain risk data and analysis

Supply Chain Component Model

Decomposing Supply Chain Complexity

GitLab’s complete supply chain is too complex to represent in a single comprehensive diagram. Instead, we break down this complexity into manageable components using a recursive model:

• Each artifact has its own supply chain
• Each artifact’s supply chain may depend on other artifacts, which have their own supply chains
• This creates a directed graph structure where:
  • Root nodes are the distributed artifacts (our final products)
  • Internal nodes are intermediate artifacts and components
  • Leaf nodes represent the boundaries of our supply chain (external components)

We focus our inventory and management efforts on artifacts and components within GitLab’s direct control. For external components (leaf nodes), we track their origin and basic metadata but do not attempt to document their entire supply chains at this stage.

SLSA Supply Chain Model

We align our supply chain tracking with the SLSA framework (Specification 1.0), which defines three key areas to secure:

This model illustrates the core steps we track:

1. Source: Where code is authored, reviewed, and stored
2. Build: Where source is transformed into packages/artifacts
3. Package: Where built artifacts are stored and distributed

The model also depicts:

• Producer: The entity responsible for creating the software
• Consumer: The entity consuming the software (another supply chain, or end-user)
• Dependencies: Internal and external components that feed into the build and package processes

For each artifact in our supply chain, we track its path through these three core steps, documenting controls and provenance at each stage.

Supply Chain component types

Our model identifies specific component types within each core step of the supply chain. These types serve as reference elements to be used when describing a particular subset of the supply chain. Note that not all components will be present in every supply chain - the categorization below provides a framework for comprehensive modeling.

These types are linked to SLSA threats in the PSRR to create comprehensive risks, see the “Threats” section below. Risks can be linked to a subtype if more granularity is needed.

Source components

The Source core step includes everything that can edit and alter the source code before the Build step:

Build components

The Build core step includes everything that can transform the source code (compilation, linting, etc.) and produce an artifact:

Package components

SLSA 1.0 Alignment

This framework is based on the Supply chain Levels for Software Artifacts (SLSA) specification 1.0. We deliberately adopt SLSA terminology and concepts to ensure consistency with industry standards and facilitate compliance efforts. Key SLSA elements incorporated into our model include:

• Build provenance documentation
• Source verification
• Build integrity controls
• Artifact authentication
• Access control requirements

Threats

SLSA defines a set of threats that are used in the PSRR to link elements of the model to risks:

SBOM Integration

Software Bills of Materials (SBOMs) play a crucial role in connecting different supply chains. For each artifact we produce:

• We generate a comprehensive SBOM
• The SBOM documents all dependencies and their sources
• These SBOMs serve as the “connective tissue” between different supply chain segments
• SBOMs provide traceability from any artifact back through its entire dependency tree

Integration with the Product Security Risk Register

The Supply Chain Risk Management Strategy serves as a critical foundation for the Product Security Risk Register (PSRR). Each supply chain-related risk identified in the PSRR must be linked to specific elements within this supply chain model:

1. Risk Mapping Requirements

   • Every supply chain risk in the PSRR must reference specific components from this model
   • By extension, risks identifies which part of the supply chain step is affected (Source, Build, or Package)
   • Risk documentation can include specific artifacts involved
   • The potential for risk propagation through the supply chain should be documented

2. Bidirectional Traceability

   • Supply chain model components must link back to relevant PSRR risk items (see labels above)
   • PSRR entries must link to the affected supply chain components
   • Updates to the supply chain model should trigger reviews of related PSRR entries
   • New PSRR risks related to supply chain must be mapped to this model during risk registration

3. Unified Risk Assessment Approach

   • The risk scoring methodology must be consistent between this model and the PSRR
   • Supply chain risk mitigations documented in the PSRR should align with controls in this model
   • Risk acceptance decisions should consider the full context of the supply chain graph

This integration ensures a comprehensive approach to supply chain risk management that leverages our existing security frameworks while providing deeper visibility into supply chain-specific threats.

How to Use This Model

For Development Teams

1. Artifact Documentation

   • For each new artifact type, document its source components
   • Register artifact in the central inventory (see https://gitlab.com/groups/gitlab-org/-/epics/16484)

2. Compliance Verification

   • Regular self-assessments against the model requirements
   • Document evidence of control implementation
   • Participate in periodic supply chain reviews

For Security Teams

1. Risk Monitoring and Intelligence

   • Implement continuous risk monitoring for registered components
   • Conduct regular threat hunting across the supply chain ecosystem
   • Maintain a supply chain threat intelligence program
   • Establish risk thresholds and escalation procedures for detected anomalies

2. Risk-Based Audit Support

   • Maintain risk evidence collection for compliance purposes
   • Support external audits with risk assessment documentation
   • Verify the implementation and effectiveness of risk controls across teams
   • Develop risk-focused audit narratives and documentation

3. Risk Model Evolution

   • Update the risk model as new threats and attack techniques emerge
   • Refine risk classification criteria based on incident data and operational feedback
   • Ensure alignment with evolving SLSA requirements and industry threat landscape
   • Conduct periodic red team exercises to test supply chain security resilience

Risk Management Metrics and Success Criteria

Success in our supply chain risk management strategy will be measured by:

References and Resources

• SLSA 1.0 Specifications and Requirements
• NIST Secure Software Development Framework
• SPDX SBOM Format
• CycloneDX SBOM Format

View page source - Edit this page - please contribute.