What a code audit checks, and what it costs

In short: a useful code audit looks at structure, dependencies, tests where they matter, security exposure and the parts only one person understands, then ranks the findings and puts a cost on each. What it costs depends on the size of the codebase and the depth you ask for, so ask for a fixed price tied to a fixed scope and date. Below is what a good audit covers, with real findings from audits of my own projects.

What a code audit actually checks

• Structure. Are responsibilities separated so a change in one place does not break three others? Is the data model able to carry the next twelve months of product?
• Dependency health. Outdated or abandoned packages and known vulnerabilities. The package manager's audit command is the starting point, not the conclusion.
• Tests where it counts. Payments, permissions, data migration and anything that touches money. A high overall coverage figure can hide an untested core.
• Security exposure. Authentication, session handling, tenant isolation, file uploads, injection risks, secrets in the repository.
• Single points of knowledge. Modules only one developer has touched, found from the commit history.
• Delivery process. How code reaches production, and whether releases can be rolled back.

Findings from real audits

These come from internal security and quality audits I ran on my own projects. They show the kind of issue that matters, and the kind that tools alone do not report.

• A multi-tenant garage-management SaaS (ToliMaster). An audit found and fixed 14 documented bugs, including several serious cross-tenant data-leak risks: a query missing its tenant-ID filter could have exposed one garage's certificates to another. In a SaaS, that is the finding that ends a customer relationship.
• An agency site and CMS (Digi4). The audit covered SQL injection, the file-upload pipeline, XSS, CSRF and server-side rendering. No query was vulnerable to SQL injection even though the database connection allowed multiple statements, a risky pattern that had been neutralised. One high-severity issue was found: a mislabelled GIF or SVG upload could trigger stored XSS. It was fixed.
• An AI meeting summariser (MeetScribe). One high-severity issue, an API key committed to a frontend environment file, plus three medium and four low findings such as open CORS in development and a missing Content-Security-Policy.
• A household budget app (Household Budget). Two real vulnerabilities: a cross-household data-isolation gap through an unvalidated foreign key, and a refresh token with no revocation path.

Three of the four were access-control or secret-handling problems, not exotic exploits. That is typical: the highest-impact issues in early-stage products are rarely clever; they are missing checks.

What it costs, and what drives the price

I will not quote a market average, because audit prices vary widely and an unsourced number would mislead you. What determines the price is knowable:

• Size and age of the codebase, and how many separate applications (web, mobile, API) it contains.
• Depth. A scoped review of the highest-risk areas costs far less than a line-by-line review, and is usually what a decision needs.
• Output. A ranked risk matrix with remediation costed in developer-days takes more work than a list of warnings, and is the only version someone can act on.
• Independence. An audit by a vendor hoping to sell the fix is a proposal with a risk matrix attached.

Ask for a fixed price, a fixed date and a stated scope. My own audit is priced on the Delivery Risk Audit page.

Questions to ask any auditor

1. What exactly will I receive, and in what format?
2. Will you cost each finding in developer-days?
3. Do you intend to bid on the remediation?
4. Who will read the code: you, or a junior and a scanner?
5. What is explicitly not covered? Penetration testing, for example, is a separate engagement.

Security audit versus code audit versus due diligence

A security audit looks for exploitable weaknesses. A code audit looks at maintainability, structure and risk in the code itself. Technical due diligence includes both and adds people, process and ownership, because that is what a buyer or investor must decide on. The technical due diligence checklist shows the full scope.