Fuzz testing, or fuzzing, is the act of inputting unexpected, malformed and/or random data to measure response or stability of an application or service. This is accomplished by monitoring for unexpected behavior or service / application crashes. The goal of fuzzing is to discover software defects that need to be addressed as these defects may lead to (exploitable) vulnerabilities.
Fuzz testing can be performed using one of the two fuzz algorithm strategies:
Fuzz testing can also be applied two different ways:
There are two primary target audiences:
There is an additional role which may be included in the target audience. Product verification (PV) engineers may leverage fuzz testing as part of their unit or regression tests. If the software development team does not directly handle their unit test creation, a PV engineer may be partnered with a software development team to create and maintain unit tests on behalf of the software development team.
Each target audience has different challenges that need to be addressed with our fuzz testing solution:
GitLab will provide its users with application robustness and security visibility testing solutions which validate the entire application stack. This will be provided by verifying the user’s application or service both while at rest (white-box testing) as well as while running (black-box testing). This will include historical trending and recommendations for next steps to provide peace of mind to our customers.
Furthermore, GitLab will provide real-time remediation for user solutions running in production. This will be possible by analyzing the user issues found in GitLab Secure and apply “virtual patches” to the user’s production application or service leveraging GitLab Defend. This will allow your organization to be secure and continue functioning until the underlying vulnerability can be remediated in your code.
The next step is to provide a minimal support for fuzzing as part of GitLab DAST offering. Users can set up dedicated pipelines and run fuzzing sessions. This is the very minimal goal to dig into this category.
Wireless, Bluetooth, and Automotive based fuzzing as these types of fuzz testing solutions require special hardware to accomplish. This makes these types of fuzz testing out of scope.
Additionally, our initial focus is on network applications and services, so we are not focusing on fuzzing local desktop or mobile applications at this time.
The fuzz testing competitive landscape is composed of both commercial and open source testing solutions. The following outlines the competitive landscape for fuzz testing solutions:
GitLab already uses OWASP ZAP today to power the DAST capability within the GitLab Secure offerings. ZAP is a web application security scanner, leveraging a proxy to perform testing, and does not perform protocol-level fuzzing. All fuzzing by ZAP is performed within the context of the web application being tested.
Analysts consider fuzzing to be part of Application Security Testing and is generally discussed as part of those reports, rather than as a standalone capability. There are challenges to make it part of the DevSecOps paradigm, and they are interested to hear more about that.
By combining our fuzz testing solution with our DAST, IAST, and SAST solutions into a GitLab Secure suite, GitLab can be placed into the Gartner Magic Quadrant for Application Security Testing. This will give GitLab additional exposure as well as show security thought leadership.
Other analyst firms include 451 Research and IDC as they have focused security practices in which GitLab Secure can be highlighted and show leadership.