In its 2024 Open Source Security and Risk Analysis report, Synopsys audited 1,067 commercial codebases. 84% contained at least one known open-source vulnerability, and 74% contained high-risk ones. Those numbers matter to anyone shopping for code audit services, because they tell you how the engagement ends before it starts: the auditor will find problems. Nearly everyone does. Finding problems is the cheapest part of the job, and a lot of the market prices it like the whole job.
Here is my position after eleven years of inheriting, rescuing and extending other people's codebases. A code audit is worth paying for only when it ends in a decision with a price attached: keep the codebase, refactor specific parts of it, rewrite it, or stop. An audit that ends in a long list of findings sorted by severity has told you that software is imperfect, which you knew when you signed the order. The four numbers below explain why, and what a decision-grade audit looks like in practice.
Number One: 84% Means Findings Are a Commodity
The usual view is that an audit's value grows with the number of issues it turns up. The Synopsys data makes the problem with that view plain. If 84% of commercial codebases carry known vulnerabilities from their dependencies alone, a report that lists them is showing you what a dependency scanner shows anyone in an afternoon. Run SonarQube, Snyk or a plain composer or npm audit over a five-year-old Laravel and React application and you'll get findings in the hundreds, sometimes the thousands. Age, dependency count and whether anyone enforced linting from the start decide which. That output costs almost nothing to produce.
A severity label doesn't tell you what the finding costs you either. A 'critical' CVE in a library called only from an admin export script behind VPN access is a Tuesday afternoon. A 'medium' finding in how the payment module handles idempotency can double-charge customers during a traffic spike. A scanner ranks those two the wrong way round, because it can't see how the code is used. Only a person who reads the code can, and that brings us to the real constraint.
Number Two: 500 Lines an Hour Means the Sample Is the Product
The largest published study of code review, run by SmartBear with a Cisco team across roughly 2,500 reviews and 3.2 million lines of code, found that defect detection drops sharply beyond 200 to 400 lines in one sitting, and that reviewers moving faster than about 500 lines an hour miss much more. Apply that ceiling to an audit. A 200,000-line codebase read carefully at 500 lines an hour takes 400 hours: ten weeks of one senior engineer doing nothing but reading, before a word of the report is written.
No audit costs that much, so every audit is a sample. A two-week engagement with one or two senior engineers reads perhaps 10 to 20 percent of a mid-sized codebase properly and skims the rest with tools. That's fine, as long as you see the choice of sample for what it is: the product you're buying. The reading hours need to go to the places where failure costs money, which are authentication and permissions, payment and billing flows, the data model and its migrations, the deployment pipeline, and the module the current team avoids touching. An auditor who spreads those hours evenly across the repository has produced an average, and averages don't find the thing that breaks the business.
When you evaluate an audit proposal, the most useful question is simple: which 20 percent will you read, and why? A firm that answers with a list tied to your business model has already started the audit. A firm that answers with its tooling hasn't.
Number Three: 17.3 Hours a Week Means the Unit Is Time, Not Severity
Stripe's Developer Coefficient survey found that developers spend an average of 17.3 hours a week on maintenance work such as debugging and refactoring. That's over 40 percent of a working week. CISQ's 2022 report put the accumulated technical debt in US software at roughly $1.52 trillion, inside a total cost of poor software quality of about $2.41 trillion. Those are macro figures, but the lesson for a single company is concrete. Technical debt is paid in engineering hours, every sprint, as lost velocity. So an audit that reports in severity levels is using a unit nobody at the budget table uses.
A decision-grade audit turns findings into time. This area costs the team about a day a sprint in workarounds. Fixing it costs roughly three engineer-weeks. It blocks the multi-currency feature on next quarter's roadmap. A founder or CFO can weigh that sentence against a hiring plan. They can't do the same with 'fourteen high-severity issues'.
The Three Questions the Report Has to Answer
First: can this codebase carry the next twelve months of the roadmap, and if it can't, where exactly does it give way? Second: what fails first under realistic load, team growth or a security review, and roughly when? Third: what's the cheapest route to a codebase that does carry the roadmap, costed in engineering weeks and set out as keep, refactor or rewrite, module by module? An audit that answers those three questions is worth several times its fee. One that answers none of them, however long, is an inventory.
Number Four: Ten Re-Estimates Means the Auditor Has to Own the Estimate
The best audits I've seen came from engineers who would have to estimate, and often deliver, the fix. That isn't a sales argument. It's about incentives and information. An auditor with no stake in remediation gains by being thorough about problems and vague about costs. An engineer who has to put a number on the fix has to work out which problems actually block delivery, and that's the judgment you're paying for.
Meal4U is the clearest example from our own work. The client came to us with a stalled build after the previous team failed to deliver. The instinctive request in that situation is a code audit: tell us what's wrong with what we have. We spent a week taking the scope apart instead, and re-estimated the product about ten times, cutting 30 to 50 percent on each pass until we reached the smallest product that could ship. The key finding was that the scope, as specified, could not be delivered at the budget available, whatever state the code was in. A findings-only audit would have catalogued the existing code accurately and left the actual blocker untouched. That week ended in a decision because the people doing the assessment had to stand behind the number at the end of it.
Inherited codebases on a deadline make the same point. When we took over a one-year-old codebase for Nautical Commerce and delivered against a 90-day go-live marketplace model, the only assessment that mattered was which parts of the existing code could carry that date and which couldn't. Under a fixed clock, a code assessment is a triage exercise or it's useless.
When Code Audit Services Are Worth Buying
The one-off audit has a proper place, and it's narrower than the market suggests. It pays for itself at points of inheritance. You're acquiring a company or investing in one, and technical due diligence decides the price. You're changing vendors and need to know what you're taking on before the new team commits to a date. Velocity has collapsed and nobody inside can say why. Or a previous build has stalled and you need a keep-or-rewrite call before spending more. At each of those moments a decision is waiting, and a senior read of the riskiest 20 percent of the code, priced in weeks, is the cheapest way to make it well.
The recurring annual audit, bought as general reassurance on code the same team keeps shipping, is where I'd spend the least. The SmartBear numbers point the other way: review works best in small batches of a few hundred lines, while the code is fresh and the author is still around to explain it. At EltexSoft every pull request is reviewed by at least one other senior engineer before it merges. That's a continuous audit at the batch size where review catches the most, and it makes a yearly retrospective read largely redundant. If your codebase has that discipline, an outside audit is confirming what's already known. If it doesn't, the cheaper fix is the review process, with the audit used once to size the backlog the missing process left behind.
So here's the test for any proposal. It names the sample and why. It reports in engineering time as well as severity. It ends in a keep, refactor or rewrite call for each major area. And the people writing it would put their name on the remediation estimate. A proposal that meets all four is buying a decision. One that meets none is buying a scan with a cover page.
This is how we structure these engagements. Technical due diligence and legacy rescue run through our CTO-as-a-Service work or begin with a free discovery week. In that week, senior engineers read the parts of your codebase that carry your roadmap and return a costed keep, refactor or rewrite recommendation. If the recommendation holds up, the next step is a paid pilot with no lock-in, in which the same engineers fix the first item on the list in 2-week sprints, so their estimate gets tested against real delivery before you commit further. The concrete first step is repository access and your roadmap for the next two quarters, and the audit starts from there.
Last updated November 3, 2026