TREN
Schedule a MeetingSchedule a Meeting

Vulnerability Research

Fuzzing

We test your product's input-handling code with large numbers of automatically generated unexpected inputs. We report discovered crashes and memory errors with their root causes.

Schedule a MeetingAll services in this area

What it is

Fuzzing feeds a program automatically generated invalid or unexpected inputs. Coverage-guided fuzzing keeps inputs that reach a new branch and derives new inputs from them. Compiler sanitizers make memory errors visible even if they do not cause a crash. Each bug is recorded with the smallest input that triggers it.

Scope

  • File format parsers and media handlers
  • Network protocol handlers and state machines
  • Schema-based fuzzing for REST and gRPC APIs
  • A fuzzing harness and seed corpus for each target
  • Integrating fuzzing into your CI/CD pipeline and tracking findings

The need

When organizations need it

  • When your product processes external input in a memory-unsafe language such as C or C++.
  • When you use a custom binary protocol or file format.
  • When crash reports from the field increase and the cause cannot be identified.

Method

How we work

  1. Target selection

    We identify functions that process external input and pose memory safety risks.

  2. Harness and corpus

    We write a harness for each target and prepare a seed corpus from valid samples.

  3. Execution

    We run fuzzing with coverage measurement and open unreached code sections by improving the harness.

  4. Triage

    We deduplicate crashes and assess the root cause and exploitability of each.

Outcome

What you have at the end

You receive the bugs found, with their root causes and triggering inputs. The harnesses and corpus remain with you, allowing fuzzing to be rerun on every new release.

Frequently asked questions

Which languages is fuzzing useful for?

It finds the most memory errors in memory-unsafe languages. In languages such as Rust, Go, or Java, it also uncovers unhandled exceptions, infinite loops, and excessive resource use.

Are our live systems affected?

Fuzzing is run in a build or test environment separate from live systems. No input is sent to live systems.

Can fuzzing be a one-time exercise?

A single run can find bugs. It provides the most value when run continuously as the code changes. We recommend integrating the harnesses into your CI/CD pipeline.

Vulnerability Research

Other services in this area

Let's talk about this service.

Tell us briefly what you need. We will agree on the scope and timing together in the first meeting.

Schedule a Meeting