Traditionally, organizations use static analysis tools to parse the code for known weaknesses. These are categorized flaws in coding practices known as Common Weakness Enumerations (CWE)s. Or they use software composition analysis to find known vulnerabilities. These vulnerabilities are assigned by MITRE a number known as a Common Vulnerability Enumeration (CVE).
Fuzz testing looks at a third area: unknown or zero-day vulnerabilities. These are more dangerous in that if a bad actor should find one first, it could cause serious damage. Testing for unknown vulnerabilities should be included in your testing regime.
In 2016, DARPA turned to hacking and sponsored a capture the flag (CTF) challenge, the Cyber Grand Challenge, to see whether machines could successfully find and patch software vulnerabilities. This was an automated version of a typical capture the flag competition, but it had wider implications. By automating redundant processes, developers should be able to do more.
White-box (Known) testing examines the functionality of an application with access to its internal structure. It is also known as Clear Box Testing, Open Box Testing, Glass Box Testing, Transparent Box Testing, Code-Based Testing or Structural Testing.
Black-box (unknown) testing examines the functionality of an application without access to its internal structure or code. It can be applied to third-party binaries, for example.
When organizations think of application security testing (AST) tools, static analysis security testing, or SAST, immediately comes to mind. There are several benefits to bringing SAST into your development pipeline, starting with: it’s just good security hygiene.
There are also a number of downsides, starting with a high number of false positives, and the lack of adequate code coverage. That’s where fuzzing can help. If SAST can find the known vulnerabilities and weaknesses in your code, fuzzing can find the unknown vulnerabilities -- the ones that criminals like to exploit.
A penetration test, or pen test, is an authorized cyberattack on a computer system. It is performed as a means of evaluating the overall security of that system, often with limited prior knowledge of the test. This is not to be confused with a vulnerability assessment which looks for known vulnerabilities in a system. Penetration testing services are typically time-boxed and therefore are not continuous.
A zero-day vulnerability refers to a bug or defect that has not been reported to the vendor and therefore does not yet have a workaround or patch available. These unknown vulnerabilities are valuable to malicious actors who can exploit these for years without detection. For example the Heartbleed vulnerability, which gave bad actors the opportunity to extract private information from websites, was in the wild for nearly two years before it was discovered.
New zero-days are continuing to be found. For example, no matter how strong we build our web browsers, that does not prevent hackers from trying to break new things in them. One researcher used fuzzing and other tools to successfully escape the Chrome sandbox.
Want to learn more about Fuzzing, see Your Ultimate Guide to Fuzz Testing
Want to learn more about DevSecOps, see our Components of a Successful DevSecOps Program