Shared Responsibility

The Security and Compliance capabilities of the GitLab product cover only one aspect of security -- application security. Other aspects, such as network, infrastructure, social, and endpoint security remain the responsibility of the customer organization. Some customers need help understanding the difference.

Furthermore, while GitLab provides the tooling (and sometimes infrastructure) for application security testing and vulnerability management, the ultimate responsibility for application security lies with the customer.

The language below might help to explain the nuance of shared responsibility, loosely based on the AWS Shared Responsibility Model for cloud services.

Customer infrastructure and applications

Customers bear responsibility for implementing and managing the security of their applications and applications, including how they utilize GitLab's security tools within their development pipelines. This encompasses reviewing and acting upon identified vulnerabilities, managing dependency updates, and implementing recommended security fixes

Customers must configure security scanning tools appropriately, interpret results, and make informed decisions about vulnerability remediation priorities.

For example, while GitLab provides dependency scanning capabilities to identify known vulnerabilities in external libraries, customers are responsible for actually updating these dependencies and ensuring their application remains secure. Similarly, while GitLab provides SAST scanning capabilities, customers must enable and configure the rules and execution policies appropriately for their specific use cases.

GitLab platform capabilities

GitLab develops, maintains, and delivers capabilities that support customers in ensuring security of their infrastructure and applications. The Application Security capabilities including several types of vulneravility scanning engines as well as various user interfaces and APIs for understanding and addressing vulnerabilities.

Our focus is on preventing software vulnerabilities from entering the supply chain - an approach known as "shift left".

We focus on improving scanning accuracy, reducing false positives, and enhancing detection capabilities through continuous research and development. In addition to the scanners themselves, GitLab maintains a database of known vulnerabilities and groups of analyzer rules. Most of the vulnerability information and rules come from public sources. Parts of the company focus on performing security research, improving GitLab's security capabilities, and developing proofs of concept while maintaining the databases and fulfilling CVE Numbering Authority duties.

GitLab platform security

With regard to the GitLab platform itself, responsibility for security falls mostly with GitLab.

GitLab maintains responsibility for providing and securing the fundamental security scanning and vulnerability management infrastructure. This includes maintaining and updating the security scanning engines, vulnerability databases, and the platform infrastructure that enables security testing.

GitLab also manages the infrastructure of GitLab.com, handling maintenance and addressing any incidents that arise.

In the case of self-managed GitLab, instance administrators take primary responsibility for infrastructure security. The GitLab support organization is available to help.

Security incidents

(Including breaches and "zero-day" vulerabilities)

When handling a security incident, follow guidance on the Responding to security incidents page in the documentation.

Customers must handle security incidents in their area of responsibility, including:

  • CI/CD security incidents, including exposed job tokens and pipeline secrets
  • Project and group setting misconfigurations
  • Credential exposure incidents
  • User account compromises within customer organizations

GitLab provides capabilities to support customers, including:

  • Audit events
  • Credentials inventory
  • Secrets detection

With regard to "zero-day" vulnerability discoveries, the best defence is to ensure that application SBOMs (Software Bill of Materials) are up-to-date so teams may quickly identify vulnerable applications.

Managing vulnerabilities

The goal is to prevent breaches and attacks. Active vulnerability management is key. At a high level:

  • The scanners scan and identify potential vulnerabilities
  • The Vulnerability Report provides a mechanism to understand, accept, dismiss, comment, and assign vulnerabilities
  • A developer or infosec professional has to make the decision as to which vulnerabilities to accept or dismiss
  • The “Explain This Vulnerability” and “Security Training” capabilities can help in some cases

One of our team members shared:

Identifying false positives requires investigation. There may be times when it’s “obvious” but those are likely rare. When you have identified a false positive, though, it might be best to tweak the rules or configuration to avoid detecting such instances in the future, where tweaking rules is available.

Resources

The Nested Nature of Security

Security responsibilities are like Russian (Matryoshka) dolls, fractals, or turtles all the way down - the same patterns repeat at different scales. For example:

GitLab <-> Customer

  • GitLab provides the software, security features, and patches
  • Customer decides how to use them and when to apply updates
  • For self-managed, customer owns infrastructure security
  • For GitLab.com, GitLab handles the infrastructure

Within the Customer org: Security Team <-> Platform Team

  • Security sets policies and requirements
  • Security maintains vulnerability management program
  • Platform implements and maintains controls
  • Platform handles infrastructure patching and hardening

Platform Team <-> Dev Teams

  • Platform provides secure infrastructure and tooling
  • Platform configures security scanners and guardrails (components, frameworks, etc.)
  • Dev teams configure security in their pipelines (sometimes)
  • Dev teams manage application dependencies

Dev Teams <-> Individual Devs

  • Teams set security standards and review processes
  • Teams handle vulnerability remediation priorities
  • Devs make day-to-day security decisions in code
  • Devs implement secure coding practices

The common pattern being one party provides capabilities, the other decides how to implement them. This creates a chain of shared responsibility that scales from the organizational level right down to individual code commits. Even within each level, you'll find the pattern repeating - like how dev teams handle both infrastructure-as-code security and application security, each with their own provider/implementer relationships and alignment to enterprise strategies.