Application Security
The application security team’s mission is to support the business and ensure that all GitLab products securely manage customer data.
Application Security Mission
As part of the Product Security department, the application security team’s mission is to support the business and ensure that all GitLab products securely manage customer data. We do this by working closely with both engineering and product teams.
Team members can reach the AppSec team by:
Application Security Roadmap
Please see the Product Security Program Strategy document.
Roles & Responsibilities
Please see the Application Security Job Family page.
Useful resources for AppSec engineers
The list above is not exhaustive and is subject to be modified as our processes keep evolving.
Application Security KPIs & Other Metrics in Sisense
- For Embedded KPIs which you filter by section, stage, or group, please see this page.
General Role Functions
Stable Counterparts
Please see the Application Security Stable Counterparts page.
Application Security Reviews
Please see the Application Security Reviews page.
RCAs for Critical Vulnerabilities
Please see the Root Cause Analysis for Critical Vulnerabilities page
Application Security Engineer Runbooks
Please see the Application Security Engineer Runbooks page index
Meeting Recordings
The following recordings are available internally only:
Backlog reviews
When necessary a backlog review can be initiated, please see the Vulnerability Management Page for more details.
As part of our dogfooding effort,
the Secure Tools are set up on many different GitLab projects (see our policies).
This list is too dynamic to be included in this page, and is now maintained in the GitLab AppSec Inventory.
Projects without the expected configurations can be found in the inventory violations list (internal link).
GitLab Inventory
Learn more about the GitLab AppSec Inventory.
Reproducible Vulnerabilities
Learn how to identify or remediate security issues using real examples with GitLab’s Reproducible Vulnerabilities.
Reproducible Builds
Learn how GitLab is implementing Reproducable Builds for our build processes.
Milestone Planning
The GitLab Application Security team plans work based around Milestones, see this page for a description of that process
Application Security Automation and Monitoring
Please see the Application Security Automation and Monitoring page
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/
Technical issues which need eyes should be create as meta-issues under gitlab-com/gl-security/product-security/appsec/appsec-reviews Non-technical should be created under gitlab-com/gl-security/product-security/appsec/appsec-team Within the labeled issues any asynchronous discussion can take place.
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.
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.
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.
The AppSec Inventory is a private GitLab project to identify and track all projects, components, and dependencies that matter for AppSec
Learn how the GitLab Application Security team does Milestone Planning
Learn how GitLab is implementing Reproducable Builds for our build processes
Learn about GitLab, its security processes, and its historical security vulnerabilities
The threat modeling process, and the framework used by the GitLab Security Team.
