A founder asked me last month what the actual difference was between a security scan and a security audit for her app. She had two quotes sitting in front of her, for the same app: one for a couple hundred dollars with same-day turnaround, one for a few thousand and a week of work. Both were called a security check. Nothing on either quote told her what she was actually paying for.
What does an automated scanner actually do?
A scanner reads your code and your configuration and compares them against a long list of known bad patterns. It doesn't run your app. It doesn't think about what your app is supposed to do. It asks one question, over and over: does this look like a mistake someone has already made before, somewhere else? An API key typed straight into a file. A software package with a publicly known vulnerability attached to its version number. A database or storage bucket left open to the internet. A missing setting that a thousand other projects also forgot. All of that is pattern matching, and a machine can do it in minutes, because the pattern is already documented somewhere.
What does that catch, in plain terms?
- Hardcoded API keys and passwords left sitting in code
- Software packages with known, published vulnerabilities
- Databases or file storage left open to anyone on the internet
- Missing or misconfigured access rules on a database
- Common web server misconfigurations
This genuinely matters. A good share of the exposed-data stories that made the rounds last year, apps built fast with AI tools, going live with wide-open databases, fall exactly into this category of mistake. A scan run before launch catches that kind of thing reliably, and it takes minutes.
So what does a scan miss?
Anything that requires understanding what your app is supposed to allow. A scanner has no concept of "only a paying customer should be able to do this" or "this user should never see that user's data." It can tell you the code doesn't match a known bad pattern. It cannot tell you the code enforces the rules you actually meant to set.
I remember a case from last year where an app let anyone register as a member of a private workspace, no invitation required, as long as they knew that workspace's public ID. Nothing about that code looked broken to a scanner. No leaked key, no outdated package, no open bucket. The logic itself was just wrong: a step that should have checked for permission simply didn't. That's not a pattern you catch by comparing files against a list. It's something you only find by actually trying the door.
What does a real audit do differently?
An audit means a person acts like an attacker inside your actual, running app. They log in as one user and try to view another user's data. They try to hit an endpoint meant for paid accounts using a free one. They trace every place your app trusts a value that came from the browser and ask what happens if that value gets changed. They aren't comparing your code to a list of known mistakes. They're testing what your app actually does against what it's supposed to allow.
That takes longer, because it has to. You can't automate a judgment call about whether a piece of business logic makes sense. Someone has to actually try it.
How do you tell which one you're being sold?
Ask three things before you pay for either one.
- Ask to see an example finding. A pattern flagged inside a file is a scan. A specific thing they were able to do inside your app, like viewing another account's data, is an audit.
- Ask how long it took. Minutes to a couple of hours is a scan, even a thorough one. A day or more of hands-on testing is an audit.
- Ask directly whether anyone tried to access data or actions that weren't supposed to be available to them. If the answer is no, you bought a scan, whatever it says on the invoice.
Both have a place. I'd run a scan before every single deploy. It's cheap, it's fast, and it catches the careless mistakes before they ship. What I wouldn't do is let a scan report be the reason I told a founder her app was safe to put real customer data into. The two things get sold under the same word, and that mismatch is exactly why so many of last year's exposed-data stories came out of apps that had, on paper, already "passed a security check." They'd passed the check for mistakes everyone already knew about. Nobody had tried the door.