---
title: "Zsolt Imre — Fuzz testing is easy"
url: https://appsecpodcast.com/zsolt-imre-fuzz-testing-is-easy/
date: 2020-04-06
duration_seconds: 2254
guests: ["Zsolt Imre"]
topics: ["Security Testing", "API Security", "Vulnerabilities and Exploits"]
audio: https://www.buzzsprout.com/1730684/episodes/8122608-zsolt-imre-fuzz-testing-is-easy.mp3
video: https://www.youtube.com/watch?v=WFMYIeUDibg
transcript: true
---

# Zsolt Imre — Fuzz testing is easy

*April 6, 2020 · 38 min*

with [Zsolt Imre](https://appsecpodcast.com/guests/zsolt-imre/)

on [Security Testing](https://appsecpodcast.com/topics/security-testing/), [API Security](https://appsecpodcast.com/topics/api-security/), [Vulnerabilities and Exploits](https://appsecpodcast.com/topics/vulnerabilities/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122608-zsolt-imre-fuzz-testing-is-easy.mp3) · [Video](https://www.youtube.com/watch?v=WFMYIeUDibg)

## Show notes

Fuzz testing can sound specialized and difficult, but Zsolt Imre argues that teams can start small and learn quickly. He joins Chris and Robert to explain what fuzzers do, which defects they are good at finding, and how his path from offensive security to defensive engineering shaped GUARDARA. The conversation covers target selection, root-cause analysis, programming languages, protocol complexity, and why no single fuzzer fits every system. Zsolt offers a practical adoption path: choose a meaningful target, integrate feedback into development, and iterate. The result is an accessible guide for AppSec teams that want to add fuzzing without turning it into a research project.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Zsolt Imre:  
→ [GUARDARA](https://guardara.com/)

Mentioned in this episode:  
→ [GUARDARA](https://guardara.com/)

Chapters:  
00:00 Why fuzz testing is easier than it looks  
02:00 Zsolt Imre’s path into security  
04:00 Moving from offensive to defensive work  
07:00 What fuzz testing actually does  
09:00 Who benefits from fuzzing  
13:00 Finding and understanding root causes  
18:00 Choosing targets and programming languages  
23:00 Complexity, protocols, and coverage  
26:00 Why there is no one-size-fits-all fuzzer  
29:00 A practical way to get started  
34:00 Integrating fuzzing and iterating  
36:00 Final takeaways

## Transcript

*5,271 words · assemblyai*

**0:00 Chris Romeo:** Zsolt Imre is the founder and CTO of Guardera, with more than 15 years experience in cybersecurity, both on the offensive and defensive side. Zsolt explains fuzz testing for us, who does it, and why. He also helps us to understand how to deal with fuzz testing results and how to get started doing fuzz testing on your own. We hope you enjoy this conversation with—

**0:24 Robert Hurlbut:** Zsolt Imre.

**0:25 Chris Romeo:** Zsolt Emery. Are you trying to build a security champions program? Everyone is these days. One challenge of rolling out security champions is, how do we educate all these new folks? Security Journey has your answer. We provide a security dojo environment with level-based security education that gives your newfound champions a path to follow. And the best part? It requires almost zero administration by you. Visit www.securityjourney.com to set up a demo and learn how you can use the security Dojo to connect with your security champions.

**1:00 Robert Hurlbut:** Hey folks, welcome to another episode of the Application Security Podcast. This is Robert Hurlbut, Threat Modeling Architect. Glad to be here with you and with my co-hosts, Hey, Robert.

**1:24 Chris Romeo:** This is Chris Romeo, CEO of Security Journey, and also, I don't know, co-host of said podcast. And is it true, Robert, that you are broadcasting from the 100th floor of the Robert Hurlbut Mansion?

**1:37 Robert Hurlbut:** Well, I don't think I have 100 floors. In fact, I'm very positive I don't, but, uh, and it's definitely not a mansion.

**1:45 Chris Romeo:** Well, I was— I mean, I'm moving into marketing now, so I'm trying to like, you know, I'm, I'm selling up the You know, the experience for you there.

**1:53 Robert Hurlbut:** I appreciate it. I appreciate it. And today we have a special guest with us, Zsolt Emre. Welcome.

**2:00 Zsolt Imre:** Hi, thank you for having me.

**2:02 Robert Hurlbut:** Absolutely. And so, uh, to get started, we're going to be talking about, uh, fuzz testing here. But before we get into that, we'd like to know your story. What's your security origin story? How did you get started into this amazing field?

**2:19 Zsolt Imre:** Well, I started as basically a kid. I was around 13 years old, or maybe it was earlier, 12 years old. And I think I got lucky. I was surrounded by really smart people. They were usually older than me, but, you know, there were guys from the demo scene, there were some other guys doing some software cracking, especially when it was coming to games, you know, different kind of cheats. And I was just seeing what they were doing, and it was amazing, you know, like working with assembly code. At that time, I had no idea what it is. It was really cryptic, but at the same time, I was really curious. So I started learning from them. As the time moved on, I started looking into different areas. For example, software like cracking itself was something that I was always really interested in. Also antivirus and all the things that basically I couldn't get my hands on, except obviously for the viruses because we had lots of those. That's how everything started. Later on, I got into basically an online community mainly, uh, well, centered around cyberpunk. Um, so that's where the whole thing really, you know, got a boost. And also by the time I was older, I had more idea about how computers work, um, and so on and so on. So, uh, at some point I knew that I will always work with computers and I will, I, I will probably work with something related to security. Like, I had no clear idea what I'm about to do in terms of like which field in security, uh, at that point. But somehow I ended up on the offensive side. So that led straight— uh, straight— a couple years after, I ended up basically being a penetration tester. And I spent probably most of my career, uh, doing penetration testing, so on the offensive side. Only a few years ago, I basically switched to the defensive side, focusing more on trying to protect organizations from attacks, especially focusing on application security.

**4:51 Robert Hurlbut:** I'm curious, whenever you were in the offensive side and now you've switched over to defensive side, has a lot of what you did on the offensive side helped you a lot with the defensive side now?

**5:03 Zsolt Imre:** Yeah, I think probably it's not the technical side because that's something that everyone can learn. Everyone can learn how to, you know, write exploits, how to find vulnerabilities. It's what I personally believe is most important to have experience on the other side. Actually, the mindset that really matters, and it's good that knowing the mindset and having an idea on on how the attacker will actually try to find issues, how the attacker will try to actually combine different things, use different attack vectors in combination, is probably much more helpful than the technical skills themselves.

**5:43 Robert Hurlbut:** Good. And I actually, I've been on mostly the defensive side, but I've also veered over to the offensive side at times just to see what's going on. And I think it does help, you know, to sort of get a view of both. But glad you were able to join us back over on the defensive side. Appreciate your help because we need it.

**6:03 Zsolt Imre:** The offensive side is also the defensive side as long as you are a white hat, right?

**6:08 Robert Hurlbut:** True, true. That's true. All right.

**6:10 Chris Romeo:** Yeah, welcome home to the side where we need all the help. And see, our listeners know this is one of my, I guess, my soapbox things about how much issues about how much kind of perspective we put on the offensive side in the industry because that's, that's what's cool, that's what gets all the attention, but yet it doesn't actually fix any of the problems. And so it's pretty exciting to hear how you kind of made that transition where now you can use those skills to apply them to actually defending networks as well.

**6:40 Robert Hurlbut:** Again, uh, thanks for being here. And this interesting topic, we haven't covered it, uh, fuzz testing. Uh, that's something I've been interested in for a number of years. probably at least 10 or 12 years since I first saw about it. But for our listeners, why don't you take us through what is fuzz testing?

**7:01 Zsolt Imre:** Well, fuzz testing is an automated software testing methodology that basically dates back to the 1950s. And the whole process is basically about feeding an application with malformed data. Well, obviously, in order to find something unexpected.

**7:19 Robert Hurlbut:** You're sending in data that— because obviously, a lot of applications, a lot of systems are processing data all the time, but you're sending in something that's different than maybe what they expect, right?

**7:32 Zsolt Imre:** Yes, definitely. I like to use unit tests as a way to explain the difference between classical, well-known testing methodologies versus fuzz testing. So, when you think about a unit test, it's basically about when you write a unit test, you are testing a block of code. You have a set of valid input, and then you also know the expected outcome. And if the actual outcome of the execution is not what you expect, then you know you have an issue. So, when it comes to fuzz testing, it's basically the complete opposite of it. Sometimes we even call it negative testing. So, we provide the application with seemingly corrupted input. And I say seemingly because it's usually specially crafted to maximize the chances of triggering some unexpected behavior. And of course, because of this, we don't necessarily know the outcome of the test. So, we have to monitor it in different ways, monitor the application in different ways to find these anomalies.

**8:39 Robert Hurlbut:** Right. And then also to determine, is the application having a problem with it too. So you have to watch for that and validate that we do have a problem and now trace it back that it was this bit of data that caused the problem so that we can fix the application to properly handle this weird data, as we sometimes call it, coming through. So I'm curious, who's fuzz testing typically? I mean, who would do this sort of work?

**9:09 Zsolt Imre:** Typically, it's done by the security community. Obviously, the goal is to find vulnerabilities, especially those that can be exploited in one way or another. Now, fuzzing is really an efficient way to identify, for example, coding mistakes and edge cases developers didn't think about. As it's being a completely automated process, you have to start it and then you wait for certain results, then you analyze. You try to determine the root cause, and obviously if you think it's exploitable, you can start developing an exploit. Once you have an exploit, then it's a win. So that's the primary reason. And the security industry— I believe the security industry really adopted fuzzing early because they see the value in it. Exploiting vulnerabilities, well, there are certain vulnerabilities like memory corruption, it's a typical one, buffer overflows, heap corruption, and so on that can be fairly easily found by fuzzing. Especially the early days when we didn't have all these protections against exploitation, it was a great way to quickly find issues and exploit them. I think that's why fuzzing got really popular within the security community.

**10:35 Robert Hurlbut:** You said security folks do this. Any others that typically would run fuzz testing tools? Would developers do this, or is it primarily the security folks who introduce this into the pipeline, if you will?

**10:50 Zsolt Imre:** I think so far, and as I've seen, So far, it was mainly the security guys. Product security teams, I'm talking about the company. The product security team tries to integrate it into the development pipeline. Otherwise, fuzzing mainly happens, unfortunately, after product release. That's probably the worst case.

**11:15 Robert Hurlbut:** Your customers test you. They throw a bunch of stuff to it and see what happens.

**11:20 Zsolt Imre:** Yes. One of the things when it comes to quality assurance, I think that's a typical problem nowadays that basically instead of doing proper quality assurance, you're outsourcing the quality assurance, basically testing to the customers. I don't think that's a good idea.

**11:39 Robert Hurlbut:** Right. Now we know a little bit about fuzz testing and some of the things that it can do and why we want to take a look at it. How much is it being done? We talked about it should be done, and I think that makes sense, but is it being done these days?

**12:00 Zsolt Imre:** Well, you can see that things are improving. Nowadays, there is more emphasis on trying to create tools that can fit into the development lifecycle. There were quite a few challenges earlier with fuzzing, one of them being that fuzz— well, the actual testing process is really long. It takes an extremely long time, so you cannot really put a fuzzing solution, or at least at that time you couldn't really put a fuzzing solution inline into your development lifecycle, software development lifecycle. Now there are more and more tools trying to focus on to scale fuzzing so that the runtime is shorter. There are different approaches to this, but things are definitely improving.

**12:56 Robert Hurlbut:** In terms of just getting that data, you said also there's the length of time it sometimes takes to run your hundreds of thousands perhaps bits of data that you want to push through to test. but also generating that data, right? How do you do that and so forth? Has that been a hindrance as well in the past and are we better at that today?

**13:21 Zsolt Imre:** I think probably the generation of it is— well, that's not the real challenge when it comes to fuzzing. What is really a challenge is to find the root cause of an issue in an automated way and provide as much information as possible about something that was unexpected, something that the application didn't behave the way it was expected to, and you have to have an idea why that was and what was the exact test case that caused that anomaly. It's basically connecting a lot of information together. Um, when it comes to like actually generating the different mutations, I don't think a lot has changed. So previously we had fuzzers that, um, so that were mutation-based. There were fuzzers that were generation-based. There were dumb fuzzers, there were smart fuzzers, and I think that hasn't changed much during the years.

**14:36 Robert Hurlbut:** You mentioned one of the challenges, but I'm curious about also, once you run these fuzz tests, how are you determining that you actually do have a fault? How do you identify that there's a fault that has happened?

**14:50 Zsolt Imre:** Well, that's the challenging part. When it comes to fuzzing in terms of looking for vulnerabilities, there are obviously multiple ways to do that. So, and it depends on your target application as well, what you are targeting. So one of the most common and well-known is obviously fuzzing applications that communicate over the network. Most of the fuzzers are capable of doing that. And when, when you fuzz something over the network, for example, the most basic way to detect if something is wrong is based on the connection state. So you connect to your target, you send a test case, and then let's say you disconnect, you try to connect back again to send another test case, the next mutation, and then it turns out you cannot connect back anymore. So likely the previous test case caused something. So that's probably the most simple way. Uh, the problem with this approach is that you don't necessarily know what's going on on the other side. So it may be a crash, it may be just the process hanging, somehow it ended up in an infinite loop, and so on and so on. So probably a much better way to do it is to monitor the remote process status. So you would likely want to use something similar to a debugger, either a debugger or something like a debugger hacking that is capable of detecting a process crash. So that the process disappears and basically transmit this information to the fuzzer. And also same way being able to detect, for example, if it's just a thread that crashes. Because even though it can happen, for example, in the connection state-based detection, it can happen that, for example, you have a web server because that's That's the easiest to explain. You send a request and it's very likely that there will be a single thread that is going to be fired up to deal with the request, to process your request and return a response. Now, if you kill that thread, you can still connect back because the server will just fire up another thread. Basically, you miss out on the detection. That's why it's important to also have an idea about threat-related issues. But that's so far, it's only about finding issues in native applications written in usually C, C++, where a fault can easily result in a crash of a process. Now, when it comes to generic quality assurance and using fuzzing for generic quality assurance purposes, there are a lot more different ways that you can monitor your target and that you should monitor your target. So you can have a look at the console output. You can, for example, read and analyze log files, try to detect anomalies based on the response messages, try to monitor for performance-related changes. For example, suddenly there's a high CPU usage or memory utilization, that can be a sign of some issues, and so on and so on. I think really it boils down to what you want to test, and then based on that, you will get a better idea on on what are the areas that you should be looking at to detect anomalies.

**18:34 Chris Romeo:** So, I have a question then about kind of the target that you're going after. So, in my history, I've done and looked at fuzz testing from the perspective of appliances and software written in C and C++, like you were describing here. How does fuzz testing fit into our web-based world where we're all about web applications with various backends and various frontend frameworks. What's the role of fuzzing in the age of the web?

**19:06 Zsolt Imre:** So when it comes to web applications, especially about complex environments, because when you usually— when the security industry, actually security experts focus on something to find, let's say vulnerabilities, that happens usually in isolation. A target application, which can be anything, but it always— the testing is done in isolation. But when you have a complex environment where, let's say, it's a web application, and then you have a bunch of services running in the backend, databases, authentication services, authorization services, and so on and so on, that's a whole different story. the type of issues that you can identify is also completely different. Obviously, if your web server is written in C and it's vulnerable, then you will find the same issues. You can find memory corruptions. But in general, now we are in a world where we have Node.js, for example, where memory corruption is less likely to happen. The issues that you find is different. But To give you a really good example, and this is actually a real-life example that shows how fuzzing can be useful when it comes to complex environments, also web services. To give an example, there was this pretty big cloud service and there was a gateway service which was basically responsible of accepting requests, preprocessing them, and then passing through part of it to different services, different backend services. Something really interesting happened as I was fuzzing this whole environment and the only attack vector I had was through the gateway service. I hit something really interesting. It turned out that the data that I was generating hit the authentication and authorization service. Now this service had certain protections in place against request flooding and brute forcing password guessing attacks, and as a result it blocked the source IP address of the attack. Now the only problem is that the gateway service was masking my IP address, so the authentication authorization service saw the IP address of the gateway service. So you can imagine the authentication authorization service blocked the IP address of the gateway. So authentication from that point on wasn't possible anymore. And this is— I think it's a really good example because when you look at, for example, the authentication and authorization service in isolation, even if you notice that, oh, we have this really nice protection mechanisms in place, you may not necessarily think about potential configuration issues in a real-life environment, in a complex environment where you would mess the IP, the source IP, and, you know, this way you would end up having a denial of service scenario. So fuzzing can be used for more than just finding vulnerabilities. Well, you can consider this as a vulnerability because it ends up as a denial of service condition, but overall the root cause was a configuration issue. Of course, it was also a design issue because even though the authentication and authorization service blocked the address of the gateway, I could still send requests and the gateway still was doing processing while ideally I should have been blocked by the gateway so no further processing occurs. You can save bandwidth, you can save CPU, and so on.

**22:59 Robert Hurlbut:** So that again, yeah, it shows that it can be complicated, right, in trying to figure out the sources and where the faults are and trace them back to origin and so forth. And then what you expect, right, and different expectations. So interesting. What other challenges have you seen in fuzz testing?

**23:23 Zsolt Imre:** Oh, well, there are many. One of the challenges is obviously when it comes to finding the right tools. Most of the fuzzing solutions that you have out there, be it open source or commercial, they are focusing on native applications and finding security issues. That's the only thing that— well, not the only thing, but primarily that's the focus is, No one seems to be interested for some unknown reason in using fuzzing for what it was really invented for, for quality assurance purposes. The other thing is the slow speed that was previously much slower. I think that's something that scares away people. Because even now, as we are improving and fuzzing takes much less time than it used to, it can still take sometimes hours or sometimes even days to run a fuzz test with decent coverage. Also, the environment has changed a lot. Again, when you test something in isolation, That's one thing and might be suitable for finding security issues, but everything has changed in the past, I don't know, let's say 10 years. We have complex environments, multiple services, things are running in the cloud, software stack has changed a lot, programming languages have— well, we have completely different set of programming languages than we used to have. Later, uh, like several years ago, we had primarily like C, C++. Lots of applications was written in C++, but nowadays you see web services, web applications popping up everywhere. There are obviously technical challenges that are related to fuzzing itself, primarily around how to detect issues, because it's it's not trivial. And people most often expect a product to be able to do everything, which it doesn't have, of course. So I think when people realize that when it comes to fuzzing, there is always some manual work involved, so it requires a human element at one point or another, be it for example, setting up the product or the tools that you have, integrating it into your development lifecycle, and also dealing with the issues. I think there are things that scare away people, and probably that's the biggest challenge.

**26:25 Robert Hurlbut:** Okay. With all the— obviously, there are a few challenges here, but And maybe you've already answered this, but is there a one-size-fits-all solution? And I think the answer is probably no, right? Because we have all the different kinds of applications and all the different interfaces and so forth.

**26:44 Zsolt Imre:** Yes, yes, that's right.

**26:46 Robert Hurlbut:** And different focus. And like you said, originally this was mostly for QA, quality assurance, being able to do their work. And now it seems that maybe the focus has sort of shifted more towards the security end. But really, I guess, you know, there's a lot of different folks who could use this and could benefit, it sounds like. So how does someone get started? You know, maybe this is the first time they've heard about fuzz testing, and/or maybe they've heard about it before but they haven't really dived into it and understood it. How would they get started? What do they need to do to get started?

**27:24 Zsolt Imre:** First of all, you will need some coding skills. At least being able to write some basic code, that's something you cannot really avoid. Also, if you are really starting from zero, what I usually recommend is to start by writing a piece of code that works in any programming language, and then try manually feed that with data. Try to provide data that may trigger some issues. For example, if you created a single method, for example, in Python that adds 2 numbers, see what happens if one of the arguments is a string or, well, it has known types, so it's basically None. See how your application will react. Or if you have written code in C or C++ that, for example, takes a filename and opens the file, and prints the content. See what happens, for example, if you provide a zero-length filename, so basically an empty string, or a very, very long filename over 4,000 characters long, or you provide an extremely long file. It depends, and then you can see what will happen. Sometimes it will be able to trigger certain issues and also moving forward, try to come up with other ideas on how you could break your own code, and finally try to automate this whole process as much as possible. And the reason why I'm saying is that this— because the— this exercise will not only give you an idea of what fuzzing is and why it's extremely useful, but it will also help you to pick the right tools later on. So you will get to know what makes too powerful and you will learn about their limitations. Of course, you will also learn about your actual needs. If your goal is to fix these issues, like the issues that you find, there's a good chance you will also need some debugging skills. If your goal is to find vulnerabilities, then likely you will need reverse engineering skills at some point. and obviously exploit development skills too.

**29:40 Robert Hurlbut:** Okay. I noticed that you were also encouraging, certainly, I know we talked a little bit about the challenges, but still encouraging many to use fuzz testing, and if they haven't already, to go ahead and start looking at it. How can developers, and also as we talked about QA, get started with this? What can they do?

**30:01 Zsolt Imre:** Well, obviously they can do the same things I just said earlier.

**30:04 Robert Hurlbut:** Yeah.

**30:05 Zsolt Imre:** Okay.

**30:06 Robert Hurlbut:** All those things we talked about, right? So the skills of development and, uh, and understanding the results and— okay, so all those, all those things still apply. Okay.

**30:17 Zsolt Imre:** Yes, yes, yes, definitely. And of course, after that, um, it would definitely make sense to see what applications are to be tested. So likely there will be many. And you will have to prioritize that, obviously. Then you have— then after that, you have an idea what you are really looking for. What are the capabilities of a fuzzer that you need? So you can have a look, uh, for open source tools or commercial tools, which one fits the best. Or if none, you may end up writing your own tools, because many do, uh, for good reason, probably. Obviously, you have to identify the right set of tools for your target. I would also recommend to start small and try to test something relatively simple and then keep improving. I don't look at fuzzing as something that you put into its place into your development lifecycle and everything is immediately covered. You are testing everything, all protocols, all applications, all file formats, and so on. So that's probably not only not cost-effective, but one of the things that I usually find that people don't really like having a backlog full of vulnerabilities. So just, you just simply cannot start by finding thousands of issues and filling the product team's backlog with different problems, they will freak out and it's not manageable. Also, in that case, if you put something there that will do all kinds of magical things, it will draw your attention away from certain things that you should be looking for, like, are the tools that we are using actually doing what it's supposed to do? How well is it performing? What is our coverage? What are the things that we cannot really test. So there are many things that you have to look for when it comes to finding the right tools. And also, obviously, you want to figure out how you can ideally come up with a solution that can be in line. So, you know, if something, if something really serious is found, then you definitely don't want to release that to production. But that's quite challenging on its own. As I said earlier, fuzzing is still quite a slow process, and the speed also changes based on what you're testing, your environment, and so on and so on. But for example, I think this is something good, and that's something I also do. When I write code, one thing I do is, At the same time I run unit tests, I run fuzz tests basically on a method level or on the functions that I'm testing using unit tests. I write a lot of Python code. I have a Python library that implements a fuzzer. The only thing I have to do is I just have to add a decorator in front of the function that I want to test. So I have to decorate the function and then it will be fuzz tested and it takes maybe just a few seconds and then I will know if there's anything significant there. So that's also an option. I think what everyone should be looking at is how to move fuzzing as close to the beginning of the development lifecycle as possible.

**34:12 Robert Hurlbut:** Okay, so it becomes a part of other things that you do. So, all right, great advice.

**34:19 Zsolt Imre:** Yeah, one of the issues with fuzz testing, and so we can say this is one of the challenges, is that fuzzing happens, well, basically almost at the end, right, the development lifecycle. So best case, it happens during the testing phase. Worst case, it happens after release.

**34:38 Robert Hurlbut:** Right?

**34:38 Zsolt Imre:** Right. After release, that's really bad. It can have serious impacts. But let's take the better case, which is the testing phase. But by that time, you already have implemented tons of code being pushed into a repository by several developers, then you built the whole thing. which may take for hours, and then you run tests, like including fuzz testing that can take hours, worst case days. Only after that you will learn about that you have 10 high severity vulnerabilities. Or let's say 10 critical issues that would break your application, or some features are still not working. because you haven't thought about certain edge cases or you haven't configured the environment properly and so on and so on. So it's really important to get to know about as many issues as possible as close to the actual software development process. So if you're a developer and you can start fuzz testing as simply as you would run unit tests locally on your laptop, probably that's that's the best you can do. I'm not saying that that's the only thing you should do, because later on when it comes to the testing phase, when you have an environment where things are running together, obviously it makes sense to test the complete environment as well because it will yield a completely different set of issues.

**36:18 Robert Hurlbut:** Okay, good. That's great. I've learned a lot here. I thought about different times that you put this in place and you Changed my thinking a little bit in terms of when you get started and how do you integrate and go with an iterative approach. I like that as well. So interesting way of thinking about it.

**36:38 Zsolt Imre:** That's why I really appreciate this opportunity to talk about it because, you know, I think this can be done simpler and it's really useful. So the more people know about it, the more we can improve the quality of the products that we have.

**36:54 Robert Hurlbut:** Absolutely. And we thank you for sharing with us today.

**36:58 Zsolt Imre:** Thank you for the opportunity.

**37:02 Chris Romeo:** Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute And Robert, @RobertHurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/zsolt-imre-fuzz-testing-is-easy/