commit	534718a78af394bfcd50e45c1ab22da7c830a3b8	[log] [tgz]
author	Kostya Serebryany <konstantin.s.serebryany@gmail.com>	Wed Nov 30 10:39:22 2016 -0800
committer	GitHub <noreply@github.com>	Wed Nov 30 10:39:22 2016 -0800
tree	0a665d3987822ede22e744f7a2ad8f349316eb17
parent	86ca1ed3375543483a7f8f565ffaff1b4f36561d [diff]

tree: 0a665d3987822ede22e744f7a2ad8f349316eb17

README.md

OSS-Fuzz - Continuous Fuzzing for Open Source Software

Status: Beta. We are preparing the project for public release soon.

Create New Issue for questions or feedback about OSS-Fuzz.

Introduction

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

We successfully deployed guided in-process fuzzing of Chrome components and found hundreds of security vulnerabilities and stability bugs. We now want to share the experience and the service with the open source community.

In cooperation with the Core Infrastructure Initiative, OSS-Fuzz aims to make common open source software more secure and stable 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 projects in OSS-Fuzz:

A maintainer of an opensource project or an outside volunteer creates one or more fuzz targets and integrates them with the project's build and test system.
These fuzz targets are accepted to OSS-Fuzz.
When ClusterFuzz finds a bug, an issue is automatically reported in the OSS-Fuzz issue tracker (example). (Why different tracker?). Project owners are CC-ed to the bug report.
The bug is fixed upstream.
ClusterFuzz automatically verifies the fix, adds a comment and closes the issue (example).
7 days after the fix is verified or 90 days after reporting, the issue becomes public (guidelines).

Accepting New Projects

To be accepted to OSS-Fuzz, an open-source project must have a significant user base and/or be critical to the global IT infrastructure. To submit a new project:

Create a pull request with new projects/<project_name>/project.yaml file (example) giving at least the following information:
- project homepage.
- e-mail of the engineering contact person to be CCed on new issues. This email should be
  linked to a Google Account
  and belong to an established project committer (according to VCS logs). If this is not you or the email address differs from VCS, an informal e-mail verification will be required.
Once accepted by an OSS-Fuzz project member, follow the New Project 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 project 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 have a 14-day grace period. If a 90-day deadline expires but the upstream engineers lets 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.

OSS-Fuzz - Continuous Fuzzing for Open Source Software

Introduction

Process Overview

Accepting New Projects

Bug Disclosure Guidelines

More Documentation

Build Status

Trophies

References