Most vulnerability scanners today are cloud SaaS. You point them at a target, they run in someone else's infrastructure, and the findings — along with a detailed map of your attack surface — live on a third-party server. For a lot of organizations that's a non-starter: banks, defense, healthcare, critical infrastructure, anyone with a genuinely air-gapped network.
That gap is why I built hackz: a corporate DAST scanner that runs fully offline. No cloud, no telemetry, no license phone-home, no path for scan data to leave the environment. Here's some of what that takes — and why building it made me a better manual tester.
Offline is an architecture decision, not a flag
You can't bolt "offline" onto a tool that assumes internet. It has to be a first principle. In practice that meant:
- Bundled everything. Every check, signature, and dependency ships inside
the artifact. An
--offlinemode runs purely from bundled plugins with no outbound calls whatsoever. - No external tool shell-outs in the offline path. If a check needs a capability, it's implemented in-process as pure code, not by shelling out to something that might not be present on an isolated host.
- Single-artifact deployment. One binary or one container image you can transfer across an air gap once and run indefinitely.
The test I held myself to: unplug the network, and the scanner should behave identically. If any feature degrades offline, it wasn't really offline.
An engine/plugin core
Under the hood, hackz is built around a small engine with a plugin registry. Self-registering check modules are discovered automatically, each declaring what surface it applies to. A shared HTTP substrate handles raw requests, insertion points, and a traffic log every check can reason over. That structure keeps the core tiny and makes adding a new check a matter of dropping in a registered module — which matters when you want the same engine covering web, network, and even z/OS mainframe surface.
The hard part: access control
The feature I care most about is the multi-user access-control engine, because it's the class of bug generic scanners can't see (I wrote a whole post on why that is). Making a scanner reason about authorization means teaching it to hold several authenticated identities at once, map each one's reachable surface independently, and then systematically cross-replay every object and function across every identity — with each identity's own valid session, so a rejection is a real authorization decision rather than a malformed request.
Getting request fidelity right here is everything. A test request that's missing a cookie or a CSRF token fails for the wrong reason and produces a false negative. So the engine builds every cross-identity request from a real, structurally valid baseline and swaps only the target object — the same discipline I follow by hand in a manual test.
Deploying like Nessus
Security teams already know the Nessus workflow, so hackz mirrors it: a first-run setup that generates an admin credential, user management, and a familiar console. On first boot with no admin user, it prints a generated password and you're in. Small thing, but it means a team is productive on day one instead of fighting configuration.
Why building it made me a better tester
Here's the part I didn't expect. Writing the code that maps a surface, replays requests across identities, and decides what counts as a finding forces you to understand — precisely — where automation ends. You feel exactly which bugs a machine can enumerate and which ones need a human who understands the application's intent: the weird state machines, the chained low-severity primitives, the business-logic abuse that no signature will ever match.
That's the whole thesis behind this site. The scanner handles breadth. I handle depth. When you hire me for an engagement, you get both — and a tester who knows the difference cold because he had to build the line himself.