The Dynamic Analysis group at GitLab is charged with developing solutions which perform Dynamic Analysis Software Testing (DAST) and Fuzzing. Our work is a mix of open and closed source code.
| Repo | Purpose |
|---|---|
| DAST | The DAST Analyzer which is deployed as a docker image. |
| Browserker | GitLab's proprietary crawler currently undergoing development |
| API Fuzzer - Private | GitLab's API Fuzzing scanner. |
| Repo | Purpose |
|---|---|
| API Security | Private - The API Security tool performs API Fuzzing and API DAST scans |
| GitLab Protocol Fuzzer (CE) | GitLab's Protocol Fuzzer (Community Edition), previously Peach Protocol Fuzzer |
| GitLab Protocol Fuzzer (EE) | Private - GitLab's Protocol Fuzzer (Enterprise Edition), previously Peach Protocol Fuzzer, includes licensed components. |
| API Fuzzing E2E Tests | Private - API End to End Tests |
| GitLab Cov Fuzz | Private- GitLab's coverage fuzzing orchestration that integrates fuzzing engines/results with GitLab CI and GitLab Security Dashboard |
| Repo | Purpose |
|---|---|
| JSfuzz | Javascript Fuzzer |
| Pythonfuzz | Python Fuzzer |
| Javafuzz | Java Fuzzer |
| Repo | Purpose |
| HAR Recorder | A utility to record HAR files based on web traffic |
| Repo | Purpose |
|---|---|
| Coverage Fuzzing Examples | Coverage fuzzing examples in 7+ languages/Fuzzers |
The DAST team also monitors #s_secure and #sec-section. Both these channels are for wider Secure topics, however are a good place to start if you are not sure which group in Secure to contact.
The Dynamic Analysis group largely follows GitLab's Product Development Flow.
Issues worked by this team are backend-centric and are typically in one the above repos, vendored templates, and GitLab's Rails monolith. At times, issues can require support from Secure's frontend team if UI changes are required. We will require more notice for initiatives like these.
There are several maintenance tasks that need to be completed each milestone. Each iteration, an issue is opened and assigned to an engineer on a rotating basis. Those rotating tasks are:
Our dynamic analysis testing group works primarily as 3 sub-teams, a DAST team(Go/Python/Rails), a coverage guided team(Go/Rails) and an API Security/Fuzzing team(C#/Python).
The DAST analyzer we build relies heavily on OWASP's ZAP open source software and ZAP Extensions. This means the accuracy and quality of the DAST analyzer is impacted by the quality of the underlying OSS.
We monitor the underlying tools for changes and for vulnerabilities.
ZAProxy and ZAP Extensions do not have significant test coverage and therefore changes in those tools could impact DAST in unexpected ways. Since our expectation is that customers run DAST in a CI environment and stability and security is of utmost importance, we do not necessarily ship the latest ZAP build. We actively review the ZAP changelog and evaluate whether new updates deliver value to our customers and their use cases. We may ship a pre-release build of ZAP or a versioned build if we determine it contains valuable updates for customers and it passes our CI pipelines.
An assigned backend engineer reviews upstream updates at least monthly to identify new bug fixes or features. Those changes are presented to the Product Manager for prioritization into DAST.
The DAST analyzer is migrating towards using exclusively a browser-based DAST tool that is being built by GitLab. The tool has internally been referrred to as Browserker. Browser based DAST was released as GA in 15.7. The browser-based DAST is being delivered iteratively, with each new iteration taking over some parts of analysis previously done by ZAP, with the eventual goal of deprecating ZAP completely.
Web API Fuzzing requires generating files that allow the Web API fuzzing tool to know what parts of the application to fuzz.
Our goals is to simplify and reduce as many of the steps that a customer needs to do to get started. We want to focus our efforts on creating samples, defaults, and intelligence that will simplify fuzzing onboarding.
We use additional labels to categorize different areas of the application.
~"Category:API Security"
~"Category:DAST"
For fuzzing we use the following labels.
~"fuzzing::coverage"
~"fuzzing::api"
~"fuzzing::protocol"
When opening up issues, the following label snippet often added:
API Fuzzing Issues:
/label ~"Category:API Security"
/label ~"group::dynamic analysis"
/label ~"devops::secure"
/label ~"backend"
/label ~"section::sec"
Coverage Fuzzing Issues:
/label ~"Category:Fuzz Testing"
/label ~"fuzzing::coverage"
/label ~"group::dynamic analysis"
/label ~"devops::secure"
/label ~"backend"
/label ~"section::sec"
DAST Issues
/label ~"Category:DAST"
/label ~"group::dynamic analysis"
/label ~"devops::secure"
/label ~"backend"
/label ~"section::sec"
The Dynamic Analysis welcomes community contributions. Community Contributors– please make sure to add the label "group::dynamic analysis" to any Merge Requests or Issues to ensure the Dynamic Analysis team sees your contribution.
Community contributions should get prompt feedback from one of the DAST engineers. All engineers on the DAST team are responsible for working with community contributions. If a team member does not have time to review a community contribution, please tag the Engineering Manager, so that they can assign the community contribution to another team member.
(Sisense↗) We also track our backlog of issues, including past due security and infradev issues, and total open System Usability Scale (SUS) impacting issues and bugs.
(Sisense↗) MR Type labels help us report what we're working on to industry analysts in a way that's consistent across the engineering department. The dashboard below shows the trend of MR Types over time and a list of merged MRs.
(Sisense↗) Flaky test are problematic for many reasons.
For our Merge Request types, we have an initial soft target ratio of 60% features, 30% maintenance, and 10% bugs based on the cross-functional prioritization process. This is not a hard target and we expect to see variation in this ratio as we mature and our focus evolves.
The Dynamic Analysis engineering team provides support to GitLab Support Engineers following the process outlined in the Sec Section support project.
GitLab uses error budgets to track availability.