What a code audit actually checks
The short answer
A code audit answers four questions: is it secure, is it correct, could someone else maintain it, and does it match what was contracted. Each is answered with specific evidence from the repository rather than an opinion, and each finding carries a remediation estimate in hours so the conclusion is negotiable rather than emotional.
Why you would commission one
Three situations account for almost every audit we run. A final invoice is due and the buyer cannot judge whether the work is finished. An acquisition is being considered and the seller's technical claims are unverified. Or a team has inherited a codebase and cannot estimate anything in it.
All three share a shape: somebody is about to commit money on the strength of a technical claim they cannot evaluate. The audit's job is to convert that claim into evidence.
Question one: is it secure
This section is non-negotiable, and it is where most audits find their must-fix items.
- Authentication: how sessions are issued, stored, expired and revoked, and whether passwords are hashed with a current algorithm.
- Authorization: whether every endpoint checks permission server-side, derived from the session rather than from a value the client supplied.
- Object-level access: whether changing an ID in a request returns data belonging to someone else.
- Secrets: whether keys are in the repository history, in the client bundle, or in a configuration file that shipped.
- Input handling: injection, unsafe rendering, and file uploads that never validate what they receive.
- Dependencies: known vulnerabilities, unmaintained packages, and how far behind the lock file has drifted.
- Data exposure: what an ordinary authenticated user can reach that they should not, and what an unauthenticated one can.
Question two: is it correct
Secure code that computes the wrong answer is still broken. This section looks for the failures that show up as silent data damage rather than as an error message.
- Schema integrity: foreign keys, unique and not-null constraints, and whether the database refuses states the code assumes cannot happen.
- Transactions: whether operations that must succeed or fail together actually do.
- Idempotency: whether a webhook or payment callback delivered twice causes something to happen twice.
- Error handling: whether failures are surfaced and retried, or swallowed and forgotten.
- Money and dates: rounding, currency handling, time zones and daylight-saving arithmetic, which is where quiet financial bugs live.
- Test coverage on the logic that would cost real money if it were wrong, which is a different question from overall coverage percentage.
Question three: could someone else maintain it
This is the one buyers underestimate and the one that determines what the asset is actually worth. A working product nobody else can safely change is a liability with a nice interface.
- Could a competent stranger clone the repository, run it locally, and understand it within a day?
- Is there a migration path for the database, or does the schema exist only in a live console?
- Are there environments, or is production the only one?
- Is deployment automated and reversible, or a documented ritual nobody has rehearsed?
- Do backups exist, and has anyone ever restored one?
- Is the structure consistent, or does each feature use a different pattern because it was written on a different day?
Question four: does it match what was contracted
The most direct question and the one that decides invoices. We take the specification, statement of work, or the demo that was signed off, and check it feature by feature against what exists in the repository.
The interesting findings are rarely missing features, which the buyer has usually already noticed. They are features that exist as a working interface with nothing behind it, and features that work only for the exact input used in the demo.
What the report gives you
| Section | What it contains |
|---|---|
| Verdict | Two paragraphs a non-technical reader can repeat accurately to someone else |
| Must-fix | Findings unsafe to ship or operate, each with file, evidence and hours |
| Should-fix | Findings that will cost money later, with the timescale on which they bite |
| Cosmetic | Everything real but not urgent, so nobody can claim it was hidden |
| Remediation estimate | Hours and money per band, so the negotiation has numbers in it |
| Maintainability opinion | Whether a new team could take this over, and at what cost |
Every finding cites the file and the specific evidence. A finding a developer cannot verify for themselves is an opinion, and opinions do not settle invoices.
What you can check before hiring anyone
- 01Change an ID in an API request to one belonging to another account and see whether data comes back.
- 02Search the client bundle for your provider key prefixes.
- 03Ask for the migration files. If there are none, the schema lives in one place and cannot be reproduced.
- 04Ask when a backup was last restored, not whether backups exist.
- 05Ask how the last deployment would have been reversed.
- 06Clone the repository onto a clean machine and try to run it using only the written instructions.
Six questions, no engineering degree required. If several land badly, a full audit will find more, but you already have enough to hold a serious conversation.