Code audits are commissioned for three quite different reasons, and an audit scoped for one answers the wrong question for the others. Saying which situation you are in before engaging anyone is what makes the money worth spending.
The three reasons, and what each needs
Acquisition due diligence asks what you are buying and what it will cost to own: licence compliance, security exposure, maintainability and key person risk. An inherited codebase asks what is safe to change and where the danger is. A vendor dispute asks whether what was delivered matches what was promised, which needs the contract read alongside the code. Each needs different emphasis and, sometimes, a different auditor.
What a competent audit covers
Architecture and whether it can absorb the changes you plan. Security, using a structure such as the elements at 16 CFR 314.4 covering access control, encryption, secure development practices, logging and incident response. Dependency health, including unmaintained and vulnerable libraries and their licences. Test coverage and, more importantly, what the tests actually assert. Operational maturity: can it be deployed, observed and restored. And documentation adequate for a successor.
A useful report is prioritised, not exhaustive
A list of several hundred findings sorted by tool severity is a search result rather than an audit. What you need is a short list of things that genuinely matter, each with what it would cost to fix and what happens if you do not, and an explicit statement of what was examined and what was not. Ask to see a redacted previous report before engaging, because the format tells you what you will get.
Scope the access and the ownership before it starts
An auditor needs the repository, the ability to build and run the system, and access to whoever can answer questions, and an audit conducted by reading code alone will miss operational problems entirely. Agree the access up front. Agree too that the report is yours to use, particularly in an acquisition or a dispute where it may need to be shared with a third party.
Questions people ask about code audit
What should a code audit cover?
Architecture against your planned changes, security using a structure such as 16 CFR 314.4, dependency health and licences, what the tests actually assert, operational maturity including deploy and restore, and documentation adequate for a successor.
What does a good audit report look like?
Prioritised rather than exhaustive: a short list of things that genuinely matter, each with a cost to fix and a consequence of not fixing, plus an explicit statement of what was and was not examined.
What does the auditor need from us?
The repository, the ability to build and run the system, and access to people who can answer questions. An audit done by reading code alone misses operational problems entirely.