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.
We believe that the world is safer when everyone can contribute to software security. Our customers, and those they serve, are better protected when developers and security professionals can fix potential security risks earlier.
The earliest possible time to catch a security issue is when the code is first written. GitLab sees code very early in the software development lifecycle, since we store production code and also support customer workflows (like merge requests) for pre-production development. So, our group is uniquely positioned to integrate static analysis everywhere as part of a comprehensive DevSecOps platform. We can do what others can't by making security omnipresent, and by supporting collaboration right in the tools that development teams are already using to do their jobs.
Building on those fundamental beliefs, the Static Analysis group's business purpose is to build value for GitLab and our customers…
We are responsible for ensuring that customers can use GitLab Ultimate to:
Our responsibility is for the full customer experience—not just security analyzers or specific software systems we maintain. At times this may mean:
We will do what it takes to deliver these customer results—our customers use the entire product to do their jobs, so it's important that we collaborate effectively with other groups to deliver end-to-end results.
This page is a summary of how Static Analysis invests our time and energy, and how we make those decisions. It:
However, it doesn't:
For group members:
We all should know why our group exists, what we're shooting for, and what GitLab needs from us to be successful as a business.
Sometimes, it can be hard to understand a prioritization decision, or a de-prioritization can feel like an indication that an idea is not valuable at all. Having a shared understanding of our group's role in the business and our current areas of investment should help explain this type of decision, and make it possible for more team members to come to the same conclusion independently.
This document (in particular the lists above) are likely to be incomplete at any given time, but the goal is to clarify and improve them over time. Any questions, suggestions, or opportunities for clarification are very welcome.
For others:
This page is designed to clarify competing priorities between feature categories and provide a high-level summary of the problems the Static Analysis group plans to tackle.
Team members can see more details in the group charter; search "Static Analysis group charter" on Google Docs to find the doc.
| Name | Rationale | Needs | Status/progress |
|---|---|---|---|
| Improve rulesets in Semgrep-based scanning | SAST is a high business priority, and false positives significantly impact customers | Static Analysis backend engineering to support rollout, including auto-resolution. Vulnerabilty Research for rule updates. | False-positive reduction is currently in progress and targeted for 16.4, with additional updates to come. See iteration plan for details. |
| Add SAST findings to the MR Changes tab | Massive UX improvement for the most common task: triaging findings. Near-complete development should be finished. | Frontend engineer (1) | In progress. Iteration 1 complete, Iteration 2 in progress. Both to be released together. |
| Finish MR findings in IDE | Improve UX of new feature while context is fresh. | Frontend engineer (1) | In progress. |
| Secret Detection POC | Net-new customer value. New MVC possibility that came up recently and may deliver value faster. | Backend engineers (multiple) | Research spikes in progress. |
| Name | Rationale | Needs | Status/progress |
|---|---|---|---|
| Identify any post-MVC changes needed in the IDE integration | We are getting ready to pause this initiative and would like to have a clean place to wrap up. | UX assessment/testing of existing feature | Development in progress; UX review in progress (issues filed) |
| Support the delivery of SAST findings in the MR Changes tab | Important feature is near delivery | Identify any risks or blockers to shipping. Provide reactive support to FE eng as needed. | Development in progress; needs UX review |
| Finalize assumptive Jobs To Be Done for SAST remediation workflow | Focus is on the remediation workflow because more users are exposed to this flow (all developers) than the configuration flow (mostly security admins) | Collaborate with UX Research | UXR started |
| Create assumptive Jobs To Be Done for Secret Detection remediation workflow | Existing JTBDs focus more on AppSec vulnerabilities that can be remediated with a new code change; secret leaks can't be fixed that way. New JTBD canvas should explore the security incident response job performer in greater detail to prepare for larger changes to Secret Detection. | Collaborate with UX Research | UXR starting soon |
| Big-picture design for revamped Secret Detection | We're getting ready to implement new architectural patterns for Secret Detection based on recent technical research. As we plan new flows and system components, we should take the opportunity to make sure we are meeting our job performers' needs well. | Collaborate with UX Research on JTBDs; create low-fidelity designs or other artifacts to show users will complete their jobs | Not yet started |
| Stage | Secure |
| Content Last Reviewed | 2023-09-14 |
| Content Last Updated | 2023-09-14 |