AutoCVE: an agent pipeline that takes an open source repository from scan to CVE report

The problem AutoCVE targets: turning a repository into a submittable CVE

Most vulnerability discovery work is not one task. It is a queue of tasks: pick a repository worth auditing, clone it, run static analysis, throw away the false positives, dig into the ones that survive, prove the bug is reachable, then write a report in a format a CNA will accept. AutoCVE's README frames the whole chain as the product, describing a flow from project selection and repository import through audit task creation and agent-driven discovery to CVE application report generation. The stated goal is that the user copies the report content and submits it.

That framing tells you who it is for. This is not a tool for a developer who wants a linter in CI. It is aimed at vulnerability researchers and small security teams who already do manual source auditing and want the mechanical parts compressed. The README's CVE results table lists 30 findings across 14 open source projects from a seven day test period, with a maximum CVSS of 9.9 and per-CVE links to a separate vulnerability-reports repository. Those are the project's own claims about its output, not an independent measurement, and the table is the only evidence presented for them.

How the Orchestrator, Recon, Scan, Triage, Finding and Verification agents connect

The README publishes a Mermaid flowchart of the agent topology. An Orchestrator sits at the top and schedules the others. Recon feeds both Scan and Finding. Scan feeds Triage. Triage and Finding both feed Verification, and Verification leads to a Merge and Finalize step. That is a fan-out then fan-in shape: two independent discovery paths (tool scanning and source reading) converge on one verification stage before anything is recorded.

The split matters because the two paths fail differently. Scan plus Triage is the conventional pipeline: run tools, then use an agent to filter false positives. The README's mode table calls this enhanced scanning and recommends it for quick analysis of tool output. Finding is the other path, described as designed specifically for CVE and 0Day research, and it is the one that reads source directly. Combined audit merges both.

Finding is where the design gets specific. The README names a ReAct Loop, task-specific tool calls, nudge-based correction, and a structured termination mechanism called FinalizeFinding. A ReAct loop means the agent alternates reasoning and tool invocation until it decides to stop, and the named termination mechanism is what stops it from looping indefinitely. The nudge is a correction signal injected mid-run. Whether these work well is not something the README demonstrates; it documents the mechanism, not its accuracy.

Installing AutoCVE with Docker Compose and running a first audit

The README offers a one-line deployment that does not require cloning the repository. It pipes a pinned compose file into Docker Compose. The version in the URL is v1.0.5, matching the most recent release listed for the project.

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

On Windows the README gives the equivalent with curl.exe piped into docker compose. For development or second-party modification, the source route is a clone followed by a build.

git clone https://github.com/larlarua/AutoCVE.git
cd AutoCVE
docker compose up -d --build

Once the stack is up, four services are exposed. The frontend is at http://localhost:3000, the backend API at http://localhost:8000, Swagger at http://localhost:8000/docs, and Adminer, the database UI, at http://localhost:8080. The README's quick-experience path is: configure a model, import a project, create an audit task, follow the live audit, manage vulnerabilities, then edit or export the report. The model configuration step is not optional and the README does not provide a default, so the first thing to check after the stack starts is whether the backend can reach whatever model endpoint you configure.

The compose file itself is worth reading before you run it. The db service is postgres:15-alpine with POSTGRES_USER and POSTGRES_PASSWORD both set to postgres, and port 5432 published to the host. Redis 7 runs on 6379. The backend container is capped at 1.0 CPU and 1g of memory, and it sets AGENT_ENABLED to true, AGENT_TASK_EXECUTION_MODE to worker, AGENT_WORKER_CONCURRENCY defaulting to 2, and AGENT_WORKER_JOB_TIMEOUT_SECONDS defaulting to 3600. Sandboxing is on by default via SANDBOX_ENABLED. Those defaults are the ones to override first if you are running on a shared machine.

Where AutoCVE breaks down: model dependency, sandbox trust and the 1 GB backend cap

The most consequential limitation is not in the agent design, it is in the dependency graph. AutoCVE is an LLM agent platform, and the README's own quick-start sequence begins with configuring a model. Nothing in the repository layout or the README suggests a fallback path that produces findings without one. If your organisation cannot send source code to an external model endpoint, or cannot run a local model large enough for the Finding agent's reasoning, the core capability is unavailable and what remains is the conventional Scan and Triage path, which is a wrapper around tools you could run directly.

The second limitation is the sandbox. SANDBOX_ENABLED is set to true in the compose file and SANDBOX_IMAGE defaults to autocve-sandbox:latest, which means dynamic verification runs inside a container. That is the right shape, but the compose file also publishes the database on 5432 with the password postgres and exposes Adminer on 8080. A deployment that runs untrusted code for verification and simultaneously exposes an unauthenticated-by-default database port is a configuration you should not put on a routable network without changing those values.

The third is resource sizing. The backend is capped at 1.0 CPU and 1g of memory while AGENT_WORKER_CONCURRENCY defaults to 2 and a job timeout defaults to 3600 seconds. Two concurrent agent workers inside a 1 GB container is a tight budget for a workload that reads source files and holds conversation context. The README does not state what happens when a worker is killed by the memory limit mid-audit; the compose file sets AGENT_WORKER_MAX_TRIES to 2, which suggests retries are expected, but the README does not document what state a partially completed audit is left in.

How AutoCVE differs from Semgrep and CodeQL, and when a plain scanner wins

Semgrep and CodeQL both take rules as their unit of work. You write or import a pattern, the engine matches it against the codebase, and the output is deterministic: the same rules on the same commit produce the same findings. AutoCVE's Scan and Triage path overlaps with that, and the repository does ship a sgconfig.yml at the top level, which indicates Semgrep is part of the toolchain rather than a competitor to it.

The real difference is the Finding agent. A rule engine can only report what someone wrote a rule for. An LLM reading source can surface a missing authorization check in a route handler that no rule describes, which is exactly the class of bug in the README's results table (Improper Access Control, Missing Authorization, SSRF, SQL Injection). The trade is determinism for coverage. You cannot diff two AutoCVE runs and expect the same output, you cannot pin its behaviour to a ruleset version, and the same repository audited twice may yield different findings.

So the honest split is this: if your requirement is a repeatable gate that blocks a merge, use a rule-based scanner and keep it. If your requirement is a research queue where a human triages the output anyway, the agent path adds something a ruleset cannot. AutoCVE's own mode table reflects that distinction by offering enhanced scanning as a separate, lighter mode.

Maintenance, release cadence and what AGPL-3.0 means for a self-hosted deployment

The repository is not archived. The last push was on 2026-09-03, roughly two and a half weeks before this writing, and 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. That is a weekly release rhythm through early July, then a gap in tagged releases while the main branch continued to receive commits into September. The project is young: the release numbering has not reached v1.1, and the README's results table is a seven day test, not a long-running track record.

Upgrade cost depends on which install route you chose. The one-line deployment pins the compose file to a tag, so upgrading means changing v1.0.5 in the URL to the next tag and re-running the command. The source route means a git pull and a rebuild, and because the backend image is built from ./backend with a Dockerfile, a rebuild picks up dependency changes. The compose file reads an optional ./backend/.env, and several values are overridable through environment variables (POSTGRES_DB_NAME, AGENT_WORKER_CONCURRENCY, AGENT_WORKER_JOB_TIMEOUT_SECONDS, AGENT_WORKER_MAX_TRIES, ONE_CLICK_CVE_MAX_REPOSITORY_SIZE_KB, SANDBOX_IMAGE), so a local override file is the low-friction way to survive an upgrade without editing the pinned compose file.

The licence is AGPL-3.0. For a security team running AutoCVE internally against its own or third-party source, that is unremarkable. It becomes a real question if you intend to embed AutoCVE in a product you distribute or expose as a network service, because AGPL-3.0's network clause reaches users who interact with a modified version over a network. This is a licensing question for your own counsel, not something the README settles; the repository ships a LICENSE file and a DISCLAIMER.md, and the README does not discuss commercial licensing.

Editorial conclusion

Adopt AutoCVE if you already run LLM-backed code review and want the pipeline, the sandbox and the report template in one place rather than wiring them yourself. Do not adopt it if you need a scanner that works without a configured model, or if AGPL-3.0 is incompatible with how you ship your own product. Before trusting it, verify three things: that the Finding agent produces a reproducible proof of concept on a codebase you already know, that the sandbox actually isolates execution, and that the CVE report it emits matches the format the CNA you submit to accepts.

Frequently asked questions

Official sources

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