AutoCVE Security Audit Platform
Automates the path from project selection and source review to vulnerability verification and CVE-ready reporting.
Per-dimension scores and reasoning
Evidence: README mentions permission protection (architecture doc), but no implementation details; user interaction exists (interactive audit), but confirmation mechanism not explicit; data flow transparency limited, only tool call tracking mentioned; sensitive data handling not detailed; dependency security not mentioned; external effects (scan targets) have safety warnings, but sandbox details absent; rollback not mentioned; source attribution acknowledges DeepAudit, but full dependency sources not provided. Deductions: most criteria only surface-level mentions without concrete implementation evidence.
Evidence: README and test files describe a consistent Multi-Agent flow, good self-consistency; dependency availability not explicitly stated, but Docker deployment provided; failure messages not detailed. Deductions: lack of concrete evidence for dependency availability and failure messages.
Evidence: README identifies target users (security researchers) and multiple audit modes for different scenarios; capability boundaries defined via three modes; trigger precision not explicit; environment fit via Docker and source deployment. Deductions: trigger precision and some environment details insufficient.
Evidence: README provides doc links (user guide, architecture, API), clear information architecture; install notes detailed (one-line and source); naming stability not explicit; examples and FAQ have CVE results but no FAQ; known limitations not explicit; license AGPL-3.0 complete; versioning via release workflow generates changelog; maintenance responsibility has contact info. Deductions: naming stability, known limitations, and FAQ missing.
Evidence: Output is CVE report with clear format; high marginal value (automated CVE discovery); cost-benefit not detailed, but one-line deployment provided. Deductions: cost-benefit lacks concrete data.
Evidence: README claims 30 CVEs found, but no verification method; cross-source corroboration via CVE links, but not independently verified; facts and inferences not clearly separated. Deductions: lack of verifiable test results and independent verification.
- The repository claims 30 CVEs found, but no reproducible verification method is provided; treat with caution.
- Security mechanisms like permission protection and sandbox isolation are only mentioned in docs, without implementation details; actual security unknown.
- Dependency security not mentioned; there may be dependencies with known vulnerabilities.
What does this agent do, and when should you use it?
AutoCVE is a self-hosted platform for authorized security research and source-code auditing, covering project selection, repository import, audit creation, vulnerability verification, and report generation. An Orchestrator coordinates Recon, Scan, Triage, Finding, and Verification agents, then merges and finalizes the audit output. It offers Enhanced Scan, Intelligent Audit, and Comprehensive Audit modes for scan-result filtering, deeper vulnerability research, or both together. The deployment exposes a React frontend, a FastAPI backend, PostgreSQL, and Adminer. Findings can be deduplicated and stored structurally, while generated CVE application reports must still be copied and submitted by the user through the target project's disclosure process.
A user imports a project and creates an audit task. The Orchestrator then coordinates Recon, Scan, Triage, Finding, and Verification: Recon collects information, Scan invokes scanning tools, Triage filters false positives, Finding analyzes source code directly, and Verification performs dynamic validation before Merge / Finalize consolidates the result. The Finding Agent uses a ReAct Loop, specialized tool calls, Nudge correction, and the FinalizeFinding structured termination mechanism. The UI shows activity logs, the Agent Tree, tool calls, stage progress, preliminary reports, and audit sessions; users can continue the conversation to request evidence, attack-chain explanations, or reproduction details. Deduplicated findings are saved in structured form and can be edited or exported as reports for a subsequent CVE submission.
- An authorized security researcher wants an end-to-end CVE research workflow for an imported open-source project, including an audit trail and report output.
- A security team has scanner output and wants to use Enhanced Scan with Scan → Triage to reduce false positives.
- A vulnerability researcher needs direct source analysis for potentially high-value findings and chooses the Finding-centered Intelligent Audit mode.
- A code-audit team wants to combine tool-assisted scanning with source analysis in one task through Comprehensive Audit.
- A disclosure owner needs deduplicated vulnerability records and a report that can be copied into a CVE submission process.
What are this agent's strengths and limitations?
- Connects project selection, repository import, auditing, verification, and report generation in one defined workflow.
- Uses an Orchestrator to divide work among Recon, Scan, Triage, Finding, and Verification, combining scan-result filtering with source-led investigation.
- The Finding Agent explicitly uses a ReAct Loop, Nudge, and FinalizeFinding for audit control and structured completion.
- Provides activity logs, an Agent Tree, tool-call visibility, and session tracking for audit review and evidence follow-up.
- The material says a model must be configured but does not identify supported providers, required credentials, costs, or behavior when a model fails.
- Generating a CVE report is not CVE submission; the user remains responsible for submission and for following the target's disclosure policy.
- The project is restricted to explicitly authorized research, auditing, scanning, verification, and PoC testing; it is not for unauthorized target assessment.
- The supplied material does not document API authentication, model setup, repository-import mechanics, or production operations, leaving important adoption details unresolved.
How do you install or deploy this agent?
On Linux, macOS, or Git Bash, run:
curl -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | docker compose -f - up -dOn Windows PowerShell or CMD, run:
curl.exe -fsSL https://raw.githubusercontent.com/larlarua/AutoCVE/v1.0.5/docker-compose.prod.yml | docker compose -f - up -dFor a source deployment:
git clone https://github.com/larlarua/AutoCVE.git
cd AutoCVE
docker compose up -d --buildOpen http://localhost:3000 after startup. A model must be configured before auditing; the supplied material does not document supported providers, credential fields, or the configuration procedure.
How do you use this agent?
Open http://localhost:3000, configure a model in the product, import a project, and create an audit task. Select Enhanced Scan, Intelligent Audit, or Comprehensive Audit for the audit goal, then follow activity logs, the Agent Tree, tool calls, and stage progress. When the task finishes, review deduplicated structured findings in vulnerability management and edit or export the report. To apply for a CVE, copy the generated report and submit it yourself through the target project's SECURITY.md, GitHub Private Vulnerability Reporting, CNA process, or another responsible-disclosure route.
How does this agent compare with similar options?
The README identifies DeepAudit as an engineering-architecture reference during early development, but supplies no feature comparison, benchmark, or migration guidance.
FAQ
Does it submit CVEs automatically?
Which model credentials are required?
Can it scan any internet target?
What local endpoints are available after deployment?
http://localhost:3000, the backend API at http://localhost:8000, Swagger at http://localhost:8000/docs, and Adminer at http://localhost:8080.