Dfence: about 100 security appliances operated with SaltStack

Dfence was a continuous vulnerability assessment service for company networks, which I co-founded and ran as CTO and Head of Product from 2022 to 2025. The service reached 20 paying customers, each with 3 to 5 monitored sites. Physical security appliances installed at the customer sites ran the vulnerability assessment engine against the local network; at the peak the fleet counted about 100 appliances, all behind customer firewalls and none reachable from outside.

The operational problem is the one every appliance business meets. A hundred boxes in a hundred different networks have to be started, stopped, updated and read, and each of them can only scan as much as its own hardware allows. Logging into them one by one does not scale, and a generic remote-execution script does not know what the scanning engine is doing.

I chose SaltStack (Salt) as the control plane. Each appliance was a Salt minion connected outbound to a central master, which suited the customer firewalls: no inbound port on the customer side. On top of Salt I wrote custom execution modules in Python that spoke to the scanning engine through its management API, so that every operation on the fleet was a Salt call with a structured, machine-readable result rather than a shell command with text to parse.

What the modules did

Resource-aware start of scans. A scan is heavy on CPU, memory and network, and starting every scheduled task at once on a small appliance degrades all of them. The module checked what the machine could take and launched processes accordingly, keeping concurrent scans within the appliance’s capacity.

Start, stop and status of the scanning processes, fleet-wide or per customer, from the master, with each minion’s result returned to the master.

Updates of the scanning software across the fleet. The engine’s feeds and images changed frequently and pinning versions was not workable, so updates were driven from the master in controlled groups rather than left to each box.

Report collection. Finished reports were retrieved through the Salt API and forwarded to a central report processor, which loaded them into a database, enriched them and produced what the customer received.

Performance monitoring. Appliance and scan metrics were sent to Elastic, so that a slow or overloaded appliance showed up on a dashboard before it became a complaint.

Why it matters

It is the same discipline I apply to web platforms today: one control plane, operations that return data instead of text, capacity treated as a constraint to respect rather than discover in production, monitoring that shows the problem before the customer does.

Limits

The fleet size is my own statement as former CTO. No figure on rollout time, scan throughput or report latency is quoted because I do not have documented measurements to support it. The scanning engine is not named, and no customer, network or infrastructure detail is published.