Group Direction - Anti-Abuse

1. You are here:
2. GitLab Direction
3. Product Stage Direction - Govern
4. Group Direction - Anti-Abuse

On this page

• Overview
  • Goal
    • Categories
  • Mission
  • Our Responsibilities
    • Ownership
      • CAPTCHA
      • User Trust Score
      • Barriers to entry
      • PVS (Pipeline validation service)
• Confidential issues
• The Plan
  • What We Recently Completed
• Overview
• Priorities
  • GitLab team members can reach Anti-Abuse via:

Overview

Create protections against abusive activity within a GitLab instance. This includes abuse, spam, and other activity for users within a GitLab instance.

Goal

Protect GitLab instances from user behavior that disrupts productivity or an organization's ability to build and deploy code.

This group will help eradicate fake accounts, proactively identify and remove bad actors, and help GitLab better understand our legitimate users. This group will directly protect the stability, performance, and scalability of GitLab for millions of users across the world ensuring they can effectively use GitLab for their daily development needs.

Categories

The Anti-Abuse group is currently made up of two product categories:

• Instance Resiliency - Detect and prevent malicious activity from occurring within GitLab Instances.
• Insider Threat - Insider Threat identifies attacks and high-risk behaviors by correlating different data sources and observing behavioral patterns.

Mission

We make abuse manageable.

Our goal is not to completely eradicate abuse. Barriers to stopping abusive behavior have an exponentially diminishing rate of return. The more barriers that you impose to stop abuse the more you discourage legitimate usage. As a result, efforts to stop abuse become more costly than the abuse itself. Our goal is to surface abuse before it causes disruption and allow our automated systems, the Trust and Safety team, or the admin of the self-managed instance to take the correct action for that abuse – or correct any action that was taken in error

Our Responsibilities

• Implement CAPTCHA to prevent malicious programmatic actions
• Implement User Trust Score to inform rate or usage limiting
• Introduce barriers to entry at signup to prevent repetitive abusers from accessing the platform
• Maintain Pipeline Validation Service (PVS) to prevent those users who make it through our barriers from utilizing the GitLab platform in a disruptive or malicious way.
• Manage the integration of Arkose Labs into GitLab.com to help protect against abuse and inauthentic behavior.

Ownership

CAPTCHA

• Utility
  • We use CAPTCHA to prevent programmable actions with the UI.
• Stakeholders
  • Trust and Safety

User Trust Score

• Utility
  • We use the User Trust Score to gauge the intent of a user. The score should predict how likely a user is to utilize the platform maliciously. Conversely, the User Trust Score should also predict how likely the user is to become a valuable user of the platform.
• Stakeholders
  • Security Automation
  • Growth
  • Product Analytics
  • Trust & Safety

Barriers to entry

• Utility
  • The majority of abuse stems from new users. Barriers to entry are a mechanism to prevent repetitive abuse by placing additional barriers in front of users that we determine could be at high risk of perpetrating abuse.
• Stakeholders
  • Growth

PVS (Pipeline validation service)

• Utility
  • PVS monitors abusive behavior within pipelines to prevent users from utilizing pipelines for other-than-intended use cases.
• Stakeholders
  • Enablement

Confidential issues

Several issues are intentionally confidential despite our value of transparency. This is because we don't want to make it obvious to abusers the exact details of our controls. We aren't relying on "security by obscurity"; however, we also don't want to make it easier for the abusers.

The Plan

What We Recently Completed

• Initial implementation of Pipeline Validation Service
• Various changes to GitLab.com to help mitigate Cryptomining abuse. Read more about coming changes.
• Initial implementation of Git abuse rate limiting

Overview

Anti-abuse is a group in the Govern stage. There are two categories in the group and details on the direction can be viewed on the following individual category pages:

1. Instance Resiliency
2. Insider Threat

Priorities

Priority	Name	DRI	Size	Target release
1	Application Rate Limits	TBD	L	16.7
2	Set new user rate limits and increase based on positive engagement	TBD	M	16.8
3	Confidential	TBD	M	16.8
4	Update rate limits based on IP location history	TBD	M	16.9
5	Create API to surface current rate limits to users	TBD	S	17.0
6	Create UI to surface current rate limits to users	TBD	S	17.0
7	Update Git Abuse Rate Limiting to use rate limits and only suspend in obvious cases	TBD	S	17.0
8	Log network traffic so it can be queried (by a service)	TBD	M	17.1
9	Log the end resolution of a URL	TBD	M	17.2
10	Analyze network traffic to see if the end resolution of a URL is a predictor of abuse	TBD	M	17.2
11	Update Rate Limit / Ban Users That Reach Out To Known Abusive URLs	TBD	M	17.3
12	Allow Admins To Monitor The Network Traffic From Their Pipelines.	TBD	M	17.4
13	Admin Users Should Be Alerted When New Domains Are Communicated With Within Their Jobs	TBD	M	17.4
14	Update rate limit when users access gitlab from a new device	TBD	M	17.4

*This page may contain information related to upcoming products, features and functionality.

It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes.

Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.*

GitLab team members can reach Anti-Abuse via:

Slack: #g_govern_anti-abuse channel

Last Reviewed: 2023-02-01
Last Updated: 2023-02-01