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.
Stage | Secure |
Maturity | Viable |
Content Last Reviewed | 2024-10-30 |
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:
gitlab-org/gitlab
issue tracker.@gitlab-bot label ~"group::static analysis" ~"Category:SAST"
so your issue lands in our triage workflow.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.
While basic SAST scans are available in every GitLab tier, organizations that use GitLab SAST in their security programs should use Ultimate. Only GitLab Ultimate includes:
The ideal/typical customer profile for GitLab SAST is affected by our pricing, our packaging (as part of Ultimate), and the market that our company addresses overall. Customers approach SAST and other GitLab security products in a way that's somewhat different from other areas of the product.
There are at least a few big-picture aspects to mention:
These large factors have led us to a few foundational design goals and constraints:
Those foundational goals are helpful, but not specific enough to guide all decisions. Going one level deeper, we can use beliefs like the following:
The customer context described above informs our strategy.
We need to meet "table stakes" requirements because we aren't creating the market or introducing customers to the concept of a SAST product for the first time. Nearly all of our customers have used a SAST product, or at least a related product like a linter or quality tool, before.
And, most organizations adopting Ultimate are going to compare us to other tools. Typically, they are either:
In both cases, customers will design some kind of evaluation or testing process, ideally in collaboration with their account team. These can be very quantitative, comparing results and FP/FN rates, or they can be more qualitative. Sometimes the evaluation is on a benchmark app like DVWA, JuiceShop, or OWASP Benchmark; evaluators often view these as "simple tests" so they expect GitLab SAST to perform well on them, even if they are unrepresentative of the organization's typical code. Other times the evaluation is based on the organization's real code.
The upshot is that we need to perform well enough in these evaluations to get through to the next stage of the evaluation. In other words, our platform value proposition, or other features like security policies, don't get a chance to compete if we aren't at least close in terms of result quality and clarity.
Similarly, we need to avoid being eliminated for lacking common "checklist" buyer features, like offering cross-file analysis, IDE integration, or ability to implement policies.
Often, the best products rely on some kind of "unfair advantage" against competitors. (For some companies, that's access to a brand-new technology; for others, it's the opportunity to start fresh without a legacy stack and customer base; for others, it's an uncommonly powerful sales and marketing motion; for others it's pricing or packaging.)
We will "punch above our weight" if we leverage GitLab's unique advantages. Those advantages include:
GitLab SAST must exist in certain tiers based on our business model.
Not all features or languages are equal-value.
Our customers expect the features we have previously released to continue to exist, so we disfavor removing capabilities entirely. This means that we should assume that we need to continue to maintain the support matrix and features we current have. For example, if we have declared support for scanning a particular language, we cannot easily remove it.
However, this doesn't mean that we need to invest the same amount of effort or achieve the same sophistication for every language or feature. For example, it is completely appropriate to continue to use open-source scanners to power less-commonly-used languages like Apex or Elixir until the appropriate customer demand shows us that we need to invest more resources in developing improved technology for those languages.
Our technology stack going forward must:
Some customers want a product that "just works"—more of a black box than anything. Others will want to customize scan behavior to detect custom problems, for example insecure use of an internal library, that would not be appropriate to ship in a global ruleset to all customers. Roughly speaking, most customers are closer to the "black box" mentality; a smaller proportion of security teams prefer the customization approach—typically those who have a Security Engineering approach and build significant hands-on expertise within their teams.
One strength of GitLab as a product is that we offer many basic "primitives" that customers can use in creative ways to achieve their goals. But, it is easy to allow a product to become very complicated and hard-to-use in the service of endless customization. GitLab's configuration principles include:
We should be opinionated about the interfaces we offer, including the types of customizations we support, so that we can give customers simplicity and maintain our own technical flexibility. For example, customers sometimes want to ban calls to particular libraries or functions.
The two options here differ greatly in:
GitLab Static Analysis and Vulnerability Research teams are collaborating to improve the customer experience with SAST.
We've identified four themes that summarize the work we're planning and completing:
In the next 3 months, we are planning to work on:
Name | Overall status | One-month plan | Three-month plan |
---|---|---|---|
Add new code-flow UI to explain Advanced SAST results Tracking issue/epic |
Shipped in the vuln report, MR widget, and pipeline security report. | Complete implementation in MR changes view, address UX issues. (Development work is being handled by the Security Platform Management group.) | |
Complete functional testing and analysis for Vulnerability Resolution Tracking issue/epic |
In progress; substantially complete. | Continue data analysis. | Move on to additional feature improvements, as listed below |
Real-time SAST scanning in the IDE: initial release Tracking issue/epic |
Expecting 17.6 (November 2024) for Experiment release on GitLab.com. | Deliver Experiment release | Move on to post-initial-release improvements, as listed below |
Provide guidance on how to evaluate GitLab SAST Tracking issue/epic |
Initial guide shipped | Implement further edits to the evaluation guide | Publish benchmark/example project guide, based on analysis project listed below |
Restructure and update Advanced SAST docs now that the feature is GA Tracking issue/epic |
In progress | Complete most issues in this epic | Complete entire epic |
Advanced SAST engine maintenance, testing, and stability improvements Tracking issue/epic |
Planned for the majority of 17.5/17.6 for SAST:Core team | Implement improvements | |
Analyze Advanced SAST performance against standard benchmarks Tracking issue/epic |
Analysis and rule updates in progress | Continue analysis and rule updates | Complete work; use results to update documentation |
Implement the next level of documentation for rule/CWE coverage Tracking issue/epic |
Assessing implementation options | Interview internal users and develop technical plan | Ship documentation |
Enable Advanced SAST for PHP Tracking issue/epic |
In progress. ETA TBD. | Finalize engine support, migrate/implement rules | |
Expand coverage for Vulnerability Resolution to more CWE types Tracking issue/epic |
Create a plan. Implement changes so new feature iterations can be tested. | Begin experiments based on this plan | |
Expand real-time SAST in the IDE Tracking issue/epic |
Will beging after the initial Experiment release | Respond to feedback and next steps after the initial Experiment release | Work toward self-managed support; improve user-perceived latency |
After the next 3 months, we plan to work on:
Name | Overall status |
---|---|
Implement Advanced SAST for C/C++ Tracking issue/epic |
|
Incremental pipeline-based scans (skip unmodified code) Tracking issue/epic |
Currently blocked by database decomposition |
Enable Advanced SAST for additional languages Tracking issue/epic |
Waiting for other languages, as listed above. See epic for language priority order. |
Reshape SAST customization; allow org-specific Advanced SAST Tracking issue/epic |
Analyzing customer use cases to develop requirements |
Enable Advanced SAST by default Tracking issue/epic |
Likely to occur in GitLab 18.0 due to breaking-change requirements. |
Make SAST results easier to understand and triage Tracking issue/epic |
Coordinating with Security Risk Management stage for scheduling |
Our recent work includes:
Check older release posts for our previous work in this area.
We understand the value of many potential improvements to GitLab SAST, but aren't currently planning to work on the following initiatives: