Case studies — how I solve problems

Sorting through millions of vulnerabilities — on one desktop, entirely local

processing engine built from scratch · SQLite + WAL · no server, no cloud backend

Problem: A real Tenable.io tenant exports findings by the million. Hold that in RAM and the process dies; the industry answer is a server-side database and a web stack. My constraint was the opposite: everything runs locally on the operator's own machine. The only network traffic is the pull from Tenable's API and whatever the operator explicitly sends to ServiceNow — vulnerability data never leaves the box.
What I built: A disk-backed processing engine written from scratch. A streaming ingest pipeline (chunk download → parse → upsert) with orjson handling multi-megabyte chunks. A DiskBackedDict storage layer that swaps in-memory dicts for SQLite tables behind LRU RAM caches — WAL mode, tuned durability — so the working set stays bounded no matter how large the tenant is. Adaptive API rate limiting with named profiles (ultra-conservative through aggressive) that hot-apply mid-run, chunk sizing aligned to Tenable's own developer guidance, and milestone publishing at 25/50/75/100% so the dashboard fills progressively instead of wedging on per-chunk updates.
Without crashing or clogging: The failure modes of scale — lock storms, GUI-thread starvation, full-table rebuilds per tick — were each hunted down and fixed at the right layer: memoized policy resolution, single-pass CVE aggregation, reload work moved to worker threads with guarded render slots so only paint touches the UI thread. Multi-million-finding ingests ride through with the dashboard live the entire time.
Proof: The storage layer, rate-limit profiles, and performance postmortems are written directly into the source head (source/tenable_sla_analyzer_v474.txt), including freeze diagnostics so a responder checks runtime state instead of guessing.

Vulnerabilities don't get fixed until someone owns them

in-app ownership assignment shipped · ServiceNow ownership sync + automated ticketing in active development

Problem: Scanner output tells you what's broken, not whose queue it belongs in. In most shops ownership lives in a stale CMDB or in someone's head, so past-SLA findings sit unassigned — the vulnerability equivalent of unrouted mail.
What I built: Ownership is a first-class record in the analyzer: every asset carries manager, team, source, and updated-at. The Asset Tagger assigns ownership from inside the application — match assets by label, hostname, FQDN, IPv4, or asset ID with substring and glob search, preview exactly what matched, then bulk-apply. Owner and team follow the asset through every view after that: dashboards, drilldowns, search, exports.
In active development: The ServiceNow lane. Ownership reconcile from the SNOW CMDB (gated behind a verified link, with the CMDB as source of truth) and pushes back the other way — plus automated ticketing driven by past-SLA Tenable CVEs: one ticket per CVE-and-owner pair so each owner sees only their own assets, triggered per-row or fleet-wide ("Auto-Escalate All Past-SLA"), always behind a confirmation that shows exactly how many tickets will mint and to whom. The full flow runs end-to-end against the mock ServiceNow instance today; the live-instance client is the piece in flight.
Proof: Asset Tagger and ownership overlay in the v468+ changelogs; ttm escalate-cve and bulk-escalate-past-sla CLIs; CMDB push gated by snow_link_verified.

"A zero-day dropped this morning — which of our assets are affected?"

Zero-Day Intelligence module · CISA KEV, NVD, and ZDI feeds matched against local data

Problem: When a new zero-day lands, leadership doesn't want a severity lecture — they want a list: do we have it, on which assets, and who owns those boxes. Getting that list usually means waiting on the next scan cycle and cross-referencing by hand.
What I built: The Zero-Day panel pulls the CISA Known Exploited Vulnerabilities catalog plus NVD and ZDI feeds and matches new entries against the findings already ingested on disk — so the answer comes from local data in seconds, not from a fresh scan. One click takes an intel hit to its affected-asset list with owner and team attached, and KEV metadata (date added, due date, vendor) rides along in the operator view. KEV membership and affected-asset count also feed the multi-factor risk score, so actively exploited findings climb the queue on their own.
Proof: Zero-Day Intelligence module in the source head: the feed registry, the "assets affected by a selected zero-day intel hit" drilldown, and the risk model (severity × time-to-breach × KEV × affected count).

The attack surface you don't scan is still your attack surface

ASM module · Tenable Attack Surface Management coverage

Problem: Vulnerability management covers the assets you know about and scan. The internet-facing surface nobody remembers — forgotten subdomains, exposed services — is exactly what an attacker enumerates first, and it never appears in a scan-based view.
What I built: An ASM module that pulls Tenable Attack Surface Management data into the same operator view as the vulnerability data, as a live dashboard snap-in with its own aggregate metric. Internet-facing exposure is flagged on asset views through a bounded cache so the check stays cheap at scale. The ASM bearer token is prompted for when needed and held in process memory only — it is never persisted to disk.
Proof: v470 changelog: fetch_asm_aggregate() on a background thread, the agg_asm dashboard metric, and the token-handling policy in the module source.

Let operators customize ticket fields — without handing them an injection vector

prefill engine · safe template renderer built from scratch · 156/157 tests green (fresh 2026-07-14 run)

Problem: Every ServiceNow shop fills ticket fields differently, so the ticket form has to be operator-configurable. The obvious answers are all wrong: hardcoding fields doesn't ship, and Python's own string formatting on user-supplied templates is a sandbox escape ({obj.__class__...} attribute traversal). No library gave me "operator-editable templates that provably cannot introduce new behavior."
What I built: A prefill engine where every field is one of exactly four kinds — literal, binding (dotted-path lookup against the CVE/asset context), template (a safe renderer I wrote that rejects dunder access, indexing, and eval-like patterns while still supporting date/number format specs), and derived (a closed, whitelisted derivation registry — profile JSON cannot register new rules). Profiles are stored Fernet-encrypted with an HMAC integrity tag under a key deliberately different from the dispatcher's primary vault key. The live SNOW client behind it refuses plain HTTP at construction time — no verify_ssl=False flag exists to misuse.
Proof: Design spec compliance/SNOW_TICKET_DESIGN.md; evidence run compliance/evidence/v464_snow_iter2/ (Bandit 0 HIGH, gitleaks 0, DAR probe 0); dedicated security-regression tests for the renderer (rejects __class__, [0], !r), tamper and wrong-key cases on the profile store, and wire-format/retry-classification tests on the client.