What Is a Code Audit? 2026 Process, Tools & Cost

Why Fora Soft wrote this playbook

We’ve audited other people’s code since 2005: for acquirers running due diligence, founders who inherited a mess, VCs pricing technical risk before a Series A, and for ourselves before we take a project over as a custom software development partner. Across 250+ shipped projects we’ve read decade-old PHP monoliths, modern Swift apps, video pipelines running at scale, and a growing pile of AI-generated prototypes. This is the checklist we actually use, plus the questions buyers and CTOs ask us most.

That range matters, because a code audit is only as good as the reviewer’s pattern library. When we audit a real-time video stack we’ve already shipped that architecture on BrainCert (500M+ classroom minutes) and VALT (770+ US organizations, HIPAA); when the codebase is a healthcare product we’ve been through the same compliance redlines on CirrusMED. Where we quote a price band below, it’s our real independent code audit band, not a market average. We won’t commit to a fixed number without scoping the repo first.

What is a code audit

A code audit is a structured, independent review of a codebase that produces a written verdict on its quality, security, performance and maintainability — with severity-ranked findings, reproducible examples, and a prioritized remediation plan. It answers one question with evidence: is this code safe to ship, buy, or scale? A good audit reads in five minutes for a non-technical sponsor and in fifty pages for the engineers who’ll act on it.

It’s a snapshot, not a refactor. The auditor doesn’t rewrite your code; they photograph it at a frozen commit, grade it, and tell you where the risk sits and what it costs to fix. The point is a decision (close the deal, release the round, green-light the migration) backed by evidence instead of a gut feel. Poor software quality is expensive at the industry level too: the CISQ 2022 report put the annual US cost at $2.41 trillion, with roughly $1.52 trillion of that sitting in accumulated technical debt. An audit is how you find out how much of that bill is hiding in your repo.

Code audit vs code review vs penetration test

A code review is continuous and internal: your own engineers reading each other’s pull requests. A code audit is a point-in-time, independent review of the whole codebase that ends in a report. A penetration test attacks the running system from the outside and never reads your source. People conflate the three constantly, and buying the wrong one wastes money. You want reviews always, an audit at milestones, and a pen test when you’re selling to enterprise or chasing SOC 2.

They stack rather than compete. Many of our clients commission an audit and a pen test together before a funding round: the audit tells the board whether the foundation is sound, the pen test tells them whether today’s deployment can be broken into. If you only have budget for one and the trigger is “we’re about to buy this company,” start with the audit.

When you should commission a code audit

There are seven moments where the return on an audit is almost always positive. Each one shares a shape: someone is about to make an expensive, hard-to-reverse decision on code they don’t fully understand.

1. Before an acquisition. You’re signing an LOI and the target’s codebase is the asset. An audit prices the technical risk before it becomes your liability.

2. Before a funding round on inherited code. You raised, or you’re about to, on a product a previous team built. Investors increasingly ask for an independent read.

3. When the bug rate is climbing. Velocity is dropping, every release breaks something, and nobody can point to why. That’s usually structural, and covered in too many bugs in a project.

4. At a team hand-off. The original developers are leaving, or you’re moving the work in-house. Freeze an objective baseline before the knowledge walks out the door.

5. Before you scale. The product works at 1,000 users and you’re about to sell to a client with 100,000. An audit finds the parts that won’t survive the load.

6. After an incident. A breach, a data-loss event, an outage — you need a root cause and a hardening plan, not just a patch.

7. When AI wrote most of it. A prototype came out of Lovable, Bolt, v0 or Cursor and now real users depend on it. That case has its own section below.

The seven dimensions we score on

Every audit produces a 1–5 score per dimension, each backed by evidence. The seven below are the same scorecard we hand our auditors. Scoring them separately stops a clean-looking codebase from hiding an architectural problem: formatting can be a 5 while architecture is a 2, and the sponsor needs to see both.

Figure 1. An example scorecard. Each dimension is graded 1–5 with evidence, so a tidy surface can’t hide a weak foundation.

Cyclomatic complexity, the maintainability metric here, has been around since Thomas McCabe defined it in 1976: it counts the independent paths through a function, and functions that score high are the ones that break when someone touches them. We flag them, but we don’t stop at the number. A high score on a stable, well-tested payment module is a different risk from the same score on code that changes weekly.

How to conduct a code audit, step by step

An audit runs in eight steps. The durations below are per engagement, not per week, and they compress or stretch with codebase size. The order matters: scope first so nobody argues about coverage later, freeze a commit so every finding is reproducible, run the machines before the humans so senior time goes to judgement rather than grunt work.

Figure 2. The eight-step audit. Automated sweeps run first so senior review spends its time on architecture, not linting.

1. Scoping and statement of work (1–2 days). Which languages, which services, which risks matter most, what “done” means, and who reads the report. Output: a written scope with a fixed price.

2. Repository onboarding (0.5 day). Clone, build, run the tests, snapshot CI, and freeze a commit hash so every finding points at code we can both see.

3. Automated sweep (1–3 days). SAST, SCA, secret and container scanning across the codebase. Every machine finding is triaged by a human before it reaches the report — scanners cry wolf, and an audit full of false positives is worse than none.

4. Senior architectural review (3–7 days). An engineer reads the code by feature path, draws the data flow, and checks the boundaries the scanners can’t see. This is where the expensive findings come from.

5. Security deep-dive (1–3 days). Threat-model walkthrough, manual review of authentication, authorization, crypto and IAM, dependency CVEs, and secrets in git history.

6. Performance check (1–2 days). Profiling on representative traffic, query-plan review, and the top three latency or cost hotspots named with numbers.

7. Report writing (2–3 days). Findings, severity, reproduction, recommended fix, a scorecard, and a one-page summary a non-engineer can act on.

8. Walk-through call (1 hour). We present the report live, work through the top findings, and answer questions. The recording ships as part of the deliverable.

The 2026 tool stack: SAST, SCA and the rest

No single tool audits a codebase. A real audit layers static analysis, dependency scanning, secret detection and dynamic testing under a senior engineer who reads the output and the source. The automated layers do the first pass fast and cheap; the human catches what pattern-matchers structurally cannot: the architectural and business-logic faults that only make sense once you understand what the product is meant to do.

Figure 3. The layered stack. Each automated layer catches a different class of issue; senior review sits on top of all of them.

SonarQube stays the workhorse for combined quality and security with a quality gate teams can enforce in CI. Semgrep wins on speed and custom rules. CodeQL goes deepest on data-flow analysis if you’re GitHub-native and can write queries. Snyk covers dependency and license risk. The pattern most mature teams land on is a fast linter for instant feedback, a quality gate in CI, and a dedicated security scanner — then a human on top.

You can run the open-source pieces yourself — SonarQube, Semgrep, Snyk and gitleaks are all approachable. The work that needs an outside auditor is the senior architectural review and the report a board or buyer will trust. If your product is a real-time media stack, the architecture patterns we check are the same ones in our real-time video engineering guide.

Security: auditing against OWASP Top 10:2025

Security is where an audit earns its fee, and it’s where most competing guides are out of date. The OWASP Top 10:2025 landed in January 2026, the first refresh since 2021, and it changed the checklist. If a “2026” audit still grades you against the 2021 list, it’s auditing last decade’s threats. Here’s the current top ten we score against:

A01 Broken Access Control — still number one; now absorbs server-side request forgery. A02 Security Misconfiguration — moved up as cloud defaults bite. A03 Software Supply Chain Failures — new for 2025, expanded from the old Vulnerable and Outdated Components category and reflecting attacks like the 2024 xz-utils backdoor. A04 Cryptographic Failures. A05 Injection. A06 Insecure Design. A07 Authentication Failures. A08 Software or Data Integrity Failures. A09 Security Logging and Alerting Failures. A10 Mishandling of Exceptional Conditions — also new, covering the error paths nobody tests.

The two additions are the tell. A03 pushes an audit past your own code into your dependencies and build pipeline: the software bill of materials, the CI secrets, the packages you never chose but inherited. A10 targets the exception handling that looks fine until production sends it something unexpected. We map each security finding to its OWASP category and, for the exploitable ones, a CVSS v4.0 score, so the severity isn’t our opinion; it’s the same scale every security team already uses.

The severity model and how we triage findings

A finding without a severity is noise. Every issue in the report gets one of five levels and a matching SLA, so your team knows what to fix this week and what can wait a quarter. We walk each finding down a single question trunk and take the first Yes. That keeps triage consistent across auditors instead of depending on who wrote it up.

Figure 4. Severity triage. The first Yes down the trunk sets the level, and the level sets the fix deadline.

Blockers are what kill or reprice deals. On diligence engagements they’re the findings that move a valuation, so we surface them on page one and never bury them in an appendix. Everything below Blocker is a plan, not an alarm: a backlog your team can burn down in priority order.

What the audit deliverable looks like

You get artifacts, not just a PDF. A Fora Soft audit hands over six things, and we give you all of them so the work outlives the engagement:

1. Executive summary. One page: the verdict, the top risks, the headline number. Written for the CEO or buyer who has five minutes.

2. Scorecard. The seven dimensions, each graded 1–5 with a sentence of evidence, so trend-tracking across audits is trivial.

3. Findings register. Every issue with severity, location, evidence, reproduction steps and a recommended fix. This is the part your engineers work from.

4. Remediation plan. Findings sorted by severity and effort, so “what do we fix first” has an answer before the call ends.

5. Evidence appendix. Tool outputs, dependency reports and the frozen commit hash — the material that holds up under data-room scrutiny.

6. Walk-through recording. The live session where we present it, so people who weren’t on the call still get the reasoning, not just the document.

What a code audit costs: a worked example

Price scales with codebase size and the depth of review, and the honest answer is a band, not a number, until we’ve scoped the repo. Below are our 2026 bands against the wider market. The third-party audit market runs roughly $35k–$95k at boutique specialists and $50k–$250k at Big Four advisory practices; UK engagements land around £20k–£100k. Our bands sit under that because Agent Engineering compresses the mechanical passes. We don’t skip the senior review; we just spend less human time getting to it.

Figure 5. Cost by size. Our $2k–$60k bands sit well below the $35k–$250k specialist and Big-Four market.

Work an example. A mid-size SaaS at ~150k lines across five services scopes to about 12 working days: two on scoping and onboarding, three on the automated sweep and its triage, five on senior architectural and security review, two on the report. At our blended rate that lands near the middle of the $8k–$25k band, about $14k, against $40k–$95k for the same scope at a specialist firm. If the audit finds one Blocker that would have surfaced after the acquisition closed, it has paid for itself many times over.

Auditing AI- and Lovable-generated codebases

Vibe-coded prototypes — built in Lovable, Bolt, v0, Cursor or Cline — have a recognizable shape. Clean-looking React components on the surface; underneath, hard-coded API keys, fragile error handling, missing tests, and an auth layer that looks correct and falls over under a five-minute review. We see them weekly, and the failure patterns are consistent enough that we audit them against a tuned checklist.

What we check first: is authorization enforced on the server, or only hidden in the UI? Are secrets in the client bundle or the git history? Do the dependencies carry known CVEs the generator pulled in blind? Is there a single test? These map straight onto the new OWASP A03 Software Supply Chain Failures and the old A01 Broken Access Control — AI generators are very good at producing plausible code and very bad at knowing what should never leave the server. For the full pattern set, see our Lovable app bugs and fix-cost guide, and for how we fold AI into our own delivery, AI in the software development process and AI in software architecture design.

Internal review vs external audit

You can review code with your own team, and you should — continuously. But there are moments where internal review structurally can’t deliver what you need, because the value is the independence. A team can’t objectively grade the architecture it chose, and a board won’t weight a self-assessment the way it weights an outside verdict.

Mini case: a two-week diligence audit

Audits are confidential, so the details here are anonymized and the numbers rounded, but the shape is a real, representative engagement. Situation. A US acquirer was ready to sign a mid-seven-figure LOI for a Series-A SaaS company. The target had a small overseas team and three years of code, and the buyer wanted an independent verdict before committing.

The 12-day plan. Days 1–2, scoping and repo onboarding. Days 3–5, the automated sweep across SAST, SCA and secrets. Days 6–9, senior architectural review across the four core services. Days 10–11, report writing. Day 12, the walk-through call. One auditor, one security specialist, one frozen commit.

Outcome. Three Blockers (plaintext production keys in git history, broken multi-tenant isolation in the analytics service, no tested backup-restore path), seven Criticals including an injection exposure and a weak token validator, and 22 Majors. The buyer repriced the offer to fund remediation, added a warranty clause covering the Blockers, and closed two weeks later with eyes open. The audit fee was a rounding error against what the Blockers would have cost post-close. Want a similar read before you sign? book a 30-minute call and we’ll scope it.

A decision framework in five questions

Before you commission anything, answer these five. They set the scope, the price, and who does the reading.

Q1. Who reads the report? A CEO wants the executive summary first. A board wants the scorecard with a peer comparison. An auditor wants findings mapped to compliance controls. Scope the deliverable to the reader.

Q2. What’s the trigger? An acquisition means broad coverage, security and IP heavy. A Series A leans architecture and scalability. A post-incident audit is root-cause and hardening first.

Q3. How big is the codebase? Under 30k lines is one auditor for about a week and a half. 30k–200k is two auditors and three weeks. Past 200k it’s a pod and four to six weeks.

Q4. Do you need a pen test too? Selling to enterprise or moving toward SOC 2? Bundle it. Otherwise the audit gets you most of the way at a fraction of the cost.

Q5. Can the result kill the deal? Be honest with your sponsor on day one. An auditor who optimizes for a passing report is worthless within a year — you’re paying for the truth, not a rubber stamp.

Five pitfalls we see every quarter

1. Tools-only audits. A SonarQube export is not an audit. Without senior judgement you miss every architectural iceberg, because scanners don’t know what your product is supposed to do.

2. Findings you can’t reproduce. Every finding must compile down to a file, a line, evidence and a fix path. “Generally insecure” helps nobody and erodes trust in the whole report.

3. Auditing the team, not the code. Reviewers who inherit the incumbent team’s narrative stop seeing clearly. They should walk into the code cold and let it speak.

4. Skipping the executive summary. The decision-maker skims. If page one doesn’t land the verdict in plain language, the fifty pages behind it die unread.

5. Treating it as one-and-done. Codebases drift. Audit full annually, lite quarterly, and track remediation across cycles — a finding that reopens next quarter is a process problem, not a code problem.

KPIs that follow up on an audit

An audit that doesn’t change a number was theatre. Track three buckets after the report lands, so you can prove the remediation actually moved the needle.

Closure KPIs. Blockers and Criticals fixed within their SLA, percentage of Majors closed within the quarter, and mean time-to-close per severity. This is the direct read on whether the report turned into action.

Quality KPIs. The SonarQube quality-gate trend, open dependency CVE count, test coverage on the risk paths, and P95 latency on the hot ones. These tell you the codebase is actually getting healthier, not just quieter.

Delivery KPIs. The four DORA metrics — deployment frequency, lead time for changes, change failure rate, and failed-deployment recovery time. Elite teams in the 2024 report keep change failure rate at or below 5% and recover in under an hour; a good audit should push you toward that, not away from it.

When you should not commission a code audit

Three situations where the spend isn’t justified, and we’ll tell you so rather than take the work. First, a working prototype under about 5k lines where the team is iterating weekly — the codebase will look nothing like itself in a quarter, so you’d be auditing a draft. Second, a stable product with a strong internal review culture and a recent SOC 2 report — you already hold the evidence an audit would produce. Third, when leadership won’t fund any remediation: an audit no one will act on becomes a list of grievances and a morale problem. In the first case, keep shipping; the what to do with legacy code playbook and a solid review culture matter more. Honesty about when not to buy is part of why clients trust the verdict when we do recommend one.

Where audits go next: agent-assisted reviews

Two shifts are reshaping the practice. Continuous audits — pipelines that run a senior-grade review on every pull request using LLM agents under a human’s supervision — are starting to replace point-in-time reviews for teams that can afford the tooling. And AI-on-AI scrutiny is now standard for any product that ships LLM features: reviewers spend real cycles on prompt injection, model supply-chain risk, and data exfiltration through embeddings or eval logs. Both are already part of how we work; the AI in the software development process guide covers the broader delivery picture. The constant underneath the change is the same as it was in 2005: a machine flags the pattern, a senior decides what it means.

FAQ

How long does a code audit take?

An MVP-sized codebase takes 1–1.5 weeks; a typical SaaS 2–3 weeks; a large multi-service platform 4–6 weeks. Agent Engineering compresses the mechanical passes, so our timelines run shorter than traditional audit teams for the same scope.

How much does a code audit cost?

Our 2026 bands are $2k–$8k for an MVP, $8k–$25k for a mid-size SaaS, and $25k–$60k for an enterprise platform. The wider market runs $35k–$95k at specialists and up to $250k+ at Big Four firms. We scope the repo before quoting a fixed price.

What’s the difference between a code audit and a code review?

A code review is continuous and internal — your team reading each pull request. A code audit is a point-in-time, independent review of the whole codebase that ends in a written report with severity-ranked findings. You want both, at different cadences.

Is a code audit the same as a penetration test?

No. A code audit reads the source for quality, security and architecture from the inside. A pen test attacks the running system from the outside and never sees your code. They’re complementary; enterprise and SOC 2 buyers often need both.

Do I need to give you full repository access?

Read-only access to a frozen branch is enough. We sign an NDA, work in an isolated environment, and return the artifacts — we don’t keep your code.

Can you audit AI-generated code from Cursor or Lovable?

Yes, we do it weekly. The failure patterns are predictable — client-side auth, exposed keys, dependency CVEs, zero tests — and our checklist is tuned for them.

Will the report be shareable with investors or acquirers?

Yes. We structure the deliverable for a data room: an executive summary, a clear scope statement, and an evidence appendix that holds up under diligence scrutiny.

Do you fix what you find?

We can, as a separate engagement, or hand the report to your team. To keep the audit independent, the original auditors don’t implement; a different Fora Soft pod handles the troubleshooting and optimization if you want us to do both.

What to read next

Ready to commission an audit that holds up in a data room?

A code audit answers a yes/no question with evidence: is this codebase safe to ship, buy or scale? Commission one before you sign, before you raise, before you migrate, and after you’ve been bitten. Score the seven dimensions separately so a tidy surface can’t hide a weak foundation, grade security against the current OWASP Top 10:2025 rather than the 2021 list, blend tools with senior judgement, and demand a deliverable a buyer can read in five minutes and an engineer can act on by day one.

If you want a partner who’s run audits across acquisitions, funding rounds, AI-generated codebases and post-incident reviews, and who’ll tell you when not to bother, talk to us. We quote in about 48 hours and start within a week.