Scope of the project
If you recognize the benefits that fuzz testing can bring to your software security but are new to it, read on. In this blog post, you’ll learn what you need to consider before implementing fuzz testing in your company to ensure a smooth and successful adoption.
So, you’ve chosen the light side and decided to find and fix bugs in your code before they become a problem. Well done, and congrats! 🎉 Now let’s talk about what you need to know and decide on to make fuzz testing a success within your team or organization.
To get started, you’ll need to answer a few key questions.
1. Where should you start fuzzing?
When teams introduce fuzz testing for the first time, it’s usually on a tight budget, with little prior experience and no professional support. There’s often pressure to demonstrate value quickly, so choosing the right starting point is crucial.
Our advice: start small and simple. Developers often get tempted to tackle the most complex, bug-prone systems first. But when starting with fuzz testing, simplicity is your friend.
Choose a self-contained, security-relevant module that’s not just used internally. For example, a widely reused C/C++ library that’s part of your public-facing or critical infrastructure is a strong candidate. This approach has two advantages:
- It’s easier to scope and fuzz effectively.
- It allows you to demonstrate the real-world impact of fuzzing early on, by surfacing bugs in components that matter to external stakeholders or customers.
In the automotive industry, a good starting point could be a parser or communication protocol library that’s already undergone some security review. Even if it’s been tested before, fuzzing often finds unexpected issues, helping you build momentum and trust in the process.
And when you find something, be kind to whoever last audited the code. The goal of doing fuzzing is to collaboratively work with developers to improve the security of the software.
2. Who Needs to Be Involved?
Fuzzing is teamwork. Here are the three core groups to involve from the beginning:
- Developers – to integrate fuzzing into development workflows and fuzz their code.
- Security teams – to guide the overall risk and vulnerability management strategy.
- Infrastructure/DevOps teams – to set up and maintain the necessary tooling and resources (e.g., cloud compute, CI pipelines).
Security teams, in particular, should involve developers from day one, not just in execution, but in the decision-making process. When teams align around a shared goal, adoption becomes easier, and results improve faster.
3. How Do You Enable Fuzzing?
Before running your first fuzzer, a few technical prerequisites need to be in place.
Make Sure the Code Is Testable
The easiest way to begin is by leveraging existing unit tests. In most projects, unit tests already exist to validate functionality.
One can use unit tests as starting points to implement fuzz tests that test realistic workflows. The good thing about unit tests is that they are self-contained examples of how to use a given function/method/AP, including all needed setup and cleanup code.
You can use these unit tests as scaffolding to:
- Feed fuzz inputs into key functions and modules.
- Isolate failures quickly.
- Iterate without needing full system integration.
Identify Ideal Targets
Focus on any function, method or API that already has unit tests.
These components typically yield valuable results in the early stages and can be fuzzed independently.
AI agents can help identify the best targets automatically. Read more on that here.
Ensure Access to Large Language Models
When doing white-box fuzz testing, you need to create fuzz tests. Large Language Models (LLMs) come in handy when you want to automate manual steps associated with fuzz testing. For example, the AI Test Agent by Code Intelligence automatically identifies fuzz targets, generates test cases (harnesses) and runs them.
To leverage this kind of automation, you need to ensure access to LLMs, whether they are open-source (e.g., Llama 3 70B, Deepseek V3, R1) or closed-source (e.g., GPT, Claude).
4. How Do You Measure Success?
To understand the impact of your fuzzing efforts, track these key metrics:
- Code coverage – How much of your codebase is exercised by fuzz tests?
- Unique crashes found – Are you detecting new types of bugs? Are they meaningful?
- Speed of test execution – How efficiently are tests running?
These metrics help demonstrate the value of fuzzing internally, improve test quality over time, and guide resource allocation as your program matures.
Final Thoughts
Start small, involve the right people, and iterate fast. With the right foundation, fuzz testing can quickly become one of your most effective tools for proactive software security.
Have questions about starting fuzzing in your own environment? Drop us a message.
