Vulnerability Daemon

Local-first daemon for recurring AI-assisted vulnerability research across your own code folders.

Point it at local repositories, let your configured agents repeatedly audit them, and keep unreviewed critical findings visible until someone triages them.

The app icon is served as the favicon, the install manifest icon, the header brand mark, and the top-right review queue button: vulnerability-daemon-icon.svg.

What It Does

• Runs recurring security audits over local folders.
• Rotates across configured targets.
• Uses local agent CLIs: codex, claude, or cursor-agent.
• Randomizes agents when agent is set to random.
• Probes agent readiness and excludes non-ready agents from random selection.
• Stores markdown reports, normalized findings, raw logs, run metadata, and SARIF.
• Tracks critical review state: new, reviewed, accepted, false_positive, fixed.
• Serves a local dashboard and JSON API on 127.0.0.1.
• Exports SARIF and GitHub issue draft markdown.
• Optionally sends webhook notifications for new high-severity findings.

The core promise: never let a new critical finding disappear into a terminal log.

Product Shape

The normal user flow is app-like:

1. Start vuln-daemon.
2. It lives in the menu bar on macOS.
3. Reviews run on the schedule in your config.
4. Critical findings stay visible in the dashboard until reviewed.

The CLI commands remain available for automation, CI experiments, and debugging.

Install

From source:

cargo install --path .

During development, use cargo run -- in place of vuln-daemon.

Release automation builds platform tarballs, and macOS release jobs also produce a .app bundle. A Homebrew formula template lives at packaging/homebrew/vulnerability-daemon.rb.template. Signed release binaries are still planned.

Quick Start

Start the app:

vuln-daemon

or:

vuln-daemon start

On first run it asks for one local repo/folder to watch, writes the app config, starts the local daemon, and opens the dashboard. On macOS it also stays in the menu bar with actions for opening the dashboard, starting a review now, opening the config, and quitting.

Default app config locations:

• macOS: ~/Library/Application Support/Vulnerability Daemon/config.json
• Linux: ~/.config/vulnerability-daemon/config.json
• Windows: %APPDATA%\Vulnerability Daemon\config.json

Use a specific config when you want to keep project-local state:

vuln-daemon start --config ./vuln-daemon.config.json

Power User CLI

Create a config without starting the app:

vuln-daemon init

Write the example config directly:

vuln-daemon init-config ./vuln-daemon.config.json

Run one review immediately:

vuln-daemon run-once --config ./vuln-daemon.config.json

Run the daemon without menu-bar integration:

vuln-daemon start --config ./vuln-daemon.config.json --no-tray

Or run the raw HTTP server:

vuln-daemon serve --config ./vuln-daemon.config.json

Export SARIF after runs:

vuln-daemon export-sarif --config ./vuln-daemon.config.json --output ./results.sarif

Export GitHub issue drafts:

vuln-daemon export-issues --config ./vuln-daemon.config.json --output-dir ./issue-drafts

Reparse existing reports after upgrading parser logic:

vuln-daemon reindex --config ./vuln-daemon.config.json

Check local agent readiness and config posture:

vuln-daemon doctor --config ./vuln-daemon.config.json

Config

See config.example.json.

Important fields:

• bind_host: must be 127.0.0.1 for the MVP.
• output_dir: where runs and review state are stored.
• schedule.interval_seconds: seconds between scheduled runs.
• schedule.run_on_start: whether serve runs immediately on startup.
• agent_timeout_seconds: max seconds before a stuck agent run is killed.
• agent: random, codex, claude, cursor, or none.
• notifications.webhook_url: optional Slack/Discord/custom webhook URL for new findings.
• targets: local folders to audit.
• targets[].prompt_pack: one of generic, webapp, backend, smart-contract, or chain.

agent: "random" chooses one installed agent from codex, claude, and cursor-agent after a non-interactive readiness probe succeeds.

Set model only when you want to force a provider-specific model flag. Leave it as null to let each local agent use its own default model.

For a compiled binary:

cargo build --release
./target/release/vuln-daemon start --config ./vuln-daemon.config.json

API

The daemon binds only to 127.0.0.1.

• GET /api/status
• GET /api/runs
• GET /api/runs/<run_id>/report
• GET /api/findings
• GET /api/sarif
• GET /api/agent-health
• GET /api/config
• POST /api/run
• POST /api/cancel
• POST /api/open-config
• POST /api/findings/<finding_id>/review

Review request body:

{
  "status": "reviewed",
  "note": "Confirmed and filed internally."
}

Allowed statuses:

• new
• reviewed
• accepted
• false_positive
• fixed

Output Layout

out/vulnerability-daemon/
  state.json
  reviews.json
  runs/
    20260427T090000Z-my-repo/
      prompt.md
      report.md
      findings.json
      results.sarif
      meta.json
      agent.stdout.log
      agent.stderr.log

Example: One Local Chain Target

{
  "bind_host": "127.0.0.1",
  "port": 8831,
  "output_dir": "./out/nibiru-dogfood",
  "agent": "random",
  "model": null,
  "agent_timeout_seconds": 7200,
  "schedule": {
    "interval_seconds": 3600,
    "run_on_start": false
  },
  "targets": [
    {
      "name": "nibiru",
      "path": "~/code/sai-project/nibiru",
      "scope": "Cosmos SDK chain security: consensus safety, module authority, x/evm and precompile boundaries",
      "prompt_pack": "chain",
      "prompt": "Prioritize confirmed code-backed findings with concrete attack paths."
    }
  ]
}

Headless Daemon Install

Examples are included for:

• systemd
• launchd

Both examples run the HTTP/scheduler daemon without menu-bar UI. They assume you have installed the compiled binary somewhere stable and created a config file. The dashboard should remain bound to 127.0.0.1.

Security Notes

This MVP intentionally binds to 127.0.0.1 only. Do not expose it directly on a public network. Reports can contain sensitive vulnerability details, source paths, and exploit sketches.

Read the full security model before using this on private or sensitive repositories.

Roadmap

• write-token for review and run-trigger endpoints
• redacted public mode
• per-project report retention policies
• signed run metadata
• local-first GitHub/GitLab handoff that makes network export explicit
• prompt-pack marketplace