Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Vision - Fuzzing


Fuzzing is testing technique focused on finding flaws and vulnerabilities in applications.

It consists in sending arbitrary payloads instead of valid input, in order to trigger exceptions and unintended code paths that may lead to crashes and unauthorized operations.

Given the arbitrary payload is mostly random, the attacked doesn't need to know many details about the expected input. Normally a huge amount of data is sent to the application while monitoring the effects, looking for crashes. This is what makes this attack very different from other specific attacks.

Once a possible problem (crash) has been found, attackers can focus on it, checking which are the exact conditions to trigger the bug, and if they can be fine-tuned to obtain some useful result.

Even if random data is used, normally it has some well-known structure in order to pass the first-level input validation made by the application. For example, if you want to attack a web application, the payload will be a valid HTTP request, but random data (fuzz) will be used to create parameters names and values.

Target audience and experience

Fuzzing is unlikely to be useful to developers, since it is just about discovering possible flaws. Since it is also very time-consuming, it should not block the development process, but be part of a security analysis that is executed as a separate process.

This approach is primarily on the radar of very specific industries, where code is often deployed on embedded devices. For example, healthcare, automotive, electronics, and everything related to IoT.

With the category moving to maturity, it can be useful for Security Researches that want to spot vulnerabilities as their primary goal, targeting libraries and other software used by the application.

What's next & why

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.

Maturity Plan

Competitive landscape

There are open source tools and a few commercial ones that do fuzzing.

A few examples:

See this issue for a complete list.

Analyst landscape

Analysts don't have specific reports for fuzzing. The topic is sometimes discussed with their customers. There are challenges to make it part of the DevSecOps paradigm, and they are interested to hear more about that.

Top Customer Success/Sales issue(s)

Top user issue(s)

Top internal customer issue(s)

Top Vision Item(s)