DeepAudit: a multi-agent vulnerability miner you can run on your own hardware

The gap DeepAudit tries to fill

Traditional SAST tools match patterns. They are fast and deterministic, and they also produce long lists of candidates that a human still has to triage. DeepAudit takes the opposite bet: several LLM agents read the code, discuss it, and then a sandbox step attempts to prove the finding with a proof-of-concept. The README frames this as giving every team an AI audit squad, and the project describes itself as China's first open source multi-agent code vulnerability mining system. The intended user is a security engineer or backend developer who wants to point a tool at a repository and get a report, without standing up a full pentest lab. The repository layout supports that reading: there is a backend/ directory, a frontend/ directory, a rules/ directory, and a sandbox image referenced from the Compose file. The README also states that the closed-source edition of DeepAudit has been credited with 49 CVE IDs and 6 GHSA advisories across 17 projects, including six advisories against OpenClaw and CVEs against DataEase, PowerJob, JimuReport, H2O-3 and others. Those numbers describe a different build than the one in this repository, and the README does not publish a false-positive rate for the open source version, so treat the CVE list as evidence that the approach can find real issues, not as a benchmark for your own run.

How the agent and sandbox pipeline is wired

The Compose file names the moving parts. A Postgres 15 container holds state, a Redis container backs the queue, and the backend container runs the FastAPI application on port 8000. Two environment variables in the backend service, AGENT_ENABLED=true and SANDBOX_ENABLED=true, switch on the two stages that matter. The backend mounts the host Docker socket at /var/run/docker.sock, and the Compose comment states this is required for sandbox execution. So the flow is: you import a repository (the README lists GitHub, GitLab and Gitea as sources), the agent stage produces candidate findings and streams its reasoning into an audit log, and the sandbox stage spins up a container from SANDBOX_IMAGE=deepaudit/sandbox:latest to attempt verification. Reports can be exported as PDF, Markdown or JSON. Two details are worth flagging. First, mounting the Docker socket gives the backend container effective control over the host daemon, which is a large trust decision for a tool that executes code under audit. Second, the Compose file explicitly blanks HTTP_PROXY, HTTPS_PROXY and sets NO_PROXY=* on the backend, with a comment saying this prevents the container from failing to reach external APIs. That is a deliberate trade-off: proxy-based egress control will not work here without editing the file.

Installing DeepAudit with Docker Compose

The Compose header gives the deployment command directly. From the repository root, with Docker and the Compose plugin installed, run the stack in the background:

docker compose up -d

Then follow the startup, because the backend waits on health checks for Postgres and Redis before it runs migrations:

docker compose logs -f

The backend service declares env_file: ./backend/.env, so that file must exist before the stack will start cleanly. The Compose file is the only deployment path documented in the README excerpt; there is no pip or npm install line in the README. Once the containers are healthy, the web UI is reachable on the frontend port and the API on port 8000. A first real use is the quick analysis path shown in the README screenshots: paste a code snippet or upload a file for an instant scan, which returns a result without the full agent loop. For the deeper mode, add a project through the GitHub, GitLab or Gitea import, then start a Multi-Agent audit and watch the audit stream. The README notes that the sample report images come from quick mode, not agent mode, so do not calibrate expectations from those screenshots.

Where the design bites back

The largest limitation is documentation language. The primary README is Simplified Chinese, with README_EN.md and README_JA.md present in the repository, and the English translation's completeness is not stated anywhere. Configuration keys, error messages and the audit log will largely be Chinese, which raises the cost of debugging a failed run. The second limitation is verification scope. The README states the sandbox performs automated PoC verification, but it does not describe which vulnerability classes can be proven this way. Logic flaws, authorization mistakes and business-rule bugs generally cannot be demonstrated by executing a payload, so findings in those categories will remain unverified claims from the model. Third, LLM auditing is non-deterministic: the same repository can yield different findings across runs, and nothing in the README describes a seed, a temperature setting or a reproducibility mode. If your process requires an auditable trail from rule to finding, a conventional SAST engine is the better fit and DeepAudit is the wrong tool. Finally, the project's own README leans on CVE counts from a closed-source build; that is marketing for the commercial edition, and it tells you nothing about recall or precision on your codebase.

DeepAudit against Semgrep and CodeQL

Semgrep and CodeQL sit at the other end of the spectrum. Both parse code into a queryable representation and evaluate rules written by humans, so a finding traces back to a specific pattern and the same input yields the same output. Semgrep rules are readable and you can write your own in a day; CodeQL requires a build step for compiled languages but gives deep dataflow queries. Neither attempts to execute a proof-of-concept. DeepAudit inverts both properties: coverage depends on what the model notices rather than on rules you wrote, results vary between runs, and the sandbox stage tries to close the loop by actually running something. The practical difference shows up in triage. With Semgrep you argue about whether a rule is too broad. With DeepAudit you argue about whether the model's reasoning is sound and whether the PoC really demonstrates the issue. That makes DeepAudit a complement rather than a replacement: it can surface a class of issue no rule encodes, and it can also produce confident nonsense that costs review time. Teams already running Semgrep or CodeQL should treat DeepAudit as an additional pass, not a migration target.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-01-24, which is the same timestamp as the v3.0.4 release. That is roughly eight months before today, so this is not a project with continuous recent activity; releases v3.0.2, v3.0.3 and v3.0.4 landed between 2025-12-18 and 2026-01-24 and there is nothing newer in the repository. Plan for a maintenance model where you may need to fix things yourself. The default branch is named v3.0.0, which is unusual and worth knowing before you script a clone. Upgrades run through the Compose stack, and the backend command applies database migrations with alembic upgrade head on startup, so a version bump can alter your schema without a separate migration step. Three Compose variants ship in the repository: docker-compose.yml, docker-compose.prod.yml and docker-compose.prod.cn.yml, the last aimed at networks where the standard registries are slow. On licensing, the project is AGPL-3.0. That licence's network clause means running a modified version as a network service can trigger source-disclosure obligations. If you plan to offer DeepAudit's output as a hosted product, read the licence text and DISCLAIMER.md yourself; this is a description of the terms, not legal advice.

Editorial conclusion

Adopt DeepAudit if you can read Chinese documentation, already run Docker and Postgres, and want an LLM audit pipeline that never sends source code to a hosted API. Do not adopt it if you need an English manual, a published accuracy baseline, or a support contract. Before trusting a run, verify that the sandbox image deepaudit/sandbox:latest builds on your host, that /var/run/docker.sock is acceptable to your security team, and that the AGPL-3.0 network clause fits how you plan to expose the web UI.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes