Link Search Menu Expand Document

Architecture

OSS-Fuzz architecture diagram

The process works like this:

  1. A maintainer of an open source project (or an outside volunteer) creates one or more fuzz targets and integrates them with the project’s build and test system.
  2. The project is accepted to OSS-Fuzz and the developer commits their build configurations.
  3. The OSS-Fuzz builder builds the project from the committed configs.
  4. The builder uploads the fuzz targets to the OSS-Fuzz GCS bucket.
  5. ClusterFuzz downloads the fuzz targets and begins to fuzz the projects.
  6. When Clusterfuzz finds a bug, it reports the issue automatically to the OSS-Fuzz issue tracker (example). (Why use a different tracker?)
  7. Project owners are CCed on the bug report.
  8. The project developer fixes the bug upstream and credits OSS-Fuzz for the discovery (the commit message should contain the string ‘Credit to OSS-Fuzz’).

Once the developer fixes the bug, ClusterFuzz automatically verifies the fix, adds a comment, and closes the issue (example). 30 days after the fix is verified or 90 days after reporting (whichever is earlier), the issue becomes public.