What a Security Review Actually Looks For
Not a checklist of vulnerabilities, but a map of where trust breaks down.
Most people picture a security review as someone running a scanner and printing out a list of CVEs. That happens, but it's the smallest part of the work. A real review is an exercise in reading a system the way an attacker would: not "does this code have bugs" but "where does this system trust something it shouldn't."
Every application is a chain of trust decisions. This request came from an authenticated user, so we'll let it write to the database. This webhook came from Stripe, so we'll believe its payload. This admin token was issued once, so we'll honor it forever. Each of those decisions is reasonable in isolation. A review's job is to find the ones that were never actually verified, just assumed.
That's why a good review spends more time reading than testing. We trace how data moves from an untrusted edge — a form, an API, a file upload — to the places it eventually gets treated as fact: a SQL query, a permission check, a rendered page. Most serious issues live in that gap, where data quietly changes status from "something a user sent us" to "something we believe."
We also look hard at the boring paths: password reset, account recovery, invite links, admin impersonation. These features get built early, under deadline pressure, and then never touched again. They're rarely exercised in normal testing because nobody resets their password twice a day. That makes them the parts of the system most likely to still reflect the assumptions of whoever wrote them in an afternoon two years ago.
The output of a review isn't a score. It's a list of specific places where the system believes something it hasn't confirmed, ranked by how bad it is if that belief is wrong. Fixing them is usually not about adding more security technology — it's about moving verification closer to the point where trust is actually being extended. That's less exciting than it sounds, and it's most of the job.