CASE 04 · 2026 · Builder · Security tooling
OMNISECTESTER
A nation-state-grade, defense-in-depth security testing framework in one CLI.
STATUS
OPEN SOURCE — SHIPPED
RESULT
Seven attack surfaces, one disciplined CLI — every surface independently shippable without a core release.
LIMITATIONS
Adapter catalog covers the 7 documented surfaces; coverage depth varies by surface.
01
THE PROBLEM
Security testing is fragmented — a different tool for web, mobile, cloud, AI/LLM, hardware. Teams need one disciplined surface to audit everything from a single command line.
7 attack surfaces, one CLI
02
THE HARD PART
Seven attack surfaces, one disciplined CLI — the engine had to stay small while every adapter stayed independently shippable, so a single bad dependency could never poison the whole tool.
03
WHAT SHIPPED
A defense-in-depth security framework covering 7 surfaces from a single command line, with per-surface adapters that update independently.
THE FULL STORY
The story
Security tooling has a fragmentation problem: a different scanner for every surface,
each with its own syntax, its own CI wiring, its own blind spots. Teams don't adopt
seven tools — they adopt one workflow. So the product decision came first: one
disciplined CLI, seven surfaces.
The engine is deliberately boring. The interesting part is the adapter contract —
every surface ships independently, so a bad dependency in the cloud adapter can never
poison the web sweeper. That split happened because the first version was monolithic
and one wrong package broke everything.
Defense-in-depth is the design thesis. Any single scanner is bypassable; layered
checks mean a finding survives even when one layer is blind. That's the difference
between a tool that reports and a framework that holds.
IMPACT
- 7 attack surfaces, one CLI
- Defense-in-depth by design
- Supply-chain and AI/LLM coverage included
THE ARCHITECTURE
Layered, labelled, honest — the system as it actually stands.
01 · TARGET
02 · ADAPTERS
03 · ENGINE
04 · OUTPUT
SYSTEM FLOW
WHAT IF …
Ask the project a different question. The architecture has to defend itself.
What if you'd written it in Rust instead of JS?
Compile-time memory safety and a faster engine, but a steeper contributor curve and slower shipping — for a security CLI the attack surface is the adapters, not the runtime. JS won on iteration speed and ecosystem reach (Playwright, fetch everywhere). I'd still pick JS today.
What if it had 10× the adapters?
The per-surface adapter contract is the moat: if each adapter is small and dependency-light, 10× adapters means 10× small plugins, not 10× complexity. The risk becomes maintenance drift — so I'd add an adapter manifest + schema tests + a monthly compatibility CI before scaling the catalog.
DIVE DEEPER
Built it — now the descent. Each question opens the next layer: why, why this architecture, what broke, what I'd change.
01Why one CLI for seven surfaces?
Security teams don't adopt seven tools; they adopt one workflow. A single disciplined entry point with per-surface adapters keeps the core tiny and the coverage honest.
02Why defense-in-depth by design?
Any single scanner is bypassable. Layered checks — network, app, supply chain, AI/LLM — mean a finding survives even when one layer is blind.
03What went wrong?
Early adapters were monolithic: one wrong dependency poisoned the whole CLI. I split the engine from the adapters so each surface ships and updates independently.
04What would I do now?
Add an adapter manifest + schema tests and a monthly compatibility CI before scaling the catalog past the current seven surfaces.
THE REPO, INSIDE
Not a screenshot — a live iframe pulling this repo's README straight from the CDN.