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 as a spell checker 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.
Security tools like SAST are best when integrated directly into the Devops Lifecycle and every project can benefit from SAST scans, which is why we include it in Auto DevOps.
GitLab was recently named as a Niche player in the 2020 Gartner Quadrant for Application Security Testing.
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:
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.
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)
We are also working on a generic language-agnostic scanning approach. While currently experimental, 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.
User success metrics
The following measures would help us know which area of SAST on which to focus:
The SAST Category Maturity level is currently at Viable. We plan to mature it to Complete by January 2021.
For the next few releases, we are currently focused on cleaning up the state of our current scanners and improving support for additional configurations. As part of this initiative, we are working on creating a new SAST configuration UI to help make our security scanner configuration more approachable and easier to understand. This configuration UI will also lay the framework for us to introduce individual scanner rule customization.
We also want to bring our SAST scanners down to Core to make them available to the most people as part of our community stewardship commitment.
Why is this important?
GitLab needs at least a minimum level of coverage in the SAST feature set to check the box for compliance and buyer personas. But further SAST has a very real impact to help the world write better code. If Gitlab provides a basic level of SAST to all repositories on Gitlab, we can meaningfully help protect against the simplest of code security issues. That encourages Gitlab to be the source of security information for repositories. It also provides opportunities to show the breadth of GitLab's feature set, and how that enables more complete and holistic DevOps processes.
Differentiation
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.
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.
We can improve the experience even more, 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: 2020-05-03 Last Updated: 2020-05-02
