The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Static Application Security Testing (SAST) checks source code to find possible security vulnerabilities. SAST helps developers identify weaknesses and security issues earlier in the software development lifecycle before code is deployed. SAST usually is performed when code is being submitted to a code repository. Think of it like spell check for security issues.
SAST is performed on source code or binary files and thus usually won't require code to be compiled, built, or deployed. However, this means that SAST cannot detect runtime or environment issues. SAST can analyze the control flow, the abstract syntax tree, how functions are invoked, and if there are information leaks to detect weak points that may lead to unintended behaviors.
Just like spell checkers, SAST analyzers are language and syntax specific and can only identify known classes of issues. SAST does not replace code reviewers, instead, it augments them, and provides another line of proactive defense against common and known classes of security issues. SAST is specifically about identifying potential security issues, so it should not be mistaken for Code Quality.
GitLab was recently named as a Challenger in the 2021 Magic Quadrant for Application Security Testing and a Contender in Forrester's 2021 SAST Wave.
Watch recent GitLab Kickoffs covering Static Analysis direction updates:
Overall 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.
The importance of these goals is validated by GitLab's 2020 DevSecOps Landscape Survey. With 3,650 respondents from 21 countries, the survey found:
“GitLab Secure enables us to ship faster. Our other scanner tools could take up to a day to finish scanning whereas Secure scans finish as little a few minutes” - Healthcare services organization, GitLab Ultimate Customer
We want to make SAST easy to set up and use, making complexity transparent to users where possible. GitLab can automatically detect the programming language of a project and run the appropriate analyzer. We support a variety of popular languages and frameworks.
We want to increase language coverage by including support for the most common languages. We look at a variety of sources to determine language priorities including industry trends, projects hosted on GitLab, as well as analyst reports (italics below indicate languages called out specifically in analyst reports).
Language priorities (in addition to our existing language support):
If we don't support a language you use, you can request support by commenting on this epic with details.
We are also working on a next generation language-agnostic scanning approach. While currently experimental and in active research, this generic scanning presents many opportunities to move faster and put more focus on the security rulesets rather than the implementation of those rules in various scanners. This is be a strategic focus for GitLab SAST during 2021 and our 14.X release cycle.
User success metrics At GitLab, we collect product usage data to help us build a better product. You can see growth of GitLab SAST on our performance indicators dashboard.
The following metrics are also of interest as they help us know which area of SAST on which to focus:
The SAST Category Maturity level is currently at
Complete. We plan to mature it to
Lovaable by late 2023.
With all of our open-source based SAST scanners now available in our Free tier for all GitLab users, and UI-based configuration tools for all customers, we're turning our focus to data quality and accuracy improvements.
We also are continuing our efforts with our next generation generic language-agnostic scanning approach. This will bring improvements to our vulnerability detection engine, vulnerability fingerprinting and tracking accuracy, as well as help reduce false positives to provide developers increased context for taking action to remediate SAST findings. This next generation SAST scanner will be a propriatry tool build ontop of research by our Vulnerability Research Team and uses advanced detection techniques like abstract syntax tree parsing. This approach allows this next-generation scanner to analyze data and control flow to understand how logic and data flow through source code to identify vulnerabilities. We will inially use this approach to improve accuracy and reduce false positives by leveraging this next-gen scanner to validate findings from our existing SAST tools.
With Static Analysis now taking over Code Quality, we're looking to streamline some of the experience between SAST and Code Quality. One area we're actively working on is annotating MR diff files with inline vulnerability alerts which is a recent feature for code quality. This will compliment our existing MR security widget and make it easier for developers to see vulnerablities in files they are working on inline just like in their IDEs.
What our Product Designer walk through our plans:
As part of our transition to next generation SAST engine, we're also looking to streamline our exsiting suite of 15 SAST analyzer tools. GitLab SAST historically has been powered by over a dozen open-source static analysis security analyzers. These analyzers have proactively identified millions of vulnerabilities for developers using GitLab every month. Each of these analyzers is language-specific and has different technology approaches to scanning. These differences produce overhead for updating, managing, and maintaining additional features we build on top of these tools, and they create confusion for anyone attempting to debug.
The GitLab Static Analysis team is continuously evaluating new security analyzers. We have been impressed by a relatively new tool from the development team at r2c called Semgrep. It's a fast, open-source, static analysis tool for finding bugs and enforcing code standards. Semgrep's rules look like the code you are searching for; this means you can write your own rules without having to understand abstract syntax trees (ASTs) or wrestle with regexes.
Semgrep's flexible rule syntax is ideal for streamlining GitLab's Custom Rulesets feature for extending and modifying detection rules, a popular request from GitLab SAST customers. Semgrep also has a growing open-source registry of 1,000+ community rules.
We are excited about what this transition means for the future of GitLab SAST and the larger Semgrep community. GitLab will be contributing to the Semgrep open-source project including additional rules to ensure coverage matches or exceeds our existing analyzers.
Why is this important?
In 2020, GitLab greatly expanded access to SAST to all our customers including our Free tier users. In 2021, we want GitLab SAST to be industry-leading with high-signal findings and low false-positive rates. SAST has a very real impact to help the world write better code. With wide accessibility to SAST and high-quality security data built directly into the DevSecOps workflow. GitLab will be able to leverage the context of not just repository source code, but also how projects are built, deployed, and changes over time. We'll be able to further integrate all of our application tools to make them smarter, more accurate, and more automated.
“GitLab Secure allowed us to consolidate spend with centralized tools enabling a more streamlined workflow for our developers” - Retail product research organization, GitLab Ultimate Customer
Gitlab uniquely has opportunities within the entire DevOps lifecycle. We can integrate across different DevSecOps stages leveraging data, insight, and functionality from other steps to enrich and automate based on SAST findings. We even allow integration with partners and competitors to ensure flexibility. This allows teams to choose specific SAST solutions that fit their unique needs without GitLab being a constraint. This centers GitLab as the system of control and allows people to extend and integrate other solutions into the GitLab DevSecOps workflow.
Many well-known commercial products provide SAST solutions. Most of them support multiple languages and provide limited integration into the development lifecycle.
Competitors are focused on a few areas:
Here are some vendors providing SAST tools:
GitLab has a unique position to deeply integrate into the development lifecycle, with the ability to leverage CI/CD pipelines to perform the security tests. There is no need to connect the remote source code repository, or to use a different interface. GitLab is consistently now having enterprise customers replacing traditional Security scanning tools in favor of GitLab's fully integrated Security Scanning tools:
“GitLab Secure replaced Veracode, Checkmarx, and Fortify in my DevOps toolchain. Secure scans faster, more accurate, and doesn’t require my developers to learn new tools” - Financial services organization, GitLab Gold Customer
We can improve the experience even further by supporting additional features that are currently present in other tools.
We want to engage analysts to make them aware of the security features already available in GitLab. They also perform analysis of vendors in the space and have an eye on the future. We will blend analyst insights with what we hear from our customers, prospects, and the larger market as a whole to ensure we’re adapting as the landscape evolves.
Last Reviewed: 2021-07-01
Last Updated: 2021-07-01