proposal: support sequential dependencies in CRS ensemble

[0xdkay]

Context

OSS-CRS currently supports parallel ensemble — multiple CRSes run simultaneously and exchange artifacts (POVs, patches, bug-candidates, seeds) via the exchange sidecar. This works well when CRSes are independent.

However, some workflows require sequential ordering — one CRS must complete before another starts, because the downstream CRS depends on the upstream CRS's output.

Use Cases

• Reviewer → Bug-finding: Security review CRS produces bug-candidate reports, bug-finding CRS uses them to guide POV generation
• Bug-finding → Bug-fixing: Bug-finding CRS produces POVs, bug-fixing CRS uses them to generate patches
• Bug-finding → SARIF generation: Bug-finding CRS produces POVs, SARIF generation CRS converts findings into standardized reports
• Harness generation → Bug-finding: Harness gen CRS produces fuzz harnesses, bug-finding CRS uses them
• Mixed: Review runs first, then multiple finders run in parallel consuming the review output, then a fixer consumes all POVs

Concrete Example: Multi-Reviewer → Bug-Finding

We have 3 reviewer CRSes that use each AI tool's native security review feature:

• crs-reviewer-claude-code — Claude's /security-review
• crs-reviewer-codex — Codex's exec review
• crs-reviewer-gemini-cli — Gemini's /security:analyze

Each produces bug-candidate files (structured vulnerability reports). These should feed into a bug-finding CRS that uses the combined review findings to guide POV generation:

Stage 1 (parallel):
  crs-reviewer-claude-code  → bug-candidates/
  crs-reviewer-codex        → bug-candidates/
  crs-reviewer-gemini-cli   → bug-candidates/

Stage 2 (after all reviewers complete):
  crs-bug-finding-claude-code  ← reads all bug-candidates from Stage 1

Today this requires an external script to orchestrate the two stages and manually pass --bug-candidate-dir between runs. Native support would allow expressing this in a single compose file.

Current Workaround

Sequential stages can be orchestrated with an external script:

# Stage 1: Run reviewers in parallel
uv run oss-crs run --compose-file reviewers.yaml ...

# Collect review output
REVIEW_DIR=$(uv run oss-crs artifacts --compose-file reviewers.yaml | jq -r '.bug_candidates_dir')

# Stage 2: Run bug-finding with review results
uv run oss-crs run --compose-file finder.yaml ... --bug-candidate-dir "$REVIEW_DIR"

This works but loses the single-compose-file simplicity and requires manual artifact plumbing.

Open Questions

1. What's the right pipeline abstraction? Options include:

   • depends_on between CRS entries in compose
   • A pipeline section in compose with explicit stages
   • Keeping the external script approach and providing a helper CLI command

2. What defines a CRS? Currently a CRS is expected to produce POVs (bug-finding) or patches (bug-fixing). Should a CRS that only produces bug-candidate reports (e.g., a reviewer) or seeds (e.g., a seed generator) also be considered a CRS? If so, the type field in crs.yaml may need new values beyond bug-finding and bug-fixing — for example reviewer, seed-generator, sarif-generator. This affects how the framework validates CRS outputs and how compose handles different CRS roles in a pipeline.

No strong opinions yet — raising this to capture the use cases as we build reviewer CRSes that would benefit from native support.

[azchin]

We need to consider the lifetime expectation from each CRS. Bug-finding CRSs (when they are fuzzer based) are long running processes, and patching CRSs are single-use given some set of PoVs. Combining them together raises a few suggestions:

• Streaming PoVs to the patcher (requires patcher to be either long-running or handle accumulated PoVs over time)
• Stopping the bug-finding after some heuristic (PoVs found, timeout) and then running patcher
• Support more complex logic via a triager and orchestrator which decides when to launch patch CRS

To add to the use case: bug-finding --> triager which filters and groups PoVs.
Plenty of AFC CRSs have triaging logic, and we can keep them modularized away from the bug-finding part.

[0xdkay]

We need to think of a CRS from AIxCC vs what we define CRS here. Ours seem more like "modules" to build a complete CRS? Feels like building blocks towards an advanced CRS.