Receiving a 117-Finding Audit

Before launch, an outside architect ran a dedicated review against the platform where I serve as CTO — a hiring product for security-cleared professionals, where the data is sensitive by definition and the customer base is exactly the population least willing to forgive a leak.

The review ran in three phases: a static architecture and code pass, a live pass combining UI walkthroughs with state-boundary and adversarial testing, and a dedicated penetration test. Across all three it catalogued 117 findings, plus a further set of general practice notes.

That is a large number to receive on your own work. The reflex is to argue severity. The useful response is to build the machinery that closes them and keeps them closed.

The first thing built was not a fix, it was a ledger. Every finding got an identifier, a current state, an owner, and the evidence that closed it, living in the repository beside the code rather than in an email thread. That single artifact is what made a hundred-finding backlog tractable — at any moment there was one authoritative answer to "what is actually still open?"

Findings that needed risky or multi-step changes — authorization model rewrites, policy changes touching live data — got their own runbooks written before the change, so the sequence was decided while thinking clearly rather than mid-migration.

The work itself spanned Row Level Security policy design, edge-function authorization, input bounds, secrets handling, webhook verification, AI guardrails, content security policy, and account-enumeration surfaces.

The penetration phase produced the classes that are easiest to get wrong and hardest to notice:

The one worth singling out is column-level write control. Row Level Security is very good at answering "may this user touch this row" and says nothing about which columns they may write. A user permitted to update their own profile row is not thereby permitted to set their own role or verification status — but a naive policy grants exactly that, and it reads as correct in review.

In one four-day stretch, 30 P1 and P2 findings were closed. The reviewer's own summary described the drop in open severity as a dramatic collapse — the active stack went from a handful of high-severity items to close to none.

The findings were the smaller half of the value. What remains is a reusable 20-class vulnerability catalog with a detection technique and severity rubric for each class, and a runnable harness that executes the static and live probes against any project and produces a report.

I now run that against new builds on day one rather than waiting for someone else to find the same classes at pre-launch. The closed findings are also wired into CI, so the specific mistakes that were made once cannot quietly return.

Receiving a hard audit well is a skill worth having on a team. The findings are free information about your blind spots, and the only wrong response is a defensive one.