AI code audit, code review or penetration test: which one fits?

Do you need a one-time assessment or continuous oversight for an AI-built application? WZ-IT provides the Production Readiness Audit as a baseline and the AI Code Review Retainer for recurring human reviews.

AI code audits, ongoing code reviews and penetration tests frequently appear next to each other in search results. They do not solve the same problem. The most important distinction is not the tool being used, but the statement the engagement should support at the end.

• An audit asks: where does the application stand today, and what blocks go-live or takeover?
• Ongoing review asks: which new risks are introduced by current changes?
• A penetration test asks: which weaknesses can be exploited through the reachable application?
• Software maintenance then asks: who will implement the required changes in a controlled process?

Direct comparison of the assessment types

The table also explains why an inexpensive automated scan is not a complete substitute. A tool may report a vulnerable package version. It cannot reliably decide whether the affected path is reachable, which customer data would be exposed, whether a temporary mitigation is adequate or whether the update breaks a critical workflow.

What is an AI code audit?

The term is not standardised. Used responsibly, it describes a one-time technical assessment of software built partly or substantially with AI tools. The proposal must therefore name the actual depth and boundaries.

A robust audit commonly covers:

• repository, build and reproducible runtime
• architecture, APIs, data model and background processes
• authentication, authorisation, roles and tenant isolation
• RLS, storage rules and administrative functions
• secrets, environment variables and external keys
• dependencies, known CVEs and end-of-life risks
• tests, CI/CD, staging, production and rollback
• logging, monitoring, backups and recoverability

These layers matter particularly for AI-built code because a working demo flow says little about invisible system boundaries. Sign-in can work while an API endpoint checks authentication but not the required role. A dashboard can look correct while a database policy fails to isolate tenants.

The WZ-IT Production Readiness Audit therefore combines code assessment with operational readiness. It is neither a guarantee of error-free software nor a complete offensive security test.

What is ongoing code review?

Ongoing review starts from a known baseline. Instead of auditing the entire application from scratch in every cycle, it focuses on an agreed corridor of changes and their effects.

Typical questions include:

1. Does a pull request change roles, data access or tenant isolation?
2. Does a new dependency introduce a relevant CVE or end-of-life risk?
3. Does a new API endpoint lack an authorisation boundary?
4. Are migration, rollback and error handling traceable for the change?
5. Must a finding be fixed before release, or can it be accepted and scheduled?

Continuity creates the value. Reviewers know the architecture, risk profile and previous decisions, so every question does not restart from zero. This is particularly useful where a small team develops rapidly with Cursor, Claude Code, Lovable or similar tools but does not have its own senior review process.

The AI Code Review Retainer deliberately separates this technical control function from implementation, hosting and incident response.

How does a penetration test differ?

A penetration test primarily adopts an attacker perspective. Its purpose is not only to identify questionable code, but to demonstrate weaknesses in a controlled manner. Scope and rules must be agreed in advance, including permitted targets, test accounts, time windows, excluded systems and handling of production data.

Depending on scope, a penetration test may examine:

• authentication and session attacks
• missing access controls and IDOR/BOLA
• injection, request manipulation and insecure APIs
• misconfiguration of reachable services
• privilege escalation and combinations of weaknesses
• rate limits, password reset and administrative paths

A black-box test does not automatically reveal internal dependency risks, dangerous dormant functionality or a missing restore process. A white-box penetration test can include source code and architecture but remains limited to a defined security objective and test window.

OWASP deliberately provides different verification and testing perspectives through ASVS and the Web Security Testing Guide. Secure development controls and offensive testing are complementary.

Where automated checks fit

Automation is an important part of all three assessment types:

• Software Composition Analysis identifies known dependency risks.
• Secret scanning looks for credentials committed by mistake.
• Static analysis finds certain code and data-flow patterns.
• Container and image scanning checks operating-system packages and base images.
• Dynamic scanning tests the running application for known web patterns.

The NIST Secure Software Development Framework describes secure development as a repeatable process spanning preparation, protection, production and response. A single scanner does not deliver that process. It provides inputs that still need evaluation against architecture, exposure, business risk and release planning.

Which combination fits each situation?

Before initial production use

Start with a one-time audit. It creates a baseline and separates launch blockers from technical debt. For an internet-facing application, sensitive data or a material threat model, a penetration test may follow.

The team keeps developing after go-live

Add ongoing code review. A monthly cadence can fit planned changes, while active release cycles may require weekly review. Critical changes must be marked clearly and supplied with sufficient context.

Findings are not being implemented reliably

Review alone does not solve that problem. In this case, software maintenance and ongoing support or an internal engineering allowance is required for fixes, tests and releases.

The application handles specially protected data

Audit and review assess the software. The operating framework remains a separate layer. For professional secrecy holders, the Section 203 Managed Cloud may also be relevant. Code review alone does not create that contractual and infrastructure framework.

Clear commissioning prevents false expectations

Before any assessment, the following should be documented at minimum:

• repositories, applications, APIs and environments in scope
• technical baseline and known legacy findings
• permitted access and source-code handling
• review window or recurring cadence
• deliverable and risk classes
• communication and response targets
• responsibility for remediation, retesting and releases
• explicit exclusions such as penetration testing, hosting or 24/7 response

This turns a vague promise to "look at the code" into a verifiable service.

Sources

• NIST Secure Software Development Framework, SP 800-218
• OWASP Application Security Verification Standard
• OWASP Web Security Testing Guide
• GitHub: About Dependabot alerts