Skip to main content

CRS Registry

The CRS Registry is a curated catalog of certified open-source Cyber Reasoning Systems that are compatible with the OSS-CRS framework. Each registered CRS has been verified to follow the CRS Development Guide and can be used out of the box with oss-crs.

Registry Structure

Each CRS in the registry is defined by a YAML file at registry/<crs-name>.yaml. The manifest describes the CRS metadata and where to fetch its source:

name: <crs-name>
type:
- bug-finding # bug-fixing, bug-finding-triage, seed-filter, etc.
source:
url: <git-repository-url>
ref: <branch-or-tag>
FieldDescription
nameUnique identifier for the CRS
typeList of CRS capabilities — bug-finding, bug-fixing, bug-finding-triage, seed-filter, bug-fixing-ensemble, or a combination
source.urlGit repository URL containing the CRS implementation
source.refGit branch or tag to use

Registry as Source of Truth

When a CRS entry in a compose file omits source, oss-crs automatically resolves it from the registry. This means registered CRSs can be used with minimal configuration:

crs-libfuzzer:
cpuset: "2-7"
memory: "16G"

The source field in compose is only needed to override the registry (e.g., for local development with local_path).

Available CRSs

Currently Registered

CRSTypeDescription
crs-libfuzzerbug-findingA lightweight CRS that runs libFuzzer on the target. Good starting point and baseline for evaluation.
atlantis-multilang-wo-concolicbug-findingA multi-language LLM-powered CRS that generates and refines fuzz harnesses without concolic execution.
crs-claude-codebug-fixingAn LLM-powered CRS that uses Claude Code to generate patches for vulnerabilities. Language-agnostic via a builder sidecar.
crs-codexbug-fixingAn LLM-powered CRS that uses Codex CLI to analyze crashes, edit code, and validate patches through a builder sidecar.
crs-copilot-clibug-fixingAn LLM-powered CRS that uses GitHub Copilot CLI to generate and validate patches through a builder sidecar.
crs-gemini-clibug-fixingAn LLM-powered CRS that uses Gemini CLI to generate and validate patches through a builder sidecar.
crs-multi-retrievalbug-fixingA two-step CRS that first analyzes crashes to gather code context, then iteratively generates and refines patches using multiple retrieval mechanisms.
crs-prismbug-fixingA cyclic CRS that rotates between analysis, patching, and evaluation agents to progressively converge on a validated fix.
crs-vincentbug-fixingA three-stage CRS that combines root-cause analysis, project-specific property analysis, and patch generation to target semantic correctness.
crs-atlantis-triagebug-finding-triageA triage CRS that validates and deduplicates bug-finding results from other CRS.
crs-clusterfuzz-triagebug-finding-triageA ClusterFuzz-based triage CRS that validates bug-finding results.
crs-roboduck-triagebug-finding-triageAn LLM-powered triage CRS that validates and classifies bug-finding results.
crs-atlantis-ensembleseed-filterA seed-filter CRS that prioritizes and filters seeds/inputs for downstream CRS.

Planned

The following CRSs are planned for inclusion in the registry:

CRSStatus
42-patch-agentPlanned
atlantis-c-bullseyePlanned
atlantis-c-deepgenPlanned
atlantis-c-libaflPlanned
crs-claude-codeRegistered
crs-codexRegistered
crs-copilot-cliRegistered
crs-gemini-cliRegistered
crs-multi-retrievalRegistered
crs-prismRegistered
crs-vincentRegistered
atlantis-java-atljazzerPlanned
atlantis-java-mainPlanned
buttercup-patcherPlanned
swe-agentPlanned

Using a Registered CRS

To use a CRS from the registry, reference it in your compose file and run:

# Prepare the CRS
uv run oss-crs prepare --compose-file <compose-file>

# Build the target
uv run oss-crs build-target --compose-file <compose-file> --fuzz-proj-path <fuzz-proj-path>

# Run the CRS
uv run oss-crs run --compose-file <compose-file> --fuzz-proj-path <fuzz-proj-path> --target-harness <harness>

See the Quick Start for a complete walkthrough.

Adding a CRS to the Registry

To register a new CRS:

  1. Ensure your CRS follows the CRS Development Guide.
  2. Create registry/<crs-name>.yaml with the required fields.
  3. Submit a pull request for review.

See CONTRIBUTING.md for contribution guidelines.