Skip to content

VENDOR.md

Latest commit

 

History

History
49 lines (39 loc) · 3.29 KB

VENDOR.md

File metadata and controls

49 lines (39 loc) · 3.29 KB
Raw

Vendored / external dependencies

cve-reverser deliberately vendors almost nothing — the point of the standalone release is that the model self-authors the Nuclei template and a pure-Python validator checks its shape. What crosses the boundary to an external source, and why, is listed here.

Nuclei template validity — how it's judged today

There is no vendored JSON schema in this repo right now. Template validity has two independent authorities, deliberately layered:

  1. In-loop, pure-Python (cve_reverser/postprocess.py). Extract → yaml.safe_load → structural checks (id / info.name / info.severity / ≥1 protocol block carrying matchers or extractors) + a few gates (duplicate keys, canonical author, CVE relevance). Deterministic, zero-LLM, no subprocess — safe to run inside the sandboxed RLM tool. This is what sets TemplateItem.valid. It intentionally checks shape, not the full ProjectDiscovery grammar: it must be cheap, hang-proof, and dependency-free.

  2. Host-side, optional, authoritative (cve_reverser/nuclei_binary.py). If the nuclei binary is on PATH, the CLI runs nuclei -validate -t <tmp> -duc -silent after the run, host-side, and appends the verdict to the report. This is the real grammar check. It is never run in-loop: a subprocess from inside the live dspy.RLM/asyncio process reliably hangs (a hard-won lesson). Treat "nuclei binary absent" as a soft/unknown verdict, not a failure — the pipeline is fully functional without it.

So: the pure-Python check is the always-on gate; the binary is the optional oracle. Neither vendors ProjectDiscovery's schema file.

When the full schema arrives

When the harness template backend ships (config.template_backend="harness", delegating authoring to a mature downstream harness via a future rlm-kit make_harness_tool), the authoritative grammar — the vendored ProjectDiscovery schema, the richer validators, the matcher/extractor knowledge — lives in that harness, not here. cve-reverser stays thin on purpose: it owns the reversing (patch → source→sink → PoC → spec) and the trajectory, and it hands the authoring to whichever backend is configured. That is why this repo does not — and should not — grow a vendored schema before that seam is wired.

External services (all opt-in, none bundled)

  • Patchstack database + wordpress.org SVN (feed.py, fetch_tool.py): public read-only sources. The Patchstack page is parsed host-side from its server-rendered Nuxt payload (no API key); plugin source is fetched from SVN through the SSRF-guarded fetch tool. Their content is untrusted LM context (a prompt-injection surface), never trusted instructions. tests/fixtures/patchstack_payload.json is a captured real Patchstack payload — a test fixture that keeps the parser honest against the actual shape (not a runtime dependency); refresh it from a live capture if Patchstack changes its serialization.
  • GitHub REST API (publish.py, CR_GITHUB_REPO / CR_GITHUB_TOKEN / CR_GITHUB_BRANCH): opt-in publishing pushes a generated template straight to the GitHub REST API over httpx — no Zapier, no MCP, no bundled server.
  • The model endpoints (planner / lifeline / generator): the user's own, by env. No default vendor.