Network Scanner

The problem

Small businesses rarely know what's actually on their network. A one-time scan tells you what's there today; it doesn't tell you what changed since last quarter, what's new and unexplained, or what services suddenly appeared on a host that shouldn't have them. Most off-the-shelf tools are either enterprise-priced or dump raw data without the context that makes findings actionable.

I wanted a tool built around the real workflow: scan, store, rescan, diff, report.

Architecture

The scanner is structured in stages, each writing to a PostgreSQL backend so results persist and can be compared across runs:

1. Discovery — host enumeration across the target range
2. Service identification — port and service detection on live hosts
3. Enrichment — banner grabbing, version detection, OS fingerprinting
4. Storage — normalized writes to scanner_db via db.py, schema designed for diffability
5. Diff reporting — comparison between any two scan runs, surfacing new hosts, new services, removed assets, and version changes

The multi-stage design mirrors how multi-agent pentest frameworks decompose work — each stage has a focused job and writes structured output the next stage can consume.

Why PostgreSQL instead of flat files

Diff reporting is the feature, and diffing is a database problem. Flat JSON files force you to re-parse everything on every comparison and don't scale past a handful of scans. With a normalized schema, the diff between scan #4 and scan #11 is a query, not a script.

What's next

• Scheduled scan runner with email-delivered reports
• Severity scoring on diff entries
• Export formats for client-facing deliverables

What I learned

The architecture decisions that felt over-engineered early — separating stages, normalizing the schema, treating diff as a first-class output — are the ones that paid off. Building around the workflow instead of the scan itself changed what the tool actually is.