Why Fuzz Testing Is Indispensable: Jarkko Lamsa

I recently spoke to Gartner on the addition of fuzzing to their Critical Capabilities for the Application Security Testing Magic Quadrant. In that conversation, one analyst shared that companies that implement fuzz testing programs never rip them out. Why? They’re just too valuable. 

This is a bold statement, especially in the world of application security where strategies are around tool augmentation and diversification, leading to frequent rotation of tools within product security programs.

So, in this series, I am going to look to my network to get validation and uncover more details on this observation.

In the last piece, I reached out to Billy Rios. In this piece, I reached out to fuzzing expert Jarkko Lamsa. Laemsae was a former software engineer and an early member of Codenomicon, the security research firm responsible for finding the Heartbleed vulnerability. Since, he has helped organizations implement product security and DevSecOps programs that include Application Security Testing technologies such as static analysis, software composition analysis, interactive Application Security Testing, and, of course, fuzz testing.  

See what Lamsa had to say about fuzzing in the interview below:

-----------

Takakura: What makes fuzz testing indispensable? 

Lamsa: Implementing fuzz testing into developer pipelines has long term returns, unlike other Application Security Testing tools. SAST is a popular testing technique, but it’s akin to planting a tomato.

With tomato plants, you must replant them every year in order to continuously bear fruit. Similarly, SAST requires ongoing maintenance in the form of tuning, validating results, and triaging to continuously gain value out of them.

On the other hand, fuzz testing is much like planting a peach tree. The upfront work may be greater, but you can reap fruits for the next 30 years with little continuous investment. 

Takakura: In your experience, how often has fuzz testing programs been pulled out of an organization? Why or why not?

Lamsa: The reasons for pulling fuzz testing out has been for political reasons rather than technological reasons. Aside from this one instance, I’ve not experienced a fuzz testing program being pulled out. As mentioned earlier, the continuous returns of fuzz testing programs for little ongoing maintenance is what makes it so difficult to pull out. The long-term returns for fuzzing programs are high, so there is an incentive for keeping fuzz testing programs.

Takakura: Why do you think fuzz testing is trending at the moment?

Lamsa: The devops movement has really helped fuzzing gain traction in the last couple years. People are finding that fuzzing is scalable and delivers accurate results, thus they’re connecting the dots that it’s a good appsec technique for devops.

It also helps that there’s low noise with fuzzing, unlike SAST. It’s also developer-friendly and not checklist driven. These attributes all make adoption easier. Any security program that aims to truly minimize risk and work in devops has to be developer friendly.

Takakura: How can we make fuzz testing more accessible and approachable?

Lamsa: I would consider fuzz testing to be accessible and approachable when it’s easy for stream aligned teams, instead of requiring a highly specialized team. This allows for scalability. Also, I would consider fuzzing accessible and approachable when it’s easy to set up without specialized knowledge, easy to automate, easy to integrate, and easy to resolve findings.

Takakura: What’s your philosophy on the “right” way to go about fuzzing?

Lamsa: When it comes to fuzzing, I believe there are 4 critical activities for finding targets that increase fuzzing value:

1. First, assess your attack surface 
2. Then, identify high exposure code
3. Next, of the high exposure code, identify high risk code that compromise safety and/or security if maliciously fuzzed
4. Finally, as a part of release tickets, show evidence of fuzz testing in the form of metadata. Example metadata that comes to mind include code coverage, test cases generated for the target, and/or proof of exploitation.

-------

Check out the first installment of this blog series with Billy Rios here. 

Want to learn how you can get started with fuzzing? Reach out to one of our security experts here. We’d be happy to help.