What is a code audit? What a production review covers before launch

Key points

• A code audit answers one question: is this app safe to launch and to build on?
• Security comes first: who can sign in, who can see what, and where the secrets are kept.
• Account control matters as much as code. The company should own the repository, hosting, domain and store listings.
• Useful findings are ranked by severity, and each one comes with a fix.
• Public standards such as the OWASP Top 10 and OWASP ASVS make a better yardstick than the reviewer’s taste.
• A review is worth most before launch, before raising money, and before a new team takes over the code.

What a code audit is, and is not

A code audit, also called a code review or production review, is a reading of the whole app by someone outside the build: the code, the configuration, the database and the accounts it runs on. It usually comes up when a founder holds an app built by a freelancer, an agency or an AI tool, and needs to know whether it can carry real users, real data or an investment.

It is not a penetration test. NIST describes penetration testing as evaluators mimicking real-world attacks to find ways around a system’s security. An audit reads the app from the inside and finds problems an outside attack might never reach, such as missing backups or an account only a former contractor can open. The two complement each other. It is also not a rewrite plan or a critique of coding style.

A good review measures the app against public standards rather than the reviewer’s preferences. The OWASP Top 10 lists the most common web application risks. OWASP ASVS is a detailed set of security requirements for testing web apps, which OWASP says can also be used to judge how much trust to place in an application. NIST’s Secure Software Development Framework describes the development practices that reduce vulnerabilities in released software.

Security: what the reviewer checks

The OWASP Secrets Management Cheat Sheet notes that many organizations still keep secrets hard-coded in source code, which is why a reviewer searches the repository history, not only the current files. Web app security checklist walks through the full OWASP list, and Is AI-generated code safe? covers the risks that show up most in code written with AI tools.

Data, reliability and the rest

• Data. Backups exist and someone has restored one to prove it works. Changes to the database run as versioned migrations, not edits by hand. Personal data is collected only where it is needed, and can be exported or deleted when a user asks.
• Reliability. Errors are caught and reported instead of crashing the page, and someone is alerted when the app fails. Logs record sign-in failures, access denials and other security events, without passwords, tokens or keys; the OWASP Logging Cheat Sheet lists both what to record and what to leave out.
• Performance. Slow pages and queries are found, database queries use indexes, and paid APIs have rate limits and spending caps so one user cannot run up a bill.
• Code quality. Another engineer can find where things happen and change them safely. Duplicated logic, dead code and shortcuts are noted, with the ones that block future work marked. What is technical debt? explains why that matters later.
• Deploy and access. The company, not an individual, owns the repository, hosting, database, domain, email sending, payment and app store accounts. Former contributors have been removed, and releases come from the repository rather than from someone’s laptop.
• Tests. Sign-in, access rules and anything involving money have tests, and those tests run automatically before each release.

What you get back

The result should be a written report, not a call. A useful one has a short verdict at the top, a list of findings, a note of what is already sound, and an inventory of every account the app depends on with who holds it. Each finding says where the problem is, why it matters, how likely it is to be hit, and the fix.

Findings are ranked by severity. CVSS, the scoring standard maintained by FIRST, maps scores to low, medium, high and critical so teams can prioritize. A code audit usually uses the same four levels in plain words:

What to prepare

• Read access to the repository, given through the platform’s own invitation rather than a shared password.
• A list of environments and their addresses: live, staging and anything else that exists.
• A test account for each user role, on a non-live environment if there is one.
• Every account the app depends on and who holds it: hosting, database, domain, email, payments, analytics and app stores.
• A short description of what the app does, who uses it and what data it stores.
• Known problems, past incidents and any earlier review.

Never send live keys or passwords in chat or email. If the reviewer needs access to a service, invite them with their own login and remove it afterwards.

How to read the result

1. Read the critical and high findings first. They decide whether you can launch.
2. Look for root causes. Ten findings that all come from access not being checked on the server are one fix, not ten.
3. Separate code problems from account problems. Moving a domain or a repository into the company’s name is often the quickest, most important fix in the report.
4. Ask whoever built the app to respond to each finding. Their answers show whether they can carry it forward.
5. Decide what to fix and what to rebuild. Rewrite vs refactor helps with that choice; most apps need fixing, not replacing.
6. Have the critical and high findings checked again once they are fixed.

A long report does not mean a bad app. A report with no findings at all usually means the review was shallow.

When a review is worth it

• Before launch, when real users or real data are about to arrive.
• Before raising money or selling the company, when investors or buyers will ask who checked the code.
• When taking over an app from a freelancer, an agency or an AI tool, before the new team starts changing it.
• When a business customer sends a security questionnaire you cannot answer.
• After an incident, or a near miss, that nobody can fully explain.

It is not worth it for a throwaway prototype with no real data; spend that effort on users instead. If the app came from an AI builder, Vibe coding to production lists the checks you can run yourself first.

When BYD Tech takes over an existing app in web app development, the first step is a written review like this one. From then on the code lives in the client’s GitHub, and AI drafts while a named engineer reviews every change.