Executive Summary
An AI code audit is an independent review of a codebase that combines automated analysis with senior engineer verification, so a team learns which findings are real and which are noise. GrowExx ran an AI code audit across a manufacturer’s operations platform — 150,000+ lines of code, no production access — and reduced more than 25,000 tool warnings to roughly 40 verified findings, a dozen of them Critical or High.
The platform had no recorded incidents and no user complaints. It also had live credentials committed to source control, security code that had been written but never switched on, and core runtimes weeks away from losing security patches. None of it had surfaced, because nothing was looking.
| 150K+ lines of code audited across API, web and mobile |
25,000+ tool warnings triaged by senior engineers |
40 verified findings, a dozen of them Critical or High |
0 access to production required |
Client details anonymised under NDA. Figures are from the delivered audit report.
The Challenge: A Platform Nobody Could Vouch For
The problem was not that the software was failing. It was that nobody could say what was inside it.
Teams used the operations platform every day, on the web and on their phones, and rarely complained. There was no incident on record. That calm was misleading. The code had been built fast by a small team. There were no automated tests, no build pipeline and no release gate — every change went straight to the people using it.
Leadership’s question was simple: is this safe to keep running, and what do we fix first? They needed an answer they could defend to the board, not a raw scanner export.
The Audit: 25,000+ Warnings In, 40 Findings Out
Automated tools are necessary and insufficient. The verification layer is what turns a scan into code validation. GrowExx ran more than 25 analysis tools across the stack — static analysis, dependency scanning, secret detection, accessibility and performance checks. Together they raised tens of thousands of warnings. Most were style noise. Several of the most dangerous problems never appeared as a warning at all.
That gap is the reason every flag passed a senior engineer before it reached the report. The client received a short list of findings they could act on, not a backlog they would ignore.
What the tools reported versus what engineers confirmed
| The tools said | Our engineers found |
|---|---|
| Error handling in place | Security controls that looked finished but were never switched on. No scanner flags code that does nothing. |
| Zero accessibility violations on the pages tested | Over a hundred unlabelled form fields in screens the automated test never reached |
| A list of dependency vulnerabilities | Most were name collisions with unrelated packages. Dismissed, not reported. |
| Around 20 possible repeated-query hotspots | Each checked for real impact before being called a defect, so the team fixes what is real |
| Hundreds of “Blocker” issues | Nearly all from a single formatting rule. Logged once as a Low finding, not a fire drill. |
The Four Findings That Mattered Most
1. Live credentials committed to source control
Keys for identity, internal integrations, app signing and a paid third-party service were committed to the repositories. One of them shipped inside the web application, readable by anyone with a browser and developer tools. A secret in a client-side bundle is not hidden; it is published.
2. Security code that only looked like security
Error and access-handling code was fully written and never wired in. A reviewer reading the file would reasonably assume it was active. This is a recognised pattern in AI-generated code: the generator produces a plausible, complete-looking implementation, and nothing registers it into the request pipeline. No scanner flags code that does nothing, which is exactly why this class of defect survives automated review.
3. A ticking support clock
Core runtimes were weeks away from losing security patches, with more of the stack following within the year. After an end-of-support date, newly disclosed vulnerabilities simply stay open — there is no fix to apply.
4. No safety net for change
No automated tests, no pipeline, and 200+ open dependency advisories, several of them Critical. Every fix — including the ones we were about to recommend — would have been tested by users in production.
Why none of it had surfaced
Usage was low, the applications quietly absorbed short outages, and the logging that would catch misuse was switched off. No incidents did not mean no risk. It meant no visibility.
The Plan: 90 Days, No Rewrite
The architecture held up. Every layer was assessed as reusable with specific corrections, so the plan repairs what exists instead of starting over. The Critical findings need no code release at all — each can be closed in a day.
Each phase carries an exit check, so “done” is a test rather than an opinion.
| Phase | When | What happens | Done when |
|---|---|---|---|
| Contain | Days 0–7 | Rotate and purge every committed credential. Stop untested changes reaching production. | Old secrets rejected by their providers |
| Stabilize | Days 7–49 | Runtime upgrades behind smoke tests. Pipeline with secret and dependency scanning. Fix file-path and XSS sites. | A build with a Critical advisory fails |
| Harden | Days 49–90 | Database audit trail on. Data on devices protected. Tests on the most critical flows. | No open Critical or High code findings |
| Assure | Following quarter | Penetration test and independent re-audit | Retest passes |
What the Engagement Required
The audit needed a source code snapshot and one read-only database login. Nothing in the client’s environment was changed, and no production access was granted or used.
| From the client | A source code snapshot and one read-only database login |
| Production access | None. Nothing in their environment was changed. |
| Scope | Backend API, web application, mobile application, database |
| Stack | .NET backend, JavaScript web application, cross-platform mobile application, SQL database |
| Deliverables | Executive readout deck, full findings register, threat model, 90-day roadmap with exit checks |
What the Client Walked Away With
Leadership got the defensible answer they asked for: a ranked register of roughly 40 verified findings, a threat model explaining why each one mattered, and a 90-day sequence with exit checks that an engineering manager could run without us.
The most valuable output was the smallest one. Four Critical findings could be closed in days, without a code release, by rotating credentials and shutting the door that had been left open — work the client’s own team could start the same week. The same containment sequence opens every AI code audit and cleanup engagement we run.
“The four Critical findings were closed the same week — without shipping a single line of code.”
Containment was completed in week one. Full remediation outcomes are measured at the independent re-audit in the Assure phase and will be added here once that retest completes.
Frequently Asked Questions
What is an AI code audit?
An AI code audit is an independent review of a codebase that combines automated analysis tools with senior engineer verification. It establishes which reported issues are real, which are noise, and which risks the tools never detected at all — then ranks what to fix first.
Why do automated scanners miss broken security controls?
Scanners analyse the code that exists, not whether it runs. Access-handling code that is fully written but never registered into the request pipeline is syntactically correct and unreferenced, so it raises no warning. In this audit, that pattern accounted for one of the four most serious findings.
How many real findings come out of 25,000 scanner warnings?
In this engagement, more than 25,000 warnings from 25+ tools reduced to roughly 40 verified findings, around a dozen rated Critical or High. Hundreds of “Blocker” issues traced back to a single formatting rule and were logged once as a Low finding.
Does a code audit need access to production?
No. This audit was completed with a source code snapshot and one read-only database login. No production access was granted or used, and nothing in the client’s environment was changed.
What happens after the audit?
The deliverable is a sequenced plan, not a report. In this case: contain in the first week (rotate credentials, close the pipeline gap), stabilize over seven weeks (runtime upgrades, CI with secret and dependency scanning), harden to day 90, then verify with a penetration test and an independent re-audit the following quarter.
Why are credentials in source code a serious finding if nothing has happened?
A committed credential is valid until it is rotated, and source history keeps it even after it is deleted from the current files. A key that ships inside a web application is readable by any visitor. The absence of a recorded incident is not evidence the key has not been copied — particularly where, as here, the logging that would record misuse was switched off.
