Category Direction - Static Application Security Testing (SAST)

1. You are here:
2. GitLab Direction
3. Product Stage Direction - Secure
4. Static Analysis group priorities
5. Category Direction - Static Application Security Testing (SAST)

• SAST
  • Introduction and how you can help
  • Overview
  • Strategy and Themes
  • 1 year plan
    • What is next for us
    • What we are currently working on
    • What we recently completed
    • What is Not Planned Right Now
  • What SAST is and isn't

SAST

Stage	Secure
Maturity	Complete
Content Last Reviewed	2024-01-26

Introduction and how you can help

This direction page describes GitLab's plans for the SAST category, which checks source code to find possible security vulnerabilities.

This page is maintained by the Product Manager for Static Analysis, Connor Gilbert.

Everyone can contribute to where GitLab SAST goes next, and we'd love to hear from you. The best ways to participate in the conversation are to:

• Comment or contribute to existing SAST issues in the public gitlab-org/gitlab issue tracker.
• If you don't see an issue that matches, file a new issue.
  • Post a comment that says @gitlab-bot label ~"group::static analysis" ~"Category:SAST" so your issue lands in our triage workflow.
• If you're a GitLab customer, discuss your needs with your account team.

Overview

GitLab SAST runs on merge requests and the default branch of your software projects so you can continuously monitor and improve the security of the code you write. SAST jobs run in your CI/CD pipelines alongside existing builds, tests, and deployments, so it's easy for developers to interact with.

While SAST uses sophisticated techniques, we want it to be simple to understand and use day-to-day, especially by developers who may not have specific security expertise. So, when you enable GitLab SAST, it automatically detects the programming languages used in your project and runs the right security analyzers.

We want to give everyone the tools they need to write high-quality code, so basic SAST scans are available in every GitLab tier. However, organizations that use GitLab SAST in their security programs should use Ultimate. Only GitLab Ultimate includes:

• Proprietary technology for suppressing false positive results and tracking vulnerabilities as they move through codebases.
• Integrating SAST results into the merge request workflow.
• Vulnerability Management, Security Policies, and other capabilities that help you enforce security requirements.

Strategy and Themes

We want to help developers write better code and worry less about common security mistakes. SAST should help prevent security vulnerabilities by helping developers easily identify common security issues as code is being contributed and mitigate proactively. SAST should integrate seamlessly into a developer’s workflow because security tools that are actively used are effective.

• Prevent - find common security issues as code is being contributed and before it gets deployed to production.
• Identify - continuously monitor source code for known or common issues.
• Mitigate - make it easy to remediate identified issues, automatically if possible.
• Integrate - integrate with the rest of the DevOps pipeline and play nicely with other vendors.

The importance of these goals is validated by GitLab's DevSecOps Landscape Survey, which consistently finds that:

• Many organizations include security testing too late in the software development lifecycle.
• Developers are critical to remediating application security issues, but often don't have access to security tools.

1 year plan

GitLab Static Analysis and Vulnerability Research teams are collaborating to address important opportunities to improve the customer experience with SAST.

We're prioritizing these themes for feature delivery:

1. Result quality: Security professionals and developers should be able to trust every result from GitLab SAST.
   • This is our most important initiative, because detection is the key task for any SAST product.
     • This work improves the user experience directly, but also indirectly by reducing the pressure on other workflows, for example by reducing how often users must complete workflows like result triage and analysis.
   • Our work in this area includes two major areas:
     • Detection engine: Improving the detection engines used to process and analyze code, including the development of a new next-generation detection engine.
     • Detection rules: Adding, removing, and updating the detection rules that the detection engines use.
2. "Day 1" experience and "Day 2" efficiency: We believe that SAST can improve every codebase by supporting human reviewers, so we want to make SAST easy to enable ("Day 1") and operate going forward ("Day 2"). Concretely, this includes:
   • Consolidating coverage from multiple separate analyzers to Semgrep-based analysis using GitLab-created rules. This provides a simpler, more consistent operational experience; allows GitLab to directly manage rules; and makes scans run faster.

We're prioritizing these themes for future design and discovery efforts, following recent feature releases:

1. Triage and remediation experience: We value our users' time, and making it easier to understand a potential vulnerability improves the chances it'll be resolved.
   • We recently added SAST findings in the MR diff view.
   • We are now looking for new opportunities to improve this experience, with an emphasis on smaller changes that have outsize impact.
2. Shifting further left: GitLab SAST already scans code as soon as it's pushed, before code reviews even begin. But, we are investing in IDE integrations to offer scanning even earlier, including before code leaves developer machines.
   • We recently released two major iterations of IDE integration, adding CI/CD pipeline-based security scan results to the VS Code IDE.
   • We have completed initial technical discussions toward real-time SAST scanning in the IDE.

What is next for us

In the next 3 months, we are planning to work on:

• Result quality:
  • Continuing to update the SAST detection rules that GitLab creates and maintains, focusing first on removing low-value rules to reduce false-positives before focusing on adding new rules to reduce false-negatives.
• "Day 1" experience and "Day 2" efficiency:
  • Consolidating additional language-specific analyzers by delivering GitLab-managed rules in the Semgrep-based analyzer.

What we are currently working on

We are currently working on:

• Result quality:
  • Continuing to update the SAST detection rules that GitLab creates and maintains, focusing first on removing low-value rules to reduce false-positives before focusing on adding new rules to reduce false-negatives.
• "Day 1" experience and "Day 2" efficiency:
  • Consolidating NodeJS scanning into the Semgrep-based analyzer.
    • This change will be fully released in 17.0 as part of the analyzer consolidations released each year in the major (.0) GitLab release.
  • Documenting intended changes to analyze coverage in the upcoming major GitLab 17.0 release.

What we recently completed

Our recent work includes:

• Integrating SAST results into the MR diff view (in the Changes tab). This project involved updating the Code Quality inline diff feature and adding SAST results to it.
• Significant improvements to the default SAST ruleset, delivering substantially fewer false-positive and false-negative results in 16.8 and future releases. See epic 10907 for further progress.
• Improvements to the automatic resolution of findings from removed rules. This makes the rollout of rule removals significantly clearer for users.
• Improvements on the recently released integration of CI/CD pipeline-based security scan results into the VS Code IDE.
• Improvements to Advanced Vulnerability Tracking (AVT). We expanded AVT to all possible analyzers and improved the algorithm to handle more cases. These improvements were released iteratively during 16.2, 16.3, and 16.4.

Check older release posts for our previous work in this area.

What is Not Planned Right Now

We understand the value of many potential improvements to GitLab SAST, but aren't currently planning to work on the following initiatives:

• Expanding language support: Currently, we're focusing on making it easier and faster to use SAST on the many languages and frameworks we already support, rather than adding support for new languages. However, if we don't support a language you use, you can:
  • Tntegrate third-party tools (open-source or proprietary) using our documented, open report format.
  • Document your request by opening an issue or commenting on an existing issue in epic 297.
• Incremental scanning: We're currently focusing on making all scans faster rather than developing different types of scans for different cases, such as incremental scans that scan only modified code.

What SAST is and isn't

SAST helps developers identify weaknesses and security issues early in the software development lifecycle, soon after code is written.

SAST does:

• Use static analysis techniques to find issues early in the development process.
• Identify weaknesses, which may be vulnerabilities, in the code it scans.
• Analyze the control and data flow of your program, check how functions are called, and otherwise analyze what the code could do at runtime.
• Help find issues that code reviewers or tests might miss.

SAST doesn't:

• Find known vulnerabilities in software dependencies; this is software composition analysis.
• Run code and attempt to trigger unexpected behaviors; this is dynamic analysis.
• Look for generic bugs or maintenance issues; this is Code Quality.
• Replace code reviewers or tests; it augments them instead.