Code Audit: A Checklist for Reviewing Someone Else's Software

A code audit is the systematic review of a codebase by someone who did not build it. It answers three questions: is the software secure enough for its purpose, can it be developed further at a reasonable cost, and what risks do you take on with it, technically, in terms of licensing, and in terms of regulation.

When do I need a code audit?

Whenever you take on responsibility for code you did not write. Five typical occasions:

• Taking over from a vendor. The most common case, and the one with the greatest potential for surprises.
• Before a purchase or an investment. Technical due diligence: this is where the findings decide the price.
• Before a prototype goes live. Especially relevant if it was built with AI tools, see From Prototype to Production.
• After a security incident. Not just the exploited hole, but the question of whether the same pattern exists elsewhere too.
• Before a major investment. Before you put a year of development into a foundation whose load bearing capacity nobody has checked.

The checklist: six areas an audit must cover

An audit that only covers the first area is a security scan. You can hold these six points up as a checklist against a proposal: if one is missing, ask about it.

• Security. Known vulnerability patterns along the OWASP Top 10:2025, handling of credentials, authentication and permissions, treatment of inputs.
• Maintainability. Structure, duplication, complexity, test coverage, how understandable it is for someone joining fresh.
• Dependencies. Which packages, which versions, which known vulnerabilities, how actively maintained, how deep the chain runs. Supply chain failures have been their own OWASP category since 2025 (A03).
• Licenses. Which licenses are present in the codebase, and are they compatible with your business model? A copyleft license inside a closed product is a finding that overshadows everything else.
• Operations. Can it be rolled out, monitored, rolled back? Is there a reproducible environment, or does it only run on one particular machine?
• Law and regulation. What personal data is processed, and on what legal basis? Does the product fall under the Cyber Resilience Act, whose reporting obligations take effect on September 11, 2026?

How does a code audit proceed?

In five steps, where step one determines the quality of the entire result.

• 1. Clarify the purpose. An audit before a purchase looks for different things than one after an incident. Without this decision you get a report that mentions everything and decides nothing.
• 2. Capture automatically. Static analysis, dependency and license checks, duplication, complexity, test coverage, change frequency from the version history. This is the foundation, not the result.
• 3. Read with purpose. A person reads the areas flagged as notable in step 2, plus always: authentication, permissions, payments, data access. A complete read through is neither affordable nor necessary at a realistic size.
• 4. Document evidence. Every finding with its exact location and a concrete scenario for how it plays out. A finding with no impact is just an opinion.
• 5. Prioritize. By damage times likelihood of occurrence, with an effort estimate. A list of 200 equally ranked items helps nobody.

How do I spot a superficial audit?

By four traits that all boil down to the same thing: a tool was run and the report was exported.

• It consists mostly of tool output. With no judgment on which finding actually matters in this particular project.
• It lacks domain logic. No tool judges whether the permission rules fit the business model. That is exactly the most expensive kind of finding.
• No prioritization. Everything is "medium".
• No statement of scope. A serious audit names what was not checked. A missing scope statement is itself a warning sign.

What does a code audit cost?

The honest answer: it depends almost entirely on the scope and the purpose, and the flat figures you find in guides are market observation, not reliable values.

What can be said responsibly: effort does not scale with the number of lines, but with the number of independent components and the depth of judgment required. An audit that only captures and classifies the six areas above with automated tools is a fraction of an audit that penetrates the domain logic of the permission system.

So do not ask for a flat quote, ask for an effort estimate per area, then you can decide where depth is needed. If you want to commission a review like this, our software and SaaS development is the place to start.

Frequently asked questions about code audits

Can an AI perform a code audit?

It can substantially speed up step 2 and parts of step 3: finding patterns, explaining connections, pre-sorting findings. It cannot do step 1 and step 5: setting the purpose and prioritizing by business risk requires knowledge of the company.

How long does an audit take?

For a mid sized project, the usual range is a few days to a few weeks. The range is this wide because step 3 depends on what step 2 finds, it cannot be set responsibly beforehand.

Should a vendor audit their own work?

That is workable for a stocktaking exercise. For a judgment that becomes the basis of a purchase decision or a contract negotiation, the independence of the reviewing party is part of its value.

What do I do with the result?

Handle the critical findings immediately, put the expensive ones into planning, and put the rest into a list that gets worked through the next time that area is touched anyway. An audit whose result is meant to be worked through entirely as its own project rarely gets funded.

An audit is a snapshot in time; the most expensive finding is the one that shows up again six months later. Code Guardian keeps running the checks an audit performs only once, on every single change.

Sources

• OWASP Top 10:2025 (review framework for the security section), final version January 2026.
• Regulation (EU) 2024/2847 (Cyber Resilience Act), reporting obligations from September 11, 2026, main obligations from December 11, 2027.
• ISO/IEC 25010:2023 (reference framework for the maintainability section).

As of: July 27, 2026. General professional guidance, not legal advice and not a price commitment; effort must be estimated case by case.