Skip to content
cccskills
FreePublished on GitHub

ossfuzz

Set up OSS-Fuzz for an open-source project and test it locally. Prepare configuration and build files, run fuzz tests that probe code with varied inputs, reproduce reported crashes, and inspect which code the tests reach.

OriginalShow the original description

Enrolls a project in OSS-Fuzz, Google's free continuous fuzzing service for open source, and drives it locally. Covers project.yaml, Dockerfile and build.sh setup, the helper scripts, reproducing OSS-Fuzz crash reports, and the acceptance criteria. Use when setting up continuous fuzzing for an open-source project, reproducing an OSS-Fuzz bug report, or testing an OSS-Fuzz build before submitting it.

Works withDocker
See how to install

Good for

  • Preparing an open-source project for OSS-Fuzz enrollment
  • Testing an OSS-Fuzz build locally before submission
  • Reproducing crashes from OSS-Fuzz reports
  • Inspecting test coverage

Files included (3)

  • SKILL.md16.3 KB
  • agents/openai.yaml233 B
  • assets/trail-of-bits-mark.svg3.0 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

OSS-Fuzz

OSS-Fuzz is an open-source project developed by Google that provides free distributed infrastructure for continuous fuzz testing. It streamlines the fuzzing process and facilitates simpler modifications. While only select projects are accepted into OSS-Fuzz, the project's core is open-source, allowing anyone to host their own instance for private projects.

Overview

OSS-Fuzz provides a simple CLI framework for building and starting harnesses or calculating their coverage. Additionally, OSS-Fuzz can be used as a service that hosts static web pages generated from fuzzing outputs such as coverage information.

Key Concepts

ConceptDescription
helper.pyCLI script for building images, building fuzzers, and running harnesses locally
Base ImagesHierarchical Docker images providing build dependencies and compilers
project.yamlConfiguration file defining project metadata for OSS-Fuzz enrollment
DockerfileProject-specific image with build dependencies
build.shScript that builds fuzzing harnesses for your project
Criticality ScoreMetric used by OSS-Fuzz team to evaluate project acceptance

When to Apply

Apply this technique when:

  • Setting up continuous fuzzing for an open-source project
  • Need distributed fuzzing infrastructure without managing servers
  • Want coverage reports and bug tracking integrated with fuzzing
  • Testing existing OSS-Fuzz harnesses locally
  • Reproducing crashes from OSS-Fuzz bug reports

Skip this technique when:

  • Project is closed-source (unless hosting your own OSS-Fuzz instance)
  • Project doesn't meet OSS-Fuzz's criticality score threshold
  • Need proprietary or specialized fuzzing infrastructure
  • Fuzzing simple scripts that don't warrant infrastructure

Quick Reference

TaskCommand
Clone OSS-Fuzzgit clone https://github.com/google/oss-fuzz
Build project imageuv run --no-project python infra/helper.py build_image --pull <project>
Build fuzzers with ASanuv run --no-project python infra/helper.py build_fuzzers --sanitizer=address <project>
Run specific harnessuv run --no-project python infra/helper.py run_fuzzer <project> <harness>
Generate coverage reportuv run --no-project python infra/helper.py coverage <project>
Check helper.py optionsuv run --no-project python infra/helper.py --help

OSS-Fuzz Project Components

OSS-Fuzz provides several publicly available tools and web interfaces:

Bug Tracker

The bug tracker allows you to:

  • Check bugs from specific projects (initially visible only to maintainers, later made public)
  • Create new issues and comment on existing ones
  • Search for similar bugs across all projects to understand issues

Build Status System

The build status system helps track:

  • Build statuses of all included projects
  • Date of last successful build
  • Build failures and their duration

Fuzz Introspector

Fuzz Introspector displays:

  • Coverage data for projects enrolled in OSS-Fuzz
  • Hit frequency for covered code
  • Performance analysis and blocker identification

Read this case study for examples and explanations.

Step-by-Step: Running a Single Harness

You don't need to host the whole OSS-Fuzz platform to use it. The helper script makes it easy to run individual harnesses locally.

Step 1: Clone OSS-Fuzz

git clone https://github.com/google/oss-fuzz
cd oss-fuzz
uv run --no-project python infra/helper.py --help

Step 2: Build Project Image

uv run --no-project python infra/helper.py build_image --pull <project-name>

This downloads and builds the base Docker image for the project.

Step 3: Build Fuzzers with Sanitizers

uv run --no-project python infra/helper.py build_fuzzers --sanitizer=address <project-name>

Sanitizer options:

Note: Fuzzers are built to /build/out/<project-name>/ containing the harness executables, dictionaries, corpus, and crash files.

Step 4: Run the Fuzzer

uv run --no-project python infra/helper.py run_fuzzer <project-name> <harness-name> [<fuzzer-args>]

The helper script automatically runs any missed steps if you skip them.

Step 5: Coverage Analysis (Optional)

First, install gsutil (skip gcloud initialization).

uv run --no-project python infra/helper.py build_fuzzers --sanitizer=coverage <project-name>
uv run --no-project python infra/helper.py coverage <project-name>

Use --no-corpus-download to use only local corpus. The command generates and hosts a coverage report locally.

See official OSS-Fuzz documentation for details.

Common Patterns

Pattern: Running irssi Example

Use Case: Testing OSS-Fuzz setup with a simple enrolled project

# Clone and navigate to OSS-Fuzz
git clone https://github.com/google/oss-fuzz
cd oss-fuzz

# Build and run irssi fuzzer
uv run --no-project python infra/helper.py build_image --pull irssi
uv run --no-project python infra/helper.py build_fuzzers --sanitizer=address irssi
uv run --no-project python infra/helper.py run_fuzzer irssi irssi-fuzz

Expected Output:

INFO:__main__:Running: docker run --rm --privileged --shm-size=2g --platform linux/amd64 -i -e FUZZING_ENGINE=libfuzzer -e SANITIZER=address -e RUN_FUZZER_MODE=interactive -e HELPER=True -v /private/tmp/oss-fuzz/build/out/irssi:/out -t gcr.io/oss-fuzz-base/base-runner run_fuzzer irssi-fuzz.
Using seed corpus: irssi-fuzz_seed_corpus.zip
/out/irssi-fuzz -rss_limit_mb=2560 -timeout=25 /tmp/irssi-fuzz_corpus -max_len=2048 < /dev/null
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 1531341664
INFO: Loaded 1 modules   (95687 inline 8-bit counters): 95687 [0x1096c80, 0x10ae247),
INFO: Loaded 1 PC tables (95687 PCs): 95687 [0x10ae248,0x1223eb8),
INFO:      719 files found in /tmp/irssi-fuzz_corpus
INFO: seed corpus: files: 719 min: 1b max: 170106b total: 367969b rss: 48Mb
#720        INITED cov: 409 ft: 1738 corp: 640/163Kb exec/s: 0 rss: 62Mb
#762        REDUCE cov: 409 ft: 1738 corp: 640/163Kb lim: 2048 exec/s: 0 rss: 63Mb L: 236/2048 MS: 2 ShuffleBytes-EraseBytes-

Pattern: Enrolling a New Project

Use Case: Adding your project to OSS-Fuzz (or private instance)

Create three files in projects/<your-project>/:

1. project.yaml - Project metadata:

homepage: "https://github.com/yourorg/yourproject"
language: c++
primary_contact: "your-email@example.com"
main_repo: "https://github.com/yourorg/yourproject"
fuzzing_engines:
  - libfuzzer
sanitizers:
  - address
  - undefined

2. Dockerfile - Build dependencies:

FROM gcr.io/oss-fuzz-base/base-builder
RUN apt-get update && apt-get install -y \
    autoconf \
    automake \
    libtool \
    pkg-config
RUN git clone --depth 1 https://github.com/yourorg/yourproject
WORKDIR yourproject
COPY build.sh $SRC/

3. build.sh - Build harnesses:

#!/bin/bash -eu
./autogen.sh
./configure --disable-shared
make -j$(nproc)

# Build harnesses
$CXX $CXXFLAGS -std=c++11 -I. \
    $SRC/yourproject/fuzz/harness.cc -o $OUT/harness \
    $LIB_FUZZING_ENGINE ./libyourproject.a

# Copy corpus and dictionary if available
cp $SRC/yourproject/fuzz/corpus.zip $OUT/harness_seed_corpus.zip
cp $SRC/yourproject/fuzz/dictionary.dict $OUT/harness.dict

Docker Images in OSS-Fuzz

Harnesses are built and executed in Docker containers. All projects share a runner image, but each project has its own build image.

Image Hierarchy

Images build on each other in this sequence:

  1. base_image - Specific Ubuntu version
  2. base_clang - Clang compiler; based on base_image
  3. base_builder - Build dependencies; based on base_clang
  4. Your project Docker image - Project-specific dependencies; based on base_builder or language variant

Runner Images (Used Separately)

Advanced Usage

Tips and Tricks

TipWhy It Helps
Don't manually copy source codeProject Dockerfile likely already pulls latest version
Check existing projectsBrowse oss-fuzz/projects for examples
Keep harnesses in separate repoLike curl-fuzzer - cleaner organization
Use specific compiler versionsBase images provide consistent build environment
Install dependencies in DockerfileMay require approval for OSS-Fuzz enrollment

Criticality Score

OSS-Fuzz uses a criticality score to evaluate project acceptance. See this example for how scoring works.

Projects with lower scores may still be added to private OSS-Fuzz instances.

Hosting Your Own Instance

Since OSS-Fuzz is open-source, you can host your own instance for:

  • Private projects not eligible for public OSS-Fuzz
  • Projects with lower criticality scores
  • Custom fuzzing infrastructure needs

Anti-Patterns

Anti-PatternProblemCorrect Approach
Manually pulling source in build.shDoesn't use latest versionLet Dockerfile handle git clone
Copying code to OSS-Fuzz repoHard to maintain, violates separationReference external harness repo
Ignoring base image versionsBuild inconsistenciesUse provided base images and compilers
Skipping local testingWastes CI resourcesUse helper.py locally before PR
Not checking build statusUnnoticed build failuresMonitor build status page regularly

Tool-Specific Guidance

libFuzzer

OSS-Fuzz primarily uses libFuzzer as the fuzzing engine for C/C++ projects.

Harness signature:

extern "C" int LLVMFuzzerTestOneInput(const uint8_t *data, size_t size) {
    // Your fuzzing logic
    return 0;
}

Build in build.sh:

$CXX $CXXFLAGS -std=c++11 -I. \
    harness.cc -o $OUT/harness \
    $LIB_FUZZING_ENGINE ./libproject.a

Integration tips:

  • Use $LIB_FUZZING_ENGINE variable provided by OSS-Fuzz
  • Include -fsanitize=fuzzer is handled automatically
  • Link against static libraries when possible

AFL++

OSS-Fuzz supports AFL++ as an alternative fuzzing engine.

Enable in project.yaml:

fuzzing_engines:
  - afl
  - libfuzzer

Integration tips:

  • AFL++ harnesses work alongside libFuzzer harnesses
  • Use persistent mode for better performance
  • OSS-Fuzz handles engine-specific compilation flags

Atheris (Python)

For Python projects with C extensions.

Example from cbor2 integration:

Harness:

import atheris
import sys
import cbor2

@atheris.instrument_func
def TestOneInput(data):
    fdp = atheris.FuzzedDataProvider(data)
    try:
        cbor2.loads(data)
    except (cbor2.CBORDecodeError, ValueError):
        pass

def main():
    atheris.Setup(sys.argv, TestOneInput)
    atheris.Fuzz()

if __name__ == "__main__":
    main()

Build in build.sh:

# allow-legacy-python: build.sh runs inside the oss-fuzz container, where the shims are absent.
pip3 install .
for fuzzer in $(find $SRC -name 'fuzz_*.py'); do
  compile_python_fuzzer $fuzzer
done

Integration tips:

Rust Projects

Enable in project.yaml:

language: rust
fuzzing_engines:
  - libfuzzer
sanitizers:
  - address  # Only AddressSanitizer supported for Rust

Build in build.sh:

cargo fuzz build -O --debug-assertions
cp fuzz/target/x86_64-unknown-linux-gnu/release/fuzz_target_1 $OUT/

Integration tips:

Troubleshooting

IssueCauseSolution
Build fails with missing dependenciesDependencies not in DockerfileAdd apt-get install or equivalent in Dockerfile
Harness crashes immediatelyMissing input validationAdd size checks in harness
Coverage is 0%Harness not reaching target codeVerify harness actually calls target functions
Build timeoutComplex build processOptimize build.sh, consider parallel builds
Sanitizer errors in buildIncompatible flagsUse flags provided by OSS-Fuzz environment variables
Cannot find source codeWrong working directory in DockerfileSet WORKDIR or use absolute paths

Related Skills

Tools That Use This Technique

SkillHow It Applies
libfuzzerPrimary fuzzing engine used by OSS-Fuzz
aflppAlternative fuzzing engine supported by OSS-Fuzz
atherisUsed for fuzzing Python projects in OSS-Fuzz
cargo-fuzzUsed for Rust projects in OSS-Fuzz

Related Techniques

SkillRelationship
coverage-analysisOSS-Fuzz generates coverage reports via helper.py
address-sanitizerDefault sanitizer for OSS-Fuzz projects
fuzz-harness-writingEssential for enrolling projects in OSS-Fuzz
corpus-managementOSS-Fuzz maintains corpus for enrolled projects

Resources

Key External Resources

OSS-Fuzz Official Documentation Comprehensive documentation covering enrollment, harness writing, and troubleshooting for the OSS-Fuzz platform.

Getting Started Guide Step-by-step process for enrolling new projects into OSS-Fuzz, including requirements and approval process.

cbor2 OSS-Fuzz Integration PR Real-world example of enrolling a Python project with C extensions into OSS-Fuzz. Shows:

  • Initial proposal and project introduction
  • Criticality score evaluation
  • Complete implementation (project.yaml, Dockerfile, build.sh, harnesses)

Fuzz Introspector Case Studies Examples and explanations of using Fuzz Introspector to analyze coverage and identify fuzzing blockers.

Video Resources

Check OSS-Fuzz documentation for workshop recordings and tutorials on enrollment and harness development.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Build and test code with AddressSanitizer, a tool that detects invalid memory access during execution. Configure checks for C/C++ and unsafe Rust, investigate crash reports, and adjust settings for fuzzing, or testing with generated inputs.

  • Detect memory errors while fuzzing C/C++
  • Test unsafe Rust and calls to external libraries
  • Interpret an ASan crash report
trailofbits/skills7.6KUpdated Oct 16, 2026

aflpp

FreeSummary

Sets up AFL++ to test C/C++ programs with varied generated inputs, a technique called fuzzing. Covers running tests across CPU cores, monitoring progress, reducing input collections, and reproducing crashes for investigation.

  • Running C/C++ fuzzing across multiple CPU cores
  • Exploring further after libFuzzer progress stalls
  • Monitoring fuzzing progress and stability
trailofbits/skills7.6KUpdated Oct 16, 2026

Audits GitHub Actions workflows that run AI coding agents. Traces how attacker-controlled content reaches prompts, checks permissions and sandbox settings, and reports evidence, severity, and fixes for prompt injection and related configuration risks.

  • Reviewing workflows that run AI coding agents
  • Tracing issue and PR content into agent prompts
  • Checking sandbox settings and user allowlists
trailofbits/skills7.6KUpdated Oct 16, 2026

Reviews Algorand smart contracts written in TEAL or PyTeal for 11 vulnerability patterns. Produces a complete coverage table and findings with code references, severity ratings, and suggested fixes, with optional automated checks using Tealer.

  • Security checks before an Algorand contract audit
  • Reviewing TEAL or PyTeal transaction validation
  • Verifying fixes for reported vulnerabilities
trailofbits/skills7.6KUpdated Oct 16, 2026

atheris

FreeSummary

Set up Atheris to test Python code and C extensions with automatically varied inputs. It guides test harness creation, coverage tracking to explore more code, and AddressSanitizer setup for finding memory errors.

  • Fuzzing a Python package or parser
  • Investigating memory corruption in Python C extensions
  • Turning raw bytes into typed test arguments
trailofbits/skills7.6KUpdated Oct 16, 2026

Connect static analysis results and human audit notes to a Trailmark code graph. Group findings by severity and compare them with input flow, impact, and privilege boundaries to prioritize investigation and understand findings in their code context.

  • Connecting Semgrep or CodeQL results to code structure
  • Combining human audit notes with automated findings
  • Prioritizing findings using input flow and impact
trailofbits/skills7.6KUpdated Oct 16, 2026

See all skills by trailofbits

Report a problem with this skill