OSS-Fuzz - continuous fuzzing for open source software.
Go to file
Kostya Serebryany c64f14dcc5 Update README.md 2016-11-18 17:01:09 -08:00
docs Update faq.md 2016-11-18 16:56:35 -08:00
infra [infra] moving test command into base-runner, using it on jenkins 2016-11-18 16:46:26 -08:00
targets [curl] static libraries 2016-11-18 16:43:16 -08:00
.gitignore Implement a helper script. 2016-09-01 16:37:12 -07:00
CONTRIBUTING Create CONTRIBUTING 2016-10-12 13:26:26 -07:00
LICENSE Create LICENSE 2016-10-03 12:24:25 -07:00
README.md Update README.md 2016-11-18 17:01:09 -08:00

README.md

OSS-Fuzz - continuous fuzzing of open source software

Status: Beta. We are preparing the project for public release. We are polishing the documentation and the process.

FAQ | Ideal Fuzzing Integration | New Target Guide | Reproducing | All Targets | Targets issue tracker

Create New Issue for questions or feedback.

Why OSS-Fuzz?

Fuzz testing is a well-known technique for uncovering various kinds of programming errors in software. Many detectable errors (e.g. buffer overruns) have real security implications.

We successfully deployed guided in-process fuzzing of Chrome components and now want to share the experience and the service with the openssource community.

OSS-Fuzz aims to make common open source software more secure by combining modern fuzzing techniques and scalable distributed execution.

At the first stage of the project we use libFuzzer with Sanitizers. More fuzzing engines will be added later. ClusterFuzz provides distributed fuzzer execution environment and reporting.

Process Overview

The following process is used for targets in OSS-Fuzz:

Accepting New Targets

In order to be accepted to OSS-Fuzz, an open-source target must have a significant user base and/or be critical to the global IT infrastructure.

To submit a new target to OSS-Fuzz:

  • create a pull request with a change to targets/README.md providing the following information:
    • target home site and details
    • source code repository location
    • a link to target security issue reporting process OR
    • an e-mail of the engineering contact person to be CCed on issue. This has to be an e-mail linked to a Google Account that belongs to an established target committer (according to VCS logs). If this is not you or address differs from VCS, an informal e-mail verification will be required. This e-mail will also be publicly listed in our Targets page.
  • once accepted by an OSS-Fuzz project member, follow the New Target Guide to write the code.

Bug Disclosure Guidelines

Following Google's standard disclosure policy OSS-Fuzz will adhere to following disclosure principles:

  • 90-day deadline. After notifying target authors, we will open reported issues in 90 days, or 7 days after the fix is released.
  • Weekends and holidays. If a deadline is due to expire on a weekend or US public holiday, the deadline will be moved to the next normal work day.
  • Grace period. We will have a 14-day grace period. If a 90-day deadline will expire but upstream engineers let us know before the deadline that a patch is scheduled for release on a specific day within 14 days following the deadline, the public disclosure will be delayed until the availability of the patch.

More Documentation

Build status

This page gives the latest build logs for each target.

Trophies

This page gives a list of publically viewable (fixed) bugs found by OSS-Fuzz.

References