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
    • GitLab's solution
  • 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

SAST

Stage	Secure
Maturity	Complete
Content Last Reviewed	2023-08-23

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. It helps developers identify weaknesses and security issues earlier in the software development lifecycle before code is deployed. 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.

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

SAST checks source code to find possible security vulnerabilities. It helps developers identify weaknesses and security issues earlier in the software development lifecycle before code is deployed.

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 behaviors 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.

Security tools like SAST are best when integrated directly into the DevOps Lifecycle. We believe that every project can benefit from SAST scans, so we include it in Auto DevOps and make SAST scanning available at all GitLab tiers, including Free. Additional features, including proprietary code analysis and integration with GitLab Vulnerability Management, are available only in GitLab Ultimate.

GitLab's solution

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, all 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.

To learn more, check the SAST documentation.

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. Important themes include:

1. Result quality: Security professionals and developers should be able to trust every result from GitLab SAST. Our work in this area involves:
   • Improving the detection engines used to process and analyze code, including the development of a new next-generation detection engine.
   • Adding, removing, and updating the detection rules used with the existing engines.
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 means:
   • 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.
   • Improving the default configuration of analyzers so they can be on by default, supporting our Convention over Configuration product principle.
3. 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 are working to:
   • Present SAST findings in context with modified code so each finding is easier to understand.
   • Improve the clarity of the guidance and reference material provided with each result.
   • Augment our efforts with AI to better explain vulnerabilities including the specific vulnerable code.
4. 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, before code leaves developer machines.

We expect different parts of these initiatives to deliver value in the short, medium, and long term.

Outside of these proactive priorities, we also react quickly to functional bugs.

What is next for us

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

• Result quality:
  • Curating the detection rules that GitLab creates and maintains.
• "Day 1" experience and "Day 2" efficiency:
  • Consolidating NodeJS scanning into the Semgrep-based analyzer.
• Triage and remediation experience:
  • Integrating SAST results into the code diff view of merge requests (in the Changes tab). This project involves updating the Code Quality inline diff feature and adding SAST results to it.
  • Improving Advanced Vulnerability Tracking by expanding the number of supported languages and handling additional cases where unrelated changes could cause tracking failures.
• Shifting further left:
  • Integrating security scanning results into the VS Code IDE, Integrating results sourced from CI/CD pipeline-based scans into the VS Code IDE.
  • Investigating approaches to real-time IDE-based scanning, advancing past the first CI/CD pipeline-based iteration.

What we are currently working on

We are currently working on:

• Result quality:
  • Communicating in the product about changes to SAST rules, as part of the first phase of our rule curation effort.
• "Day 1" experience and "Day 2" efficiency:
  • Consolidating NodeJS scanning into the Semgrep-based analyzer.
• Triage and remediation experience:
  • Integrating SAST results into the code diff view of merge requests (in the Changes tab). This project involves updating the Code Quality inline diff feature and adding SAST results to it.
  • Improving Advanced Vulnerability Tracking by completing expansion to all possible analyzers and finalizing algorithm improvements. This builds on improvements we released iteratively during 16.2 and 16.3.
• Shifting further left:
  • Completing follow-up iterations on the recently released integration of CI/CD pipeline-based security scan results into the VS Code IDE.

We are also looking forward by investigating approaches to:

• Real-time IDE-based scanning, advancing past the first CI/CD pipeline-based iteration.

What we recently completed

Our recent work includes:

• Showing security findings in the VS Code IDE (with findings from CI/CD-pipeline-based scans) (16.3).
• Further expansion of coverage and improvements to the algorithm used in Advanced Vulnerability Tracking (16.3).
• Updated error handling in the Semgrep-based analyzer (16.3).
• New documentation of how SAST rules work (16.3).
• Improvements to SAST rules and customizability of Semgrep-based scanning (16.2).
• Expansion of coverage and improvements to the algorithm used in Advanced Vulnerability Tracking (16.2).
• Shared ruleset customization files across multiple projects (16.1).
• Clearer guidance and better coverage for SAST detection rules (16.1).
• Semgrep-based scanning for Scala code (16.0).
• Auto-resolution for findings when rules are disabled or removed, including removal of false-positive-prone default rules (15.10).

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 request support by opening an issue in epic 297 with details. Or, you can integrate third-party tools using our documented, open report format.
• 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.