Application Security

Overview

As the Application Security team spans too many different time zones to have a reasonable schedule for a team-wide synchronous meeting we’ll try to handle most discussions asynchronous.

The main problem to solve is knowing that other team members have had a chance to respond to a given issue.

needs-eyes Label

In order to point other AppSec team members we use the needs-eyes label under https://gitlab.com/gitlab-com/gl-security/product-security/appsec/

Monitoring

The Application Security team uses a number of automation initiatives to help secure GitLab. These are not all authored by the AppSec team but they’re all useful to us. The points are listed in no specific order.

• Gem Checker monitors suspicious activity on RubyGems.org for gems that we use at GitLab
• sec-appsec-mr-alerts identifies MRs that modify dependencies used in our projects
• Public MR Confidential Issue Detector monitors for public merge requests that should have been opened in our security mirror
• Custom SAST rules detecting known-vulnerable code patterns that alert the AppSec team in the MR (related MR)
• untamper-my-lockfile included in CI to prevent lockfile tampering
• Package Hunter detects suspicious activity in dependencies at runtime (related runbook)
• GitLab Inventory monitors our projects and violations of security best practices and standards
• GitLab’s own application security features are running in CI
• Tokinator monitors for leaked credentials
• AppSec Escalator which is a tool that…
  • monitors that security issues are labeled properly
  • sets appropriate due dates on security issues
  • escalates overdue issues
  • detects potentially sensitive files posted in public issues
• depSASTer runs SAST on the dependencies used by GitLab
• Maintainer Watcher monitors potentially compromisable dependency maintainer accounts
• depscore runs dependency review checks on new/updated depndencies in gitlab-org/gitlab project.

Overview

This page describes the usage of a label to indicate a specific issue or epic is a priority for the Application Security (AppSec) team. This label helps in categorizing, tracking, and sharing product features requests that would benefit the AppSec team as part of dogfooding the GitLab product.

~"Internal Request::AppSec Team" Label

• Link to the list of issues with this label on gitlab-org.
• Link to the list of issues with this label on gitlab-com.

Usage

Apply the ~"Internal Request::AppSec Team" label when the AppSec team requests new security features or improvements to be built into GitLab, the product.

TBD

This page details the application security review process for appsec engineers. The purpose of application security reviews are to proactively discover and mitigate vulnerabilities in GitLab developed or deployed applications in order to reduce risk and ultimately help make the company’s mission successful.

An application security review may include any or all of the following stages:

• Threat modeling
• In-depth code review
• Dynamic testing

The results of each stage will inform the review done in the next stage. Ideally, all new features would receive some threat modeling, with the latter two stages being performed based on the risk profile. Features already in development or production can receive an appsec review as well. The testing done is dependent on the circumstances.

Note for New team members

Whenever you are on a rotation (HackerOne or Triage Rotation or doing your onboarding process and need help or advice, reach out in the #sec-appsec Slack channel or ask during an AppSec Sync meeting. Here are some examples on scenarios where you may need ask or need help:

• You’re doing your onboarding tasks, threat modeling, or appsec reviews, and you’re stuck on it; or don’t know how to tackle something in particular
• You’re on ping rotation and you don’t know how to deal with a particular situation or what to do with a specific question
• You’re on HackerOne rotation and have to deal with a hard report

The overall goal of Application Security Stable Counterparts is to help integrate security themes early in the development process. This is intending to reduce the number of vulnerabilities released over the long term. These Stable Counterparts can be found on the Product Categories page, next to the “Application Security Engineer” mentions.

Technical Goals

• Assist in threat modeling features to identify areas of risk prior to implementation
• Code and AppSec reviews
• Provide guidance on security best practices
• Improve security testing coverage
• Assistance in prioritizing security fixes
• Provide technical guidance on security fixes

Non-technical Goals

• Enable development team to self-identify security risk early
• Help document and solve pain points when it comes to security process
• Identify vulnerability areas to target for training and/or automation
• Assist in cross-team communication of security-related topics
• Assist development teams with security related compliance and regulatory audits

Adding & Updating Stable Counterparts

Stable Counterparts can be added or updated by following these steps:

Purpose

This procedure applies to vulnerabilities identified in GitLab the product or its dependency projects and ensures implementation of the Vulnerability Management Standard. This procedure is designed to provide insight into our environments, promote healthy patch management among other preventative best-practices, and remediate risk; all with the end goal to better secure our environments and our product.

Scope

The procedure laid out here applies to vulnerabilities identified in GitLab the product or its dependency projects.

We scan our own product using our security scanners. Our Engineering teams are remediating vulnerabilities detected by our scanners on a regular basis. This is done when a patch is available and for vulnerabilities that can be exploited in our context.

We often receive inquiries from customers regarding potential vulnerabilities detected by their own scanning tools or those integrated into GitLab. We value our customers’ trust in our expertise to assess these issues. However, given the volume of requests we receive and our limited resources, we kindly request cooperation in performing a reasonable level of initial review before seeking our input. These proactive efforts will enable us to focus on addressing the most critical vulnerabilities efficiently.