What it does
OSS-Fuzz is Google's continuous fuzzing program for qualifying open-source projects. A project maintainer adds fuzz targets and a build configuration to the project's source, then submits an integration for review. Accepted projects are built and fuzzed continuously using supported engines and sanitizers, with findings routed to the project's contacts. It is a service for testing code that handles complex or untrusted input, not a scanner that can be pointed at any repository without preparation or approval.
Start with a code path that accepts difficult input
OSS-Fuzz is useful when a maintainer can identify a parser, decoder, or other component that consumes untrusted or complex data. The integration guide asks projects to supply one or more fuzz targets, a build script, and project metadata. A typical setup includes a Docker build environment and a project.yaml that names the project, language, repository, and contacts. The target should be maintained with the project's own source rather than left as a detached experiment.
After preparing the integration, the maintainer submits it to the OSS-Fuzz repository for review. Once accepted and merged, the project is built and run on the service's ClusterFuzz infrastructure; the project documentation describes continuous integration and bug disclosure. The infrastructure supports engines including libFuzzer, AFL++, and Honggfuzz and uses sanitizers to help expose memory and undefined-behavior problems.
Admission is selective. The FAQ says OSS-Fuzz considers established projects with critical impact on infrastructure and user security, and closed-source projects cannot use the hosted service. A team outside that scope can look at ClusterFuzz as a separately deployed option, but that is a different operating burden. No fuzzing was run for this listing.
Strengths
- Accepted projects receive continuous, distributed fuzzing rather than a one-time local scan.
- The documented setup supports several fuzzing engines and sanitizer configurations.
- The integration can be maintained alongside the project's source and build configuration.
Watch out for
- Projects are admitted case by case, with priority for established open-source projects that have critical infrastructure or security impact.
- Maintainers must supply fuzz targets and a build environment before the integration can be reviewed.
Best for
- Maintainers of widely used open-source parsers, codecs, and other software that processes untrusted input
- Projects that can maintain fuzz targets and want continuous coverage-guided testing
Sources
- OSS-Fuzz Documentation (Oct 26, 2026)
- Getting started | OSS-Fuzz (Oct 26, 2026)
- Setting up a new project | OSS-Fuzz (Oct 26, 2026)
- Frequently Asked Questions | OSS-Fuzz (Oct 26, 2026)
- oss-fuzz/LICENSE at master · google/oss-fuzz · GitHub (Oct 26, 2026)