Security and Compliance Advisory

This fixed price advisory service is recommended for customers new to GitLab Ultimate, including upgrades from Premium, who are looking to understand core DevSecOps principles and how to get the most out of GitLab Ultimate features. The workshop is particularly valuable for organizations that are new to application security practices or are looking to enhance their existing security workflows.

It includes an introduction to GitLab Security features, including shift-left concepts, security dashboard, vulnerability management, security scan capabilities, policies, compliance frameworks, and other features.

The roadmapping sessions advise customers on how to plan for and adopt GitLab's application security features, helping clients to:

  • Define security policies including:
    • Types of security scans required.
    • When to run each scan.
  • Determine which projects should be scanned, automate scans and enforce scans.
  • Understand the GitLab Security Dashboard.
  • Define a vulnerability remediation strategy.
  • Educate both developers and security team members on the GitLab compliance process.

Sales and pre-launch considerations

  • This service offering does not involve touching customer code at any point. We use pre-built, open source projects to showcase GitLab Ultimate security features, and dive deep into each of the security topics mentioned above.
  • This is a fixed price SKU service (not customized or variable), the scope and price estimate of this service is small.
  • For any customer looking for a more advanced security focused engagement, they should look at our DevSecOps App Transformation service, whose scope is larger because it involves working on customer projects.

For fixed-price engagements, we use a service description document instead of the traditional SOW. This still has a list of all of the activities that will be covered in the engagement, but doesn't tie specific hours to specific tasks. You can find the Security and Compliance Advisory Service Description here..

Delivery requires access to the GitLab demo environment and maintainer access to the Security and Compliance Advisory Compliance Group. To receive access, generate credentials by following the demo system documentation.

Professional Services team, please use the demo architect portal to request a workshop LearnLabs group to be created. First, use GitLab Admin login to sign in and follow the instructions to do a content/lab request and complete the form with the necessary information. Afterwards, you will be notified when the issue to create your group is created and then the group link when it is actually created. Please export/import the Security and Compliance Advisory project demos you'd like to use into the LearnLabs group and provide the partner with access permissions.

Target Audience

The target customer for this service offering is a customer moving from Premium to Ultimate or a new Ultimate customer or an Ultimate seat expansion. The main service offering is meant for a PSE to showcase GitLab's security product capabilities, facilitate deep-dive sessions, Q&A, and/or strategic discussions about GitLab security features.

Unlike GitLab's education services, there is no limit to how many people from the customer organization can participate in this advisory, making it an excellent opportunity for cross-team collaboration. The customer should ensure that security SMEs and champions are in attendence.

Advisory Structure

The Security and Compliance Advisory engagement typically breaks down into three main components:

  1. Discovery/Inquiry (approximately 2 hours of meetings) - An open discussion to understand the customer's current security practices, tools, and challenges. This helps tailor the subsequent parts of the engagement to the customer's specific needs. Aim to establish 1 or 2 items from discovery that you can directly showcase in the demo. Leverage these discovery questions to help.

  2. Demonstration (approximately 2 hours of meetings) - A hands-on showcase of GitLab's security capabilities and vulnerability management features using pre-built projects. This gives customers practical experience with the tools.

  3. Strategic Discussion - A strategic session to map the customer's specific challenges to GitLab Ultimate features, with a focus on shifting security left in the development process. Review a roadmap that details what implementing information security into an organization could look like.

Demo Overview

The projects to use are widely known, open-source projects. They are:

Slides are available for use and are located in the deck Security and Compliance Advisory. The slides were designed to help pave the way for how the demo can flow. Please add comments and make changes as necessary so that everyone can benefit.

These projects were chosen because they provide:

  • Intentionally vulnerable applications - Designed with known security flaws to simulate real world applications
  • Multiple vulnerability types - Include SAST, DAST, secret detection, dependency scanning, and container scanning findings
  • Realistic codebases - Written in commonly-used languages and frameworks (PHP, Java, Node.js) that customers actually work with
  • Consistent demo experience - Externally well-maintained projects that produce predictable scan results without requiring customer code
  • Educational value - Widely recognized in the security community, making them excellent teaching tools for security concepts
  • Multi-language coverage - Allows demonstrating GitLab's language detection and appropriate analyzer selection across different technology stacks

These projects will be showcased to customers to teach them the following core GitLab Ultimate concepts and benefits:

Remember this delivery is designed to be flexible. Make changes you feel necessary, within reason, based on what would provide the most benefit to the customer.

  1. Shift-left mindset in MR workflow and DevSecOps best practices.
  2. Inclusion of GitLab scanners.
  3. Creation of a policies.
  4. Creation of compliance frameworks. You can use these prebuilt compliance frameworks templates.
  5. Built-in GitLab security dashboard and vulnerability remediation.

Delivery Steps

For delivery, the intent is to provide as much relevant information to the customer, based on discovery, as you can in the ~2 hours of demo time. This delivery is designed to be flexible, within reason. It is encouraged to set this up fully ahead of time so that time is not used during the demo setting up items like policies or frameworks from scratch.

It's important to faciliate conversation with the customer to allow them to start thinking about how they can utilize these features and practices in their organization. Stop frequently to ask if the customer has questions or if they would like to discuss a topic in greater depth.

1. Access the Security and Compliance Advisory Compliance Group in our sandbox environment and request maintainer access, and that should have everything you need for delivery. See prerequisites above for more details details.

2. Create a new subgroup named "Security and Compliance Advisory - JohnDoe", replacing "JohnDoe" with your name. In your subgroup add the three projects DVWA, juice-shop, and Webgoat. You can find the original projects in the Security and Compliance Advisory Group and add them to your new subgroup by:

  • Creating an export (Settings-->General-->Advanced-->Generate & Download Export), hitting the "New Project" button, and attaching the GitLab export file (*tar.gz)
  • Cloning the Security and Compliance Advisory - Original project down to your local machine, create a new blank project in the GitLab UI within the Security and Compliance Advisory Compliance Group, and pushing it to "Security and Compliance Advisory - JohnDoe", replacing "JohnDoe" with your name.

3. Showcase the .gitlab-ci.yml file on the default branch and briefly walk through the stages that exist for the three sample projects.

  • While going through the .gitlab-ci.yml file, take time to point out which type of scanner each template is since they were introduced in the slides.

4. Create various policies: Merge Request Approval Policy, Scan Execution Policy, and Pipeline Execution Policy. Discuss how these policies enable the shift-left mindset.

  • Showcase the separate policy project that has been created with a similar name to the project/group where the policy was created.

5. Create 2-3 compliance frameworks. Point out that you can use these compliance frameworks to enforce policies based on the compliance framework assigned to the project. Showcase the Compliance Dashboard and point out the various reports that can be exported.

6. Showcase other items under the Secure tab such as the Security Dashboard, Vulnerability Report, and the Dependency List. Demonstrate how the view will change based on where you are in the hierarchy when looking at the Security Dashboard, Vulnerabilty Report, and the Dependency List. Navigate around the various functionality within each tab, such as showing how to do mass triage on the vulnerability report and how you can export SBOM from the dependency list. Audit Events is available as well and Ultimate gets Audit Event Streaming. It is encouraged to setup Audit Event Streaming to showcase how it works and mention how actions can be performed automatically based off using event information.

7. It's important to remind the customer that GitLab is a tool. It may not contain all the functionality they would like out of the box. That is where functionality like CI/CD components can come in and help extend pipeline functionality. Remember, just because it's not native to GitLab does not mean it cannot be done through GitLab.

Guide to Facilitate Deeper Dive On Some Concepts

It's important to note that customers often face process challenges more than technical challenges. Be prepared to discuss topics such as:

  • Organizational structure for security (many organizations don't have dedicated security personnel)
  • Branching strategies and workflows
  • GitLab group structure and organization
  • Integration with third-party scanners (e.g., SonarQube)
  • Secret push protection

Shift-Left Security Mindset + Merge Request Setup

Watch this video from the documentation that summarizes the shift left mindset.

  • The stages and jobs defined in the .gitlab-ci.yml file will run and output meaningful results (test outputs, logs, etc.) on the GitLab UI.
  • Using Auto DevOps templates, we can include security scans with 1 line of code to run security checks and output logs to developers before code gets merged into the default branch. The templates run the scans in a test stage that is automatically created for you.
  • Merge request approvals can be set up so that certain users or groups of users need to review a merge request before that branch is merged into a specific branch. This encourages code reviews, increases quality, and prevents unwanted changes from being released.
  • Customization allows for multiple approval rules to be created, different rules per branch, and rules based on security scan results.

Secret Detection

  • GitLab's Secret Detection solution scans through source code to look for over 100 common patterns that would signify a token or password (i.e. access tokens, popular cloud provider keys, URLs, etc.).
    • The GitLab solution spins up a container that runs the GitLeaks scan for you in the test stage.
    • You can override certain predefined rules or create custom rules if you need to.
  • By default, secret detection only scans commits, not the working tree, but the scan template can be configured to do a historical scan, scan all commits in a merge request (use the secret-detection.latest job for this), scan all branches, etc.
  • You need a docker or k8s executor on a Linux based GitLab runner to use the secret detection GitLab template.
  • You can configure the scan to omit certain paths, secrets, and use a specific version of the analyzer.
  • The job outputs an artifact in JSON format which by default is available for 7 days.

SAST and GLAS (GitLab Advanced SAST)

  • GitLab's SAST scanner checks out source code for vulnerabilities and outputs the report into a JSON artifact.
    • Examples of SAST vulnerabilities include a dangerous class attribute or unsafe code that can lead to unintended code execution or code that is available to cross-site scripting (XSS) attacks where unauthorized access to session details can be attained.
    • The SAST job runs in the test stage when including the template.
      • Because the job automatically runs in the test stage, and by default does not contain the needs keyword (aka it does not depend on any other job), it will run after the build and/or containerize job is run and scan the entire working tree. Therefore, if anything from those jobs have been saved as artifacts or within the cache (i.e. a poetry install in a build stage), secrets detection could potentially detect dozens of vulnerabilities based on the dependencies that were installed.
      • The solution here would to be to use the needs keyword to ensure secret detection runs first or encourage teams to run it in the .pre stage instead of the test stage.
  • You need a docker or k8s executor on a Linux based GitLab runner to use the SAST GitLab template.
  • GitLab's SAST scanner detects the language used in the project and automatically runs the corresponding analyzer.
  • False positive detection, currently is only available for Ruby and Go projects for Ultimate customers.
  • Certain projects need to have code pre-compiled before running a SAST analyzer, and this can be achieved by outputting project dependencies into a working directory via the artifacts keyword, setting the COMPILE variable to false, and making sast depend on the build job with the needs keyword.
  • You can configure the scan to omit certain paths, use a specific version of the analyzer, increase the debug log level, modify the depth of scan, pass credentials to a private repository, etc.

Security Dashboard & Vulnerability Remediation

  • The GitLab Security Dashboard is the one stop view to track the results of the most recent GitLab security scans on the default branch.
  • The dashboard provides a view of vulnerabilties over time at both the project and group level, and for the latter, will assign a grade based on the highest severity open vulnerability (does not include dismissed or resolved vulnerabilities).

Vulnerability Management

  • The Vulnerability Report for a project shows details on each vulnerability including when it was detection, description, where in the code it was detected, linked issues, and available actions.
  • The report can be filtered by date, severity, scanner, activity, and project.
  • Here's a short video on vulnerability management.
  • The default vulnerability status is Detected, which shows up as "Needs Triage" in the UI. Dismissing a vulnerability ensures it won't pop up on subsequent security scans while resolving a vulnerability will change its status, but allow the vulnerability to pop up again if the problem still exists.

Scan Result & Scan Execution Policies

Scan result policies are used to enforce a custom approval rule when a security scan detects a vulnerability.

  • Scan result policies can be enforced at the group level with a corresponding security policy project and customizable policy.yml file that gets created within the group.
  • Customize the approval group to ensure certain people need to approve an MR with vulnerabilities for it to be merged.
  • This enables developers to collaborate with security to determine whether the vulnerability is a false positive, insignificant, or requires a code change.
  • You can customize your scan result policy to only go in effect for a certain severity of vulnerability (low, medium, high, critical).
  • The policies are only enforced when the target branch for the MR is a protected branch.

Scan execution policies can be used to schedule pipeline runs on the desired interval.

  • Enforce these policies on all projects, whether or not they have a .gitlab-ci.yml file.
  • These are the future direction for GitLab and will be customizable to allow for custom CI job inputs into the policies.

Discovery + Roadmapping

The engagement is 8 days, and yet the demo above and deep dive sessions should only take a few days to deliver. So what does the rest of the engagement entail?

  • Remember, the goal of this engagement is to ensure the customer leaves with a foundational understanding of GitLab Ultimate security features AND a path for how to transition to using it. While we don't touch customer code in this engagement, the remaining engagement time can and should be dedicated to the following activities. Time spent on each activity may vary as this is just a general outline of discussion points.

  • The roadmap outline is a template that should be modified based on the customer's current information security maturity. To simplify this process, there is a Claude Project created to help generate a roadmap based on the information received from the customer through this engagement.

  • Setting expectations: It's crucial to clearly communicate what this service includes and what it doesn't. Some customers may have different expectations about what they've purchased, so clarify the scope early to avoid misunderstandings.

    1. Understanding the customer's current security setup and design.

    • What is your security team structure and group responsibility breakdown?
      • Do they have separate teams for QA, application security, compliance/governance, etc.?
      • Who is responsible for ensuring code in production is secure? How is this done today?
    • What security tools are you currently using and what are they used for?
      • Are the GitLab scanning solutions able to displace the customer's existing solutions?
      • What technology stacks does your business use?
      • Are there any applications that use languages or frameworks that aren't supported by GitLab?
      • What are your current security requirements, processes, and/or policies?
        • Do you have certain code scans that are required for certain applications or when deploying to certain environments?
        • When, if at all, do you require manual intervention and review of code?
        • How do you manage vulnerabilities today?
        • Do you have a standard way of enforcing all applications run the required security scans?
        • How do you manage security across a large number of applications?

    2. Identify why the customer is interested (i.e. what is not working so well with their current setup).

    • Are there too many disparate tools to manage?
    • Is there a lack of consistent process or security standardization between applications?
    • Are there too many manual processes that drain the resources?
    • Is there a lack of collaboration or even tensions between the security and development teams?
    • Is it too difficult to manage security and/or ensure all of the applications meet the necessary requirements?

    3. Using the above information, discuss topic by topic how GitLab can solve the customer's issues.

    • Examples:
      • Security policies can enforce security controls across applications.
      • Shifting security to the left can foster collaboration between security and developers to ensure all code is checked before moving to production.
      • The security dashboard allows you to manage vulnerabilities across projects, gather data about vulnerability remediation trends, and export that data for your own reporting purposes.
      • Security can easily be automated within pipelines.
      • All of the above can be done within a single platform to simplify the user experience for both developers and security team members.

    4. Using the above discovery information, design the security vision of what the customer's end state GitLab setup could look like.

    • Example:
      • 10,000 foot view: GitLab SAST, DAST, Secrets Detection, and Container scanning.
      • Organization: Top level group contains centralized repository of security templates with different scanning setups that are automatically enforced. Developers don't need to worry about including any security scans in their code as these security scans are automatically injected into the application pipelines. The security team has a single location for all of the templates, which makes it easy to manage and maintain. Developers can easily contribute back to those templates through issues and merge requests. The necessary security folks will be automatically asked to review any application code MRs that violate a security policy.
        • Workflow: Every code commit triggers a SAST and Secrets Detection scan. On merge request pipelines, additional scans can be run. There are different security policies assigned to differentiate between web applications, payment applications, business applications, etc., each with different objectives to match specific security requirements. Security professionals can use the Security Dashboard to pull reporting and trend data for vulnerabilities broken down by severity at both a group and project level.