AutoCVE: an agent pipeline that turns source repositories into CVE submission reports

The gap AutoCVE targets: audit work that ends before the report exists

Source code auditing produces two kinds of output. The first is a list of candidate weaknesses, which most static analysers and grep-driven manual review can generate. The second is a verified finding with a reproduction path and a written report that a CNA will accept. The distance between those two is where most audit time disappears, and it is the distance AutoCVE is built to close. The README frames the product as covering project selection, repository import, audit task creation, agent-driven discovery and CVE report generation, with the user left to copy the report and submit it. The intended user is therefore a vulnerability researcher or a small security team that wants throughput on the submission side, not a developer who wants a linter in a pull request. The repository ships a separate reports project (larlarua/vulnerability-reports) holding the disclosed findings, which tells you the authors treat the report as the deliverable rather than the alert.

Orchestrator, five agents, and where the ReAct loop sits

The architecture is a directed graph. An Orchestrator schedules Recon, Scan, Triage, Finding and Verification agents, and the README's mermaid diagram shows Recon feeding both Scan and Finding, Scan feeding Triage, and Triage and Finding both feeding Verification, which then goes to a Merge/Finalize stage. Recon is information gathering, Scan wraps tool-based scanning, Triage filters false positives out of scan output, Finding does the deep source analysis, and Verification attempts dynamic confirmation. The Finding agent is described as the core capability: it reads source directly and runs a ReAct loop with tool calls, a Nudge mechanism for course correction, and a structured termination tool named FinalizeFinding. That last detail matters more than it looks. An agent that decides when to stop by writing free text is hard to bound; one that terminates by calling a named tool with a defined payload gives the orchestrator a parseable handoff into the Merge stage. The three audit modes are not three separate products but three subsets of the same graph: enhanced scanning runs Scan then Triage, intelligent audit runs Finding alone, and comprehensive audit runs Scan, Triage and Finding together. Choosing a mode is really choosing how much of the graph you pay for in model calls.

Three audit modes and what each one costs you in coverage

Enhanced scanning is the cheap path. It takes existing tool output and asks Triage to remove false positives, which means its ceiling is whatever the underlying scanner already found. If the scanner missed a logic flaw, no amount of triage will surface it. Intelligent audit drops the scanner entirely and points Finding at the source, which is the mode aimed at CVE and 0day work per the README's table. That is also the most expensive mode per repository, because every file the agent chooses to read is a model call, and the ReAct loop can run long. Comprehensive audit combines both, and the README describes it as full-coverage auditing. The trade-off is stated plainly enough in the table: scanning is fast, Finding is deep, and running both costs the sum. There is no documented mode that runs Verification without a prior Finding or Triage stage, so dynamic confirmation is always downstream of discovery. If your target is a binary or a service you cannot point at a source tree, none of these three modes applies.

Deployment is Docker-first, and the one-liner pins a release tag

The README gives two install paths. The one-line path pipes a compose file from a versioned URL into docker compose:

curl -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | docker compose -f - up -d

The tag v1.0.5 is embedded in that URL, so the command is reproducible in the sense that it fetches a fixed file, not a moving branch. The source path is a plain clone followed by docker compose up -d --build, which the README recommends for local development, debugging or secondary development. Four services come up: the React frontend on port 3000, the FastAPI backend on 8000, Swagger at 8000/docs, and Adminer on 8080 for database access. PostgreSQL 15 is the database, and the badges confirm Python 3.11 or newer, FastAPI 0.100 or newer and React 18. The README's quick-start tip lists the intended sequence: configure a model, import a project, create an audit task, follow the live audit, manage findings, then edit or export the report. What the truncated README does not show is the model configuration keys themselves, so the exact environment variables or settings fields for pointing AutoCVE at an LLM endpoint are not something I can state from this material. Expect to read docs/USER_GUIDE.md before the first run.

The finding pipeline assumes a model endpoint you control and a database you expose

Two constraints fall out of the architecture. First, the whole product is a wrapper around an LLM, and the README does not describe a bundled model. Every audit task therefore depends on an external inference endpoint being reachable from inside the container, and on that endpoint being able to read source files that may be under NDA or under a licence that restricts third-party processing. Sending proprietary source to a hosted model is a policy decision the tool does not make for you. Second, Adminer is published on port 8080 by default. Adminer is a full database client in a web page; leaving it reachable on a host with a weak database password is a straightforward way to lose the findings database. The README presents 8080 as a convenience, and it is, in a local compose stack. It is not something to expose. A third limitation is structural: Verification is described as dynamic validation, but the README does not state what sandbox, if any, the target runs in. Running a candidate exploit against a live service to confirm a finding is the step with the highest blast radius, and the material here does not say how that is contained.

Where AutoCVE sits against Semgrep and CodeQL

The obvious comparison is with rule-based analysers. Semgrep matches patterns written by humans against parsed source; CodeQL compiles a queryable database of code and lets you write declarative queries over data flow. Both are deterministic. Run the same rules on the same commit and you get the same alerts, which is why both fit comfortably in CI. AutoCVE inverts that. Its Scan stage may wrap tools of that kind, but the Finding stage is a language model deciding what to read next, so two runs over the same repository can diverge, and the cost per run scales with how much the agent chooses to explore. What you get in exchange is the part rule engines do not attempt: triage of its own output, a verification step, and a written report formatted for submission. A team already running CodeQL for regression detection would use AutoCVE on a different schedule and a different target set, not as a replacement. The comparison also clarifies the licence question, since Semgrep's community rules and CodeQL's CLI have their own terms that differ from AGPL-3.0.

AGPL-3.0, release cadence, and the maintenance bill

AutoCVE is licensed AGPL-3.0, which is the network-copyleft licence. In practical terms for an adopter: if you modify AutoCVE and let users interact with it over a network, the licence's source-availability obligation extends to your modified version. Running an unmodified copy internally is a different situation from shipping a modified AutoCVE as part of a hosted service. This is a description of the licence's structure, not legal advice; if the deployment touches customer data or a commercial offering, get the terms reviewed. On maintenance, the release history shows v1.0.3 on 2026-06-27, v1.0.4 on 2026-07-04 and v1.0.5 on 2026-07-12, roughly weekly patches in that window, with the last push to main on 2026-09-03. That is an active project, and it also means the surface you pin will move. The compose one-liner pins v1.0.5, so an upgrade is a change to that URL plus a compose pull and restart, but the README does not document a database migration step, and PostgreSQL 15 is named as the database. Before upgrading across minor versions, check the release notes for schema changes, because a findings database that fails to migrate is the expensive failure mode here. There is no homepage listed for the project, so the repository and the docs directory are the only documentation surface.

What the 30-CVE claim does and does not tell you

The README reports 30 CVEs across 14 projects with a maximum CVSS of 9.9, collected during a seven-day test period, and links each entry to a CVE record and a detail page in larlarua/vulnerability-reports. The listed findings are concentrated in a few projects, with five Chartbrew access-control entries and two Lemmy SSRF entries visible in the truncated table, and the vulnerability types shown are authorization and access-control classes plus SQL injection. Treat that as evidence the pipeline can produce submissions that a CNA accepts, which is a real bar, and not as a detection rate. A seven-day window on a self-selected project set says nothing about recall on your codebase, and the concentration within two projects suggests the tool is most productive where a class of authorization bug repeats across endpoints. The honest way to read the badge row is as a track record of the report format working, not as a benchmark. The detail pages in the reports repository are the thing worth reading before you trust the output, because they show the depth of evidence the Finding and Verification stages actually produced.

Editorial conclusion

Adopt AutoCVE if you already run source audits and want the triage and report-writing stages automated for CVE submission; skip it if you need a CI-friendly scanner or cannot accept AGPL-3.0 terms on a networked service. Verify first that your model endpoint is reachable from the container, that PostgreSQL 15 and the Adminer port 8080 are acceptable in your network, and that the Finding agent's output on one of your own repositories holds up before you trust it on a target you intend to submit.

Official sources

1. Issues
2. larlarua/AutoCVE on GitHub
3. License: AGPL-3.0
4. README
5. Releases