A review of an AI-built product is only as useful as the code audit report it ends in. The report is the document a founder decides from, forwards to an enterprise customer’s security team and hands to whoever fixes the code. A report that cannot do those three jobs leaves the review unfinished.
This guide shows what a good code audit report for an AI product contains: the eight sections, the nine fields of a single finding, how severity is rated and how to tell a decision-grade report from a scanner export. For the wider route from prototype to live product, read the founder’s guide to ai-generated code in production.
TL;DR
A code audit report is the written result of an independent review of a product’s source code, configuration and setup: every finding with its evidence and severity, ranked into a fix order, with a handoff an engineer can act on. For an AI-built product, the report also shows which code nobody on the team can explain and what the product sends to AI models.
- Eight sections make up a complete code audit report: executive summary and verdict, scope and limits, product and architecture map, findings, risk overview, dependencies and licences, prioritised action plan, and technical handoff with evidence.
- Nine fields describe every finding: ID, plain-language title, severity with a reason, category, location, evidence, business impact, fix with effort, and status.
- Five severity levels rank the findings, from Critical (fix before launch) through High, Medium and Low to Informational; security vulnerabilities can be scored with CVSS v4.0 where the framework applies, and other findings get a documented assessment of likelihood and impact.
- Three signals separate a decision-grade report from a scanner export: reproduced evidence for each finding, a business impact in plain language, and a fix order tied to your launch or contract date.
What is a code audit report?
A code audit report is the document an independent reviewer delivers after reading a product’s source code, configuration and deployment setup. The report lists each finding with evidence, ranks the findings by severity, sets a fix order and gives engineers enough detail to start. What the reviewer checks and how the engagement runs is covered in ai code audit.
Three readers use the same report for different decisions. The founder or COO reads the executive summary and verdict to decide whether to launch, sign a customer or raise funding. The technical lead or freelancer reads the findings and the handoff to plan the fixes. An enterprise customer or investor usually sees the summary, the scope and the status of the fixes, not every finding.
A code audit report is not a certificate and not a pass-or-fail stamp. The report describes the state of the code at a stated date and commit, within a stated scope. Any area outside that scope is unreviewed, not approved.
What a code audit report for an AI product contains: eight sections
A code audit report for an AI product contains eight sections, and each section answers a different question for a different reader. Sections 4 and 5 hold the findings, section 7 turns them into a prioritised action plan and section 8 is the technical handoff: the three deliverables a review promises, in the order a reader needs them.
| # | Section | Question it answers | Read by |
|---|---|---|---|
| 1 | Executive summary and verdict | Can we launch, sell or hand over, and what must happen first? | Decision owner |
| 2 | Scope, method and limits | What was reviewed (repositories, commit, environments, tools), and what was not? | Decision owner, customer |
| 3 | Product and architecture map | How is the product built: modules, data flows, third-party services, AI tools and AI models? | Technical lead |
| 4 | Findings | What is wrong, where, how do we know, and how bad is it? | Technical lead |
| 5 | Risk overview | How many findings per severity and per area, and where do they cluster? | Decision owner |
| 6 | Dependencies and licences | Which third-party packages carry known vulnerabilities, maintenance or licence risk? | Technical lead, legal |
| 7 | Prioritised action plan | What do we fix now, what before launch, and what later? | Both |
| 8 | Technical handoff and evidence appendix | What does an engineer or AI coding tool need to fix each finding, and how is a fix confirmed? | Engineer |
Section 2 is the section founders skip and the one that matters most when something goes wrong later. A report without a list of out-of-scope areas lets unreviewed parts of the product read as safe. We’d recommend refusing a code audit report without a limits paragraph, because the limits decide what you can honestly tell a customer about the review.
The verdict line in section 1 is where reports differ most. A launch verdict should name the conditions that must be met first, and a production readiness checklist shows what those conditions usually cover; a structural decision to keep, refactor or rebuild follows refactor or rewrite. The report should say which of the two decisions its verdict answers.
Sections 2 and 4 also answer the supplier questionnaires of enterprise customers, which often ask how code is reviewed against secure coding, the control ISO/IEC 27001:2022 lists as Annex A 8.28.
What AI-built products add to the report
An AI-built product needs four report parts that a classic code audit often leaves out: the AI tool footprint, the quality of generated tests, dependency and licence checks, and the risks of model calls when the product uses an AI model at runtime. The parts exist because AI coding tools change where problems hide, not because the tools are faulty.
AI tool footprint and code nobody can explain
Where development records are available, the report can identify code produced or substantially modified with AI assistance. More importantly, the report should flag modules with unclear ownership, duplicated logic, insufficient tests or undocumented behaviour. Code generated from separate prompts often repeats the same rule in slightly different ways, such as two price calculations, and a later change fixes one copy and misses the other.
When the origin of a module cannot be established, the report records that limitation rather than inferring which tool created it. Ownership, tests and documentation decide how risky the next change is; the name of the tool does not.
Tests that pass but test nothing
Test count and coverage percentage are weak evidence in an AI-built product, because the same AI tool often wrote the code and the tests that check it. A good report states, for each critical flow such as sign-up, payment and permissions, whether a test exists that would fail if the behaviour were wrong. A test that only checks that a function was called stays green while the result is wrong.
Dependencies and licences
AI coding tools add third-party packages quickly, including packages that are unmaintained, vulnerable or licensed in a way that conflicts with how the product is sold. OWASP Top 10:2025 lists Software Supply Chain Failures as category A03. The dependency section should identify third-party components, versions, licences and relevant supply-chain relationships.
A software bill of materials (SBOM) provides a structured inventory of those components, while dependency analysis adds known vulnerability information, maintenance status and recommended actions. The 2026 Minimum Elements for a Software Bill of Materials, published by CISA with partner agencies, provides a reference for the inventory data, not a substitute for security assessment.
Products that call an AI model at runtime
A product with AI features, such as a support assistant, document search or generated summaries, needs a report section on its model calls. The term “AI product” covers both an app built with AI tools and an app with AI features; the difference and its cost effect are explained in ai app development cost.
Three checks belong in that section. Prompt injection, listed as LLM01:2025 in the OWASP Top 10 for LLM Applications, covers user or document text that changes what the model does. Unbounded consumption, LLM10:2025, covers model calls without limits that turn into outages or an uncontrolled model bill.
The data-flow check records which personal data reaches the model provider, for what purpose, and under which contractual arrangements. Where the provider acts as a processor on your behalf, GDPR Article 28 requires an appropriate processing agreement, and Article 32 requires security measures appropriate to the risk. The report should identify any missing controls or contractual arrangements rather than assume that every model provider has the same data-protection role.
For AI systems intended to interact directly with people, EU AI Act Article 50(1) generally requires informing users that they are interacting with AI, unless this is already obvious from the context. The transparency obligations have applied since 2 August 2026. A report should check whether the product’s interface meets the applicable requirement rather than assume every AI-enabled feature needs the same disclosure.
Anatomy of one finding: nine fields
One finding in a code audit report should carry nine fields, so a founder can decide and an engineer can act without a follow-up call. The finding, not the page count, is the unit of value.
| Field | What it contains | Why the founder needs it |
|---|---|---|
| ID | A unique reference, for example F-07 | Track fixes and discuss them in the read-out |
| Title | One plain-language sentence: what can go wrong | Understand the finding without reading code |
| Severity | Critical, High, Medium, Low or Informational, plus a one-line reason | See what blocks the launch |
| Category | OWASP Top 10:2025 or OWASP LLM 2025 ID for security; “engineering quality” otherwise | Match the finding to customer questionnaires |
| Location | File, endpoint, configuration or service | Lets the engineer start at once |
| Evidence | Reproduction steps or a test result | Proves the issue is real, not a scanner guess |
| Business impact | Effect on users, personal data, money or contracts | Weigh the finding against the launch date |
| Fix and effort | The recommended change, sized S, M or L | Plan who does the work and when |
| Status | Open, fixed, partly fixed or accepted risk, with a re-test date | Show progress to customers and investors |
Automated scanner exports may include severity, status and generic impact descriptions. A decision-grade report adds validated evidence, explains the effect on the product’s actual users and workflows, and sets a fix order against business milestones.
Sample finding 1: security (illustrative, no client data)
| Field | Content |
|---|---|
| ID | F-03 |
| Title | Anyone with a free account can run the AI support assistant without limits |
| Severity | High (illustrative severity assessment, not a calculated CVSS score) — easy to trigger with a simple script; cost and availability impact; no data exposure confirmed |
| Category | OWASP LLM10:2025 Unbounded Consumption |
| Location | POST /api/assistant/chat; the model API is called from the server with no per-user quota |
| Evidence | A script logged in as a free test user sent 500 requests in ten minutes. Every request was answered, and no rate limit, quota or spend alert was triggered. |
| Business impact | The model provider bills per token, so one abusive account sets the size of the monthly bill. When the provider’s own usage limit is reached, the assistant stops working for every customer. |
| Fix and effort | A per-user rate limit and daily quota on the endpoint, a spend cap and alert at the model provider, and a block on free accounts that keep hitting the limit. Effort: S. |
| Status | Open — re-test after the fix |
Sample finding 2: engineering quality (illustrative, no client data)
| Field | Content |
|---|---|
| ID | F-11 |
| Title | Payment tests pass even when refund amounts are wrong |
| Severity | Medium (illustrative) — no security exposure; the rating depends on how many refunds are affected, the amounts involved and the actual impact on customers, and would rise if any of those is large |
| Category | Engineering quality (test coverage) |
| Location | tests/checkout/ and the refund module |
| Evidence | The 42 checkout tests replace the payment provider with a mock (a stand-in) and only check that the refund function was called. Changing the refund rounding from two decimals to none left all 42 tests green. |
| Business impact | A refund error reaches customers and the finance team before any test fails. The first signal is a customer complaint or a reconciliation gap at month end. |
| Fix and effort | Contract tests against the payment provider’s sandbox for three flows (payment, partial refund, full refund) that check amounts and currency. Effort: M. |
| Status | Open |
The two samples show why a report needs both kinds of finding. A security scanner would flag F-03 only if it knew the business purpose of the endpoint, and no security scanner would flag F-11 at all.
Want findings written like these for your own product?
An AI-built product review explains every finding in plain English, with the evidence behind it and its effect on your product, and turns the findings into a prioritised action plan your team or your AI coding tool can act on. Engineering and security are reviewed together, so you get one fix order instead of two reports that disagree.
How severity is rated in a code audit report
Severity in a code audit report describes how serious a finding is, on five levels from Critical to Informational. Security vulnerabilities may be scored using CVSS v4.0 when the framework applies: the CVSS v4.0 specification published by FIRST rates scores of 0.1–3.9 as Low, 4.0–6.9 as Medium, 7.0–8.9 as High and 9.0–10.0 as Critical. Other findings, including engineering quality, operational weaknesses and business-logic defects, need a documented severity assessment based on their likelihood, impact and affected users or workflows.
| Severity | What it means | AI-product example | Illustrative remediation priority |
|---|---|---|---|
| Critical | Exploitable now, or breaks a core flow for all users | Customer data readable without logging in; secret key for a paid service in the front-end code | Before launch; contain the exposure first |
| High | Serious and reachable, with limited preconditions | One customer account can open another account’s records; AI endpoint without limits (F-03) | Before launch or the next enterprise deal |
| Medium | Real risk under specific conditions, or wrong behaviour with a workaround | Tests that cannot catch payment errors (F-11); no handling for a third-party outage (OWASP A10:2025) | Within the next one or two releases |
| Low | Limited impact or hard to trigger | Detailed error messages shown in production; outdated package with no known exploit path | Planned backlog |
| Informational | No direct risk; a quality or maintainability note | Duplicate logic across modules; missing architecture notes | When the module is next changed |
Severity describes the seriousness of a finding. Priority determines what should be fixed first, considering severity, exploitability, business dependencies and upcoming milestones. A Medium finding that blocks an enterprise customer’s security questionnaire can rightly move ahead of a High finding in an internal admin screen.
Priority never works the other way round: a launch blocker cannot be made acceptable merely by assigning it a later target date. The remediation priorities in Table 3 are illustrations, not fixed waiting periods for every finding at that level.
How to read a code audit report if you are not technical
A non-technical founder can read a code audit report in five steps without reading any code. The first two steps tell you whether the rest of the report changes your plans.
- Read the verdict and the fix-before-launch list in section 1.
- Read the title and business impact of every Critical and High finding; skip location and evidence for now.
- Read the limits in section 2 and note what you cannot claim to customers.
- Hold the action plan against your real dates: launch, enterprise contract or funding round.
- Check that every fix-now item has a named owner on your side.
Five questions make the read-out meeting with the reviewer useful:
- Which single finding would stop you from launching if this were your product?
- What did you not review, and does that gap matter for our next milestone?
- Which findings did you reproduce, and which are risks still to investigate?
- Which findings can safely wait three months?
- How will a fix be confirmed as closed?
Who fixes what after the report, and when a finding counts as closed, is set out in the after-the-audit section of the ai code audit guide.
How to tell a good report from a scanner export
A decision-grade code audit report differs from a scanner export in eight visible signals, and all eight can be checked in a sample report before you sign a review.
| Signal | Scanner export or weak report | Decision-grade report |
|---|---|---|
| Evidence | Pattern match, no proof the issue is reachable | Reproduction steps or a test result per finding |
| Business impact | Generic risk text per rule | Impact on your users, data, money or contracts |
| Duplicates | The same issue listed once per file | Grouped into one finding with all locations |
| False positives | Left in the list | Removed, or marked “not confirmed” with the reason |
| Limits | Not stated | Out-of-scope areas listed |
| Fix order | Sorted by tool score | Prioritised against your dates |
| Summary | None, or a chart | A plain-language verdict on page one |
| Re-test path | None | Status field and re-test log |
Automated scans remain an input to the review, not its output. We’d recommend asking any reviewer for one sample finding with all nine fields before you sign; a sample without evidence or business impact predicts a full report without them.
Code audit report vs security assessment report vs pentest report
A code audit report, a security assessment report and a penetration test report answer different questions, so one cannot stand in for another in a customer questionnaire. NIST SP 800-115, the US National Institute of Standards and Technology’s technical guide to security testing and assessment, separates review techniques from target vulnerability validation techniques such as penetration testing — the same line that separates the two documents.
| Report | Based on | Typical evidence | Usually requested when |
|---|---|---|---|
| Code audit report | Source code, configuration and deployment setup — engineering and security | File and line, reproduction with test accounts, test results | Before launch, an enterprise deal, due diligence or a handover |
| Security assessment report | Security controls, policies, configuration and processes; may include no code review | Control gaps against a framework such as ISO/IEC 27001:2022 Annex A | A customer, auditor or insurer asks how security is managed |
| Penetration test report | Attacks on the running application or network | Exploited paths, attack chains, screenshots | A customer or regulator asks for proof that the live system resists attack |
For a pre-launch AI-built product, the code audit report usually comes first, because it covers engineering and security in one fix order. When the question is how the live system holds up against an attacker, the penetration testing guide explains what a pentest report adds.
How Sunbytes reports an AI-built product review
The test of a code audit report is whether a decision owner can act on page one and an engineer on page ten. That test shapes how Sunbytes reviews AI-built products.
Sunbytes reviews AI-built products through an agreed scope covering relevant code, architecture, security, critical workflows and deployment settings. Engineers and security specialists examine the same product, then turn the findings into a prioritised action plan and technical handoff. Remediation and re-checks can follow where needed, with responsibilities and scope agreed separately. The result helps founders decide what must change before launch and gives their technical teams a practical starting point.
Code access is handled under an ISO/IEC 27001-certified information security management system with Netherlands-led governance, and the review draws on 15+ years in software delivery and 300+ projects delivered.
To see this report format applied to your own product, start with an AI-built product review or discuss your AI-built product with our team.
