Code Audit Services for the Codebase You Just Inherited
Contract staff engineers read the code, then hand you a findings register priced in engineer-weeks. Not an opinion. A scope.
A code audit is an independent read of a codebase that produces a written findings register, each finding rated for severity and sized in engineer-weeks. KORE1 staffs contract staff engineers, security engineers and architects to run them in four to six weeks.
Last updated: October 8, 2026
- This page
- A code audit bought by the company that owns the code, and the priced remediation scope it turns into.
- Covered elsewhere
- Auditing a target before a deal closes is technical due diligence for M&A. Diagnosing a slow team rather than a codebase is the free engineering velocity assessment. A project already on fire is project rescue staffing.
Three calls bring people here, and they are always the same three. A new VP of Engineering has inherited forty thousand commits she didn’t write and is being asked for a plan by the board. An agency has handed a product back and nobody internal can say what arrived. Or somebody has proposed a rewrite, the number attached to it is large, and the leadership team has no way to argue with it.
All three are the same problem wearing different clothes. A decision is due and the evidence doesn’t exist. Every time.
Our project staffing desk, part of KORE1’s IT staffing services, puts senior engineers on that reading work for the weeks it takes. They’re on our W-2 through contract staffing, they have no platform to sell you and no implementation to win, and the register they write belongs to you the day they roll off.
What a Code Audit Actually Reads
A score out of ten is not an audit. Nowhere close. Neither is a static analysis report, though one usually gets attached to the invoice. The findings that change a decision come from six places, and a tool can only see two of them.
- The boundary between tenants, roles and accountsWho can read what, and whether the code enforces it or merely never gets asked. Broken access control has been the number one entry in the OWASP Top 10 since 2021 and held the position in the 2025 revision, and improper access control was a new arrival in the 2025 CWE Top 25. It is also the single hardest thing to find with a scanner, because nothing about the code looks wrong. The check is simply absent.
- What you depend on, and how old it isNot the lock file. The transitive graph underneath it. Black Duck’s audit team found 92 percent of the codebases they examined carried components four or more years out of date, and 93 percent carried components nobody had touched in two.
- Licenses, which is the one nobody asks for and everybody needsSixty-eight percent of audited codebases carry a license conflict. Almost nobody checks. That matters most on exactly the engagement this page is about, because an agency that pulled in a copyleft component three years ago has just handed you the obligation along with the code.
- Where the money logic lives, and whether anything tests itBilling, pricing, entitlements, tax. We look for the same rule implemented twice, which is the most common thing we find and the most expensive thing to leave alone, because the two copies have usually already drifted and somebody in finance is reconciling the difference by hand every month without having told anyone it is a problem. Quietly.
- What happens when it breaks at 3amLogs, correlation, alerts, runbooks. A codebase that cannot be debugged in production is a staffing problem dressed as a code problem, because it means only the two people who wrote it can operate it. Two people.
- The parts everyone steps aroundAsk four engineers which file they dread. You will get one answer. That file is the audit.
Tooling does real work here and we use it. Dependency scanning, secret scanning in git history, coverage, complexity. It is maybe a third of the engagement, and it is the third that produces the longest list and the fewest decisions. Useful. Rarely decisive.
The other two thirds are closer to NIST’s Secure Software Development Framework, SP 800-218, which sorts practice into preparing the organization, protecting the software, producing well-secured software, and responding to vulnerabilities. A scanner speaks to one of those four. A reader speaks to all of them, which is the entire reason this costs what it costs.
Twelve Findings. Five of Them Get Priced.
This is what the deliverable looks like once the reading stops. Findings sorted by effort, each sized in engineer-weeks, with a running total down the right. One rule crosses the listing where the priced scope ends. Everything under it is written down, accepted, and deliberately not fixed.
- Blue edge, the finding is in the priced scope
- No edge, accepted and documented, not fixed
- The crossing, where the priced scope stops
- Orange, the single largest finding
- 31
- engineer-weeks to fix what actually blocks you
- 74
- engineer-weeks to fix every single thing found
- 94
- engineer-weeks quoted for the rewrite
- 29%
- of the priced scope sits in one finding, CAS-01
Thirty-one against ninety-four. That is the whole argument, and you cannot make it without the middle column.
Read the register twice and two things change. The rewrite stops being a philosophical argument between the people who like the code and the people who don’t, and becomes a comparison between two numbers that were produced the same way. And the longest finding on the page, fourteen weeks of untyped service layer, turns out to sit below the line, because nothing about it is stopping the business this quarter. It is genuinely worth doing. It is not worth doing first, and saying so in writing is most of what you are buying.
Then look at CAS-01. Nine weeks, twenty-nine percent of the priced scope, and it is one missing check. Rewriting the platform would have fixed it eventually, at three times the cost, some time next year. Probably.
The seven findings under the rule are the part clients argue about and the part that matters most. An audit that recommends fixing everything has made no decision and transferred no risk. Writing down what you are choosing not to fix, with a number against it, is the deliverable. Your successor will thank you. Mine never did.
A Consultancy, Your Own Staff Engineer, or a Staffed Audit Crew
The document comes out broadly similar. What differs is who can be cross-examined about it in month six, and whether the people who wrote it are available to do any of the work.
Consultancy
Your own staff engineer
KORE1 contract crew
Who reads the code
ConsultancyA team the firm assigns, often more junior than the partner you met.
In-houseSomeone who already knows the history, and already has a roadmap to ship.
KORE1 crewNamed engineers you interviewed, for the weeks it runs.
Candour of the findings
ConsultancyHigh on the code. Lower on anything that implicates the remediation they want to sell.
In-houseMixed. Nobody files a severe finding against code their own director approved.
KORE1 crewHigh. No platform to sell, no prior decision to defend.
What it costs
ConsultancyA fixed fee per phase, usually with a change order clause.
In-houseNothing on the invoice. One quarter of whatever they were going to ship.
KORE1 crewHourly per engineer, on a KORE1 W-2, for a scope you can stop.
When the scope grows
ConsultancyA change order, priced by the firm.
In-houseIt stops. The release date always wins.
KORE1 crewAdd a second reader for the heavy weeks, drop the seat after.
Afterwards
ConsultancyGone, unless you buy the remediation from them too.
In-houseStill here, back on the roadmap, carrying it all in their head.
KORE1 crewKeep the reader on the remediation, or hire them outright.
The middle column is better than it looks on paper. A principal engineer who has been in the codebase four years will find things no outsider gets to in six weeks, and she will be right about which of them matter. Usually.
What in-house audits almost never survive is the calendar and the politics, in that order. The audit gets a week, then a release slips and it gets nothing, and the half-finished version in a shared doc becomes the thing people argue about for a quarter. There is also a quieter problem, which is that an internal findings register is read as a performance review of whoever wrote the code, so the severe findings get softened on the way to the exec summary and the document that reaches the board is the one that was safe to send rather than the one that was true. We have read a few.
87%
of 947 audited commercial codebases carried a known open source vulnerability
68%
carried an open source license conflict, against 56% a year earlier
62.4%
of developers name technical debt their single biggest frustration at work
17 days
KORE1’s average time to hire for IT roles
Codebase figures from the 2026 Open Source Security and Risk Analysis report, published March 2026 from the Black Duck audit team’s analysis of 947 commercial codebases across 17 industries, which also recorded a mean of 581 vulnerabilities per codebase against 280 the previous year. Developer frustration from the 2024 Stack Overflow Developer Survey, where technical debt outranked the next answer roughly two to one. Hiring figure from Why KORE1.
Who Holds the Pen
Two seats cover most mid-market audits. A third shows up when the code is regulated or the stack is unusual.
- A staff or principal engineerReads the most of it, writes the register, and makes the effort estimates. The estimate is the skill. All of it. Anyone can say a module is bad; saying it is six weeks and being within two is why this seat is senior.
- An application security engineerTakes the access control model, the dependency graph, the secrets in history and the authentication paths. Usually about a third of the engagement, and the part most likely to produce something that has to be fixed this month rather than this year. We fill this seat from the same bench as application security engineer staffing.
- An architect, when the question is rewrite or refactorSomebody who has actually migrated a system of this shape and can say what the rewrite really costs. Without this seat the comparison on the register has a confident number on one side and a guess on the other.
- A QA lead, on the ones with no testsRare. Worth it when the audit is going to recommend a test suite, because sizing that properly is its own discipline. See QA staff augmentation.
Screening for this is not a normal engineering interview. We ask for a finding they filed that turned out to be wrong, and what it cost. Engineers who have genuinely audited somebody else’s code have that story and tell it without being prompted. The ones who have only ever reviewed pull requests inside a team they joined three years ago talk about standards instead. That tell is reliable enough that we lead with it.
Rates track seniority rather than the word audit. The BLS puts the median software developer salary at $135,980 as of May 2025, and audit work sits at the senior end of that. If the engagement turns into build work afterwards, that is software development staff augmentation and a different rate conversation.
How a Fixed-Scope Code Audit Runs
Four to six weeks for one system. The order matters, because step five is an opinion if you skip step two.
- Write down the decision the audit has to serveRewrite or refactor, can we ship on this for two more years, or what did the agency actually hand us. One sentence. An audit with no decision attached produces a list nobody acts on, and we have watched that happen to work we did well.
- Get read access and a guided tourThe repository, the build, a running environment, and ninety minutes with whoever knows the most. That ninety minutes is worth about a week of reading. Book it early.
- Run the tools, then set the output asideDependency and license scanning, secret scanning across the full git history rather than the current tree, coverage and complexity. This is the cheap third and it goes first, so the expensive reading is not spent rediscovering what a scanner already knows.
- Read the paths where the money and the data liveAuthentication, authorization, billing, anything touching customer records. Follow one real request. End to end, rather than browsing by directory, because the gap is almost always between two components rather than inside either of them.
- Size every finding, then sort and cutEngineer-weeks against each one, sorted by effort, with the line drawn where the findings stop blocking the decision from step one. This is the step clients try to skip. It is also the only one that turns a document into a scope.
- Walk it back to the team who wrote itRead the register out to the engineers before it reaches the board. Something will be wrong, usually an effort estimate that ignores a constraint nobody mentioned. Better corrected now. It also converts the authors from defendants into co-authors, which is the difference between a remediation plan that gets delivered and one that gets relitigated.
At the end you hold a register, a priced scope, and a short list of what you are deliberately not fixing. That last one is the document that survives. If the scope turns into delivery, it becomes a statement of work or a staffed crew by the month, and on code handed over by a vendor it is worth reading alongside who actually owns the contractor IP before anybody signs anything.
Rewrite or Refactor, Settled With Arithmetic
Most rewrites we have watched get proposed were argued on feeling. The code is unmaintainable, morale is bad, nobody wants to touch it. All of that can be completely true and still not add up to a rewrite.
An audit reframes it as two totals produced by the same people using the same method, which is the only version of this argument anybody wins. In the register above the comparison is thirty-one weeks against ninety-four, and the ninety-four buys no new capability while it runs. That is usually how it lands. Not always. Not even mostly, on older platforms.
When the arithmetic says refactor. The blocking findings cluster in two or three modules, the data model is broadly sound, and the worst finding is a missing check rather than a missing idea. This is the common case by a wide margin, and the reason is structural. Rewrites are priced against the system you can see; the old one also contains a decade of edge cases nobody wrote down, which is why the estimates miss.
When it genuinely says rewrite. The blocking set is most of the codebase, the platform is out of support, or the thing you need to build next is impossible in the current data model rather than merely painful. We have written that recommendation. Twice last year. It reads better when a register backs it.
When it says neither, yet. Sometimes the honest answer is that nobody can cost the rewrite because nobody can describe the current behavior. The audit then becomes the first half of the work rather than the decision, which is disappointing to hear in week six and much cheaper than finding out in month nine.
Technical debt is not an abstraction at this scale. CISQ put the accumulated software technical debt in the US at roughly $1.52 trillion inside a total cost of poor software quality of at least $2.41 trillion in its 2022 report. Your share of that is a number on a register. It can be sized. So size it. When the finding is speed rather than structure, the follow-on is a performance engagement that profiles and tunes the slow path.
One Reader, a Crew, a Fixed Scope, or Keep Them
Same recruiters, different paperwork. Pick by how firm the question is, because a fixed price on an audit scope nobody has drawn yet is a guess you pay for twice. Whichever route you take, 92% of the people we place are still in the seat twelve months later.
One seat
A single reader
One staff engineer, four to six weeks, one system, one register.
Contract staffingSmall crew
Engineer plus security
Two or three readers when the stack is wide or the data is regulated.
Project staffingFixed scope
Deliverables on a SOW
Once the boundary is written down, pay against the register rather than the hours.
SOW staffingKeep them
Contract, then hire
The engineer who audited your platform already knows it better than your next hire will in a year.
Contract-to-hire
Common Questions
What do code audit services actually deliver?
A written findings register, where every finding carries a severity, a location in the code, an effort in engineer-weeks and a disposition. The disposition is the part people underestimate. Half the value is the list of things you have decided, in writing, not to fix. Possibly more than half.
How long does a code audit take?
Four to six weeks for one system, with one or two senior engineers on it most days. Smaller services run two to three. The thing that stretches it is never the size of the repository, it is how long it takes to get read access and a working environment, which we have seen eat a fortnight. Twice.
Can a tool do this instead?
A tool finds roughly a third of it, and the cheapest third. Scanners are excellent at out-of-date dependencies, known vulnerabilities and secrets in git history. We run them first. What they cannot see is a missing authorization check, because absent code looks like nothing at all. Broken access control is the number one category in the OWASP Top 10 and it is largely invisible to static analysis.
We are taking code back from an agency. Is this the right thing to buy?
Yes, and buy it before the final payment clears rather than after. Two findings matter disproportionately on a handover. License conflicts, which 68 percent of audited codebases carry and which transfer to you with the code, and whether anything in the build depends on infrastructure or accounts the agency still controls. Both are much easier to resolve while you still have commercial leverage. Much easier.
What does a code audit cost?
Price it as weeks of senior engineers, not as a product. One staff engineer for four to six weeks is the usual shape, and the BLS median software developer salary of $135,980 as of May 2025 is the right anchor for the hourly contract rate once you add the employer burden we carry on a W-2. A crew of two or three costs proportionally more and finishes sooner. Your call. We have never seen an audit cost more than the first change order it prevented.
Will the audit tell us to rewrite?
Usually it tells you not to, and gives you the arithmetic to say so. The priced set of blocking findings is normally a fraction of a rewrite estimate, because a rewrite is costed against the system you can see while the old one also holds years of undocumented edge cases. Sometimes the answer really is rewrite. It is a much easier conversation with a register behind it.
Is this the same as technical due diligence?
No, and the difference is who is paying and why. Diligence serves a buyer deciding what a company is worth before a close date, so it is broad, fast and risk-weighted, and we staff that separately on technical due diligence for M&A. A code audit serves the company that already owns the code and has to decide what to do on Monday, so it goes deeper, sizes the remediation, and is written to be acted on rather than negotiated with.
Tell Us the Decision You Have to Make
Send us the language, the rough size of the codebase, and the decision the audit has to serve. Rewrite or refactor, a handover you need checked, or a platform you inherited last month. You’ll hear back from a KORE1 recruiter with seats, rates and engineers to interview.
Scope a Code Audit →Or call 949-706-6990
