bluechips-zhao/DITING

Adopt this only if you already run authorized engagements and can supply your own PostgreSQL, login password and model credentials; it is a working surface, not a turnkey scanner.

The problem

A tester starting a scoped engagement has to keep the target inventory, recorded traffic, model conversations, candidate findings and the final report in separate tools, then reconcile them by hand. That makes it easy to lose which request produced a given finding or which report version was shared. DITING puts assets, scope rules, agent runs, captured traffic and findings into one self-hosted workspace, so a finding can be traced back to the request/response pair and regenerated into a report. The result is a single audit trail of the task rather than a folder of exports.

What's different

The project is a modified fork of ARTEX that keeps the asset graph, multi-agent exploration, traffic evidence and manual approval, and adds token/tool budgets, evidence relationships, report versions, full export and encrypted backup/restore project instructions. The 2.6 release focuses on run observability: model-call usage accounting, execution statistics, and source/review status for candidate signals, which stay pending review rather than becoming confirmed vulnerabilities automatically release notes. A budget mechanism with conservative reservation and a wind-down phase limits runaway loops, though the README states the token budget is a local usage ledger, not a vendor billing figure.

The trade-off is that the tool assumes operator judgement. Constraints only feed agent context while tool interception rules execute separately, so scope enforcement depends on configuring both. Candidate findings are deliberately not promoted automatically, which means human review is part of the workflow rather than optional polish.

Who should try it

This suits a penetration tester or small red team that wants a self-hosted LLM-assisted workspace over an authorized scope and is willing to supply a database and model configuration. Docker users get a compose template with separate persistent volumes for runtime secrets and workspace data, keeping keys out of the browsable data directory backup notes. Those who want a one-click cloud scanner, or who cannot run PostgreSQL 16+ locally, should look elsewhere. Non-Windows users must build from source; the release ships a Windows amd64 package, and the Docker template is a source-build entry point rather than a prebuilt image.

Requirements and limitations

First start is a blank business state: no demo database, admin password, model key or tasks are included, so setup means creating a PostgreSQL 16+ database, setting an 8-character-plus login password and configuring a model getting started. Source builds need Go 1.26.3+, Node 22, npm and PostgreSQL. The setup wizard binds to loopback and checks local origin, Host and a one-time launch token.

Ongoing care is the bigger cost. Model credentials and other secrets are encrypted with a separate secrets.key; losing or replacing it can halt startup, and backups need that key packaged or explicitly declared separately backed up. Upgrading from 2.3.x to 2.4.0 encrypts old credentials, so rolling back requires restoring a pre-upgrade database and workspace backup. The README also states the 2.6.0 container image was not rebuilt or accepted because Docker was unavailable at release; earlier 2.5 local records do not count as this release's image acceptance.

HotRepo's take

HotRepo recorded 119 total stars and a #23 position on its NEW-REPOSITORY board (新项目榜, not the overall Trending board) on 2026-10-25, from a repository created 2026-10-11. There is no comparable daily-board history, so whether interest persists cannot yet be judged. Before investing time, verify the Windows release and the documented encrypted-backup restore path match your environment, since the recovery workflow is the part most likely to matter after real usage.