Skip to main content

Operations, Signature Updates & Maintenance Guide

This guide covers day-2 operational maintenance, vulnerability template updates, transactional concurrency safeguards, and diagnostic procedures for self-hosted VulnerGuard deployments.

1. Routine Service Management​

From your deployment's root compose directory (<WORKSPACE_ROOT>):

# Inspect status of all platform services
docker compose ps

# Tail real-time logs from the core orchestration plane
docker compose logs -f backend mcp

# Rebuild and hot-swap the web & documentation gateway
docker compose up -d --build frontend

# Rebuild and restart core API + MCP execution services
docker compose up -d --build backend mcp

2. Updating Vulnerability Templates & Signatures​

To keep detection accuracy sharp against newly disclosed 0-days and CVEs, periodically refresh the signature databases inside the persistent scanner volumes:

Update Nuclei Templates​

docker compose exec nuclei nuclei -update-templates

Update Trivy Vulnerability Database​

docker compose exec trivy trivy image --download-db-only

Update WPScan WordPress Database​

docker compose exec wpscan wpscan --update

3. Transactional Concurrency & Database Safeguards​

VulnerGuard's persistence layer is accessed concurrently by API request workers and background SecurityAgent threads.

Built-in Concurrency Safeguards​

  1. Connection Busy Timeout: Configured with a 30-second connection timeout so concurrent background finding inserts never fail during spikes.
  2. Immediate Quota Commits: Monthly organization quota records (OrgUsageMonthly) are committed immediately prior to spawning scan workers, preventing lock contention when /api/scan creates the Scan record.
  3. Single Application Context per Request: Route handlers maintain a clean, single request-scoped session lifecycle.

4. Diagnostic & Troubleshooting Guide​

Symptom A: Tool Execution Reports Runtime Proxy Connection Refused​

  • Root Cause: The scoped container runtime proxy service was stopped or its socket directory mount permissions were altered.
  • Resolution:
    1. Verify the runtime proxy container is running and healthy via docker compose ps.
    2. Ensure the shared socket directory mount is present on backend, mcp, and trivy.

Symptom B: Tool Reports 0 Findings on a Known-Vulnerable Target​

  • Diagnostic Step 1 — Verify Target Scheme Normalization: Ensure web tools (nuclei, katana, ffuf, zap) receive an https:// or http:// URL while network/DNS tools (nmap, subfinder, testssl) receive the stripped hostname (handled automatically by SecurityAgent.execute_step).
  • Diagnostic Step 2 — Check Tool Readiness: Query GET /api/tools/status or check the Command Center (/dashboard) to confirm all 14 engines report Ready.