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.
This context informs our SAST direction.
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:
