Security testing allows you to evaluate the robustness of applications and systems and identify potential weaknesses that attackers may exploit. DAST and fuzzing are two popular, important, and proven security testing methods. DAST (dynamic application security testing) searches for security vulnerabilities and weaknesses by executing the application, whilst fuzz testing – or fuzzing – is an automated software testing method that injects invalid, malformed or unexpected inputs into a system to reveal software defects and vulnerabilities. Fuzz is also a form of dynamic testing and can be seen as a form of DAST with its own specific testing technology.
Where typical, classic DAST solutions use black-box testing, fuzzing may apply white-box testing. Solely relying on DAST tools doesn’t necessarily give you an advantage over attackers, as attackers can also employ similar tools. To detect weaknesses earlier than attackers, companies need to leverage their knowledge about internal design. This is where the white-box fuzz testing approach is helpful.
Fuzz testing can be especially useful because malicious hackers often use fuzzing techniques to find software vulnerabilities. Fuzzing also helps you to uncover bugs that would not have been detected through more conventional testing methods (such as static analysis) or manual audits.
Understanding DAST
Dynamic application security testing (DAST) has been around for several decades. DAST is the approach of analyzing a web application from the front-end to find vulnerabilities through simulated attacks. This type of approach evaluates the application from the “outside in” by attacking an application like a malicious user would. Does the behavior of the application differ from predefined correct responses? Does the program crash? If either happens, you know that there is an error or a bug in the application.
Advantages of DAST are that it can be used independent of the application and on software for which the tester doesn’t have the source code. DAST also immediately finds vulnerabilities that could be exploited. DAST scanners interact with a running application, enabling it to detect both compile-time and runtime issues within an application. DAST also has low false positive rates. It’s also language agnostic, meaning it can be used for applications written in any language for any environment.
Some limitations of DAST include:
- It often doesn’t allow you to find the exact location of a vulnerability or a bug in a code.
- You need a decent amount of security knowledge to correctly interpret reports, especially when compared with fuzzing.
- It can be very time-consuming, meaning time needed to run tests.
- You need a special testing infrastructure and customization.
The rise of fuzzing
Overall, fuzz testing and DAST have many similarities. The big difference is that the goal of fuzz testing is not necessarily to find specific vulnerabilities, but rather to identify conditions which will trigger exceptions and crashes in the target system for further investigation by security professionals. This allows you to find and fix issues before they become security incidents.
More and more companies are turning to fuzz testing. According to Forrester, 65% of security decision-makers are adopting fuzz testing, while 16% plan to implement it.
Microsoft, Facebook, and Google have been using fuzzing for ages. They were early adopters of fuzzing technologies to test their own systems. Since launching in 2016, Google's OSS-Fuzz, a free fuzzing platform for critical open-source projects, has helped fix over 8,800 vulnerabilities and 28,000 bugs across 850 projects.
Key fuzzing techniques include protocol (aka black-box fuzzing) and source code (or white-box) fuzzing. Protocol fuzzing involves testing the behavior of a server when bad content is sent over a given protocol, whilst source code fuzzing focuses on the source code while the app is running, probing it with random input in an effort to uncover bugs. Read more about the difference between protocol and code fuzzing here.
Two chief fuzzing principles are generator-based and mutation-based fuzzing. The first creates test values from scratch, while the latter modifies existing values to create new ones and, therefore, requires some baseline input.
Advantages of code/white-box fuzzing
White-box fuzzing has several advantages over traditional black-box DAST, including:
- As it tests source code, it runs earlier in the development process at the unit, integration, and system testing stages.
- It measures code coverage.
- It integrates into the CI/CD pipeline - with any ticket tracking system, such as Jira, and any IDE through unit testing.
- It enables developers to reproduce issues and identify root causes in minutes.
- White-box fuzz testing finds vulnerabilities that are impossible to expose with black-box testing.
- Fuzzing is often more cost-effective than DAST and manual testing methods.
White-box fuzzing by Code Intelligence: each bug is pinpointed to the exact code line in the repository
Real-world success stories
To illustrate the potential of fuzz testing, let us look at some real-world fuzzing successes. Fuzz testing enabled the telecommunications operator Deutsche Telekom to complete projects much faster. Feedback-based fuzzing led to a shortened testing time (the test time per project fell by 66%), more advanced bug detection, a maximization of productivity because developers could go on programming code instead of hunting bugs and security issues, and a decrease in developer time through a fully automated solution and easy-to-use IDE plugin.
Tech giant Google discovered 16 security leaks in the Windows kernel through fuzzing. The vulnerabilities occurred when processing TrueType and OpenType fonts and, in the worst case, could allow an attacker to take over the computer.
Continental, a German multinational automotive parts manufacturing company, leveraged fuzz testing to: 
- Reach compliance with ISO 21434 for UN R155 regulation and pass ASPICE for cybersecurity.
- Implement measurable security: they continuously find and fix critical bugs and monitor code coverage.
Watch the webinar recording “How Continental leveraged fuzz testing and ASPICE for cybersecurity to comply with ISO 21434” and learn how Continental built an automated security testing process as part of scalable CI/CD infrastructure by applying fuzzing at the Software-in-the-Loop level (SiL).
Start fuzzing!
Would you like to discover the power and benefits of fuzz testing and team up with a partner that can provide you with all the necessary expertise and experience? Book a Demo to discuss how your testing strategy can benefit from fuzzing.