0x77: Sec-Dashboard

52 tools, one port and zero cloud

Running a scan means opening ten tabs, copying output into a note and losing half of it along the way.

I wanted a local panel that runs the tools, keeps the history and lets you export the results.

Sec-Dashboard is exactly that: FastAPI + one framework-free JavaScript page, all on 127.0.0.1.

What need does it cover, and for whom?

For the solo analyst or the small SOC that wants to do recon without cloud accounts or API keys scattered everywhere. Before, that meant one tool per tab, output copied by hand and history scattered across CSVs nobody ever opens again.

Now there is a panel with the 52 tools, persistent history and export to JSON, PDF or Splunk from the same page.

Honestly I built it for my own SOC but it scales perfectly.

The niche is me and my ecosystem, but any solo analyst can use it just as well because it depends on nothing that is not already on their machine.

What it brings to an SOC (blue team)

• Exposure surface: subdomain, DNS and email (SPF/DKIM/DMARC) recon plus TLS with deep certificate analysis. This is the inventory part that is almost never up to date, and without inventory there is no fine-grained detection.
• Triage with context: CVE search and correlation, exploitability checks (ExploitDB, Vulners) and finding classification with Jev, which also explains it in plain language — useful for deciding what to patch first without opening five websites.
• Feeds the SIEM: self-indexing into Splunk over REST (index sec_dashboard, with its own sourcetypes like powershell:audit and wifi:marauder). The result of an analysis becomes queryable, correlatable evidence, not a loose PDF in a folder.
• Evidence for the report: JSON, CSV, PDF and an executive PDF per pipeline. From finding to report without building the template by hand, with the same data that got indexed.
• Endpoint and artifacts: security audit on Windows via PowerShell, offline analysis of WiFi captures (.pcap) and RF (.cff from HackRF). None of it requires uploading the file anywhere.
• Local-first, which in security is a decision: no accounts or API keys and the data never leaves the machine. Works in restricted or isolated environments and fits GDPR better.
• History and comparison: targets and scans persist, two runs can be compared, and you see what changed between yesterday and today. For asset tracking, which is the blue team's real job.

Day to day: a new domain comes in, fast to get the map, deep or nuclear if something smells bad, Jev and its explanation, export and indexing into Splunk, and everything stays in the history for the report.

Before and after

Building each target's context by hand with the history scattered across CSVs was the slow part. Now the fast mode resolves recon and ports in about a minute, the result lands in SQLite with its date, and the history is queried with search. What saves the most time is not the speed: it is never having to rebuild the context of a target you have already seen.

How it works?

1. FastAPI backend and vanilla JS SPA frontend: a single index.html, no framework, no build.
2. 52 tools in 7 categories (Network Recon, Web Security, Vulnerability, System, OSINT, Email Security, RF Hardware). Thirteen are special tools that take no target: hash checker, password audit, CVE search and system information.
3. Flow engine (pipelines) with four modes: fast (~1 min), deep (~5), full_depth (~4) and nuclear (~7). Each mode is a chain of phases and each phase chains tools. Updates arrive live over WebSocket (/ws).
4. SQLite in data/sec.db: targets and scans persist across restarts, with search and pagination in the history.

1. AI layer (v2.0): Jev classifies findings with structured questions and a local LLM writes the explanation in Spanish. The local_llm.py module only accepts loopback URLs: the model never leaves the machine.
2. Runs 100% locally, no cloud or accounts. Optional TOR/SOCKS5 proxy for the OSINT tools that need it.

How I set it up

git clone https://github.com/PoisonXploIT/sec-dashboard.git
cd sec-dashboard
python -m venv .venv
# Windows: .venv\Scripts\activate  |  Linux/macOS: source .venv/bin/activate
pip install -r requirements.txt
uvicorn backend.main:app --host 127.0.0.1 --port 8444

Open http://127.0.0.1:8444 and that's it.

Minimal dependencies: FastAPI, uvicorn, aiohttp, aiosqlite, dnspython, scapy, fpdf2 for the PDFs.

Three pieces of code worth looking at

backend/config.py is where the 52 tools (TOOLS) and the pipelines (PIPELINES) live.

A pipeline is just data, phases with lists of tools.

"fast": {
    "name": "Fast Scan",
    "description": "Quick recon + port scan (~1 min)",
    "phases": [
        {"name": "Recon", "tools": ["whois_lookup", "dns_recon", "http_probe"]},
        {"name": "Scan", "tools": ["port_scanner"]},
    ],
},

backend/validators.py — validate_target() is the SSRF protection

In remote mode it blocks private IPs, loopback and metadata endpoints (169.254.169.254), and logs every block as a WARNING so there is a trace.

backend/local_llm.py — explain_finding() asks the local LLM for a plain-language explanation of a finding and is_loopback_url() is the guard that prevents pointing that call at anything that is not localhost.

And this is what a running pipeline looks like, phase by phase, with the WebSocket updates.

How I built it?

Built with AI, tool by tool.

The idea, the architecture and what I review are mine; each tool is asked of the AI as a separate module and I don't accept it until I test it live against a real target.

I don't let it make the security decisions

• The SSRF rule, rate limiting and the double auth layer (Cloudflare Access + X-API-Key header) — I defined them and it only implements.

• The project history has three jumps: v1.1 with 35 tools and 6 categories; v2.0 with the AI layer (Jev + local LLM); and the current state, 52 tools and 7 categories including RF Hardware (offline analysis of HackRF .cff and WiFi pcaps).

• In August I did a proper audit with static review of the 8,113 LOC plus live tests against a second instance with SEC_DASHBOARD_REMOTE=1 simulating the public deploy.

• Ten findings, two critical, all fixed and verified on that same remote instance.

Decisions and mistakes

• Vanilla JS instead of React: the whole SPA lives in one index.html. What I gained (zero build, zero frontend dependencies) costs me as it grows, and the UI logic no longer fits well in a single file.
• SQLite instead of Postgres: zero configuration, and for a local tool that was the right call. The cost is that it is not designed for several instances writing at once.
• Critical mistake: /api/tools/{id}/run accepted the raw target without validating. In remote mode anyone could use the server as a scanning proxy against private networks and cloud metadata. My audit found it and the fix was to pass every tool with a target through validate_target().
• Mistake: the API key leaked into uvicorn logs. Rotation and a double layer in the public deploy (Cloudflare Access + API key) because one single layer proved not enough.
• Dropped: VPS without Cloudflare Access — dropped it precisely because of audit finding C2, a public API with no authentication; without that layer I would not publish.

What I would improve

• Split the SPA into modules, since index.html grew past healthy to keep maintaining it as a single file.
• Extend Pytest coverage to the RF Hardware tools (offline .cff and pcap) with fixtures that today are the least tested.

Links

• Code: https://github.com/PoisonXploIT/sec-dashboard ·
• Try it and tell me how useful it is for your work and what could be improved or changed.
• Local demo at 127.0.0.1:8444 (the public deploy is behind Cloudflare Access through this website).

Originally published at https://sammideblas.com/posts/0x77-sec-dashboard