What to expect from an app security audit

Most founders who contact me about a security audit are not sure what they are asking for. They know they shipped fast and want to feel confident about what is in production, but "security audit" is a broad term that can mean a 30-minute automated scan or a six-week penetration test engagement. Here is what a focused app security review actually involves.

The scoping call

Everything starts with a 30-minute call. The goal is to understand the app: what it does, who uses it, what stack it runs on, what data it handles, and what the founder is most concerned about. That conversation shapes the scope. A single-page web app with no sensitive data is a very different engagement than a healthcare app handling PHI or a fintech product handling payments.

The scoping call also establishes access. I need read-only access to the codebase and, where relevant, to the infrastructure configuration. I do not need production credentials, live API keys, or access to customer data. Any data-sharing method is agreed in writing before anything is shared.

What gets reviewed

A focused app security review covers the layers where most real-world vulnerabilities live. Authentication and session management: how users log in, how sessions are managed, how tokens are validated, and how account recovery works. Authorization: whether data operations check that the requesting user has permission for that specific resource. API design: how endpoints are structured, what they accept, how they validate inputs, and whether rate limiting is present. Data handling: what gets stored, where, in what form, and who can access it. Dependency risk: known vulnerabilities in third-party packages and libraries. Secrets management: whether credentials are stored and referenced safely.

What the output looks like

The deliverable is a written report, not a list of CVEs. For each finding: what was found, where it is in the code, why it matters in practical terms, and specifically what to do to fix it. Findings are prioritized by actual risk, not by theoretical severity. A critical CVSS score on a dependency you are not calling is less urgent than a broken authorization check on an endpoint real users hit every day.

The report also includes a risk prioritization: here are the three things to fix first, and here is why. Most teams can work through the highest-priority findings in a sprint or two.

What happens after

The report is yours. Some founders fix everything themselves. Some want a follow-up call to walk through the findings. Some want ongoing advisory while their team works through the remediation. All of those are options; none of them are required.

The goal of the engagement is that you leave knowing what is in your app, what the actual risks are, and what to prioritize. Not a score, not a certification, not a checkbox. Practical information you can use.