Do I need both a code audit and a penetration test?

Eventually, yes, because their blind spots barely overlap. A code audit reads your source and finds root causes, dormant flaws, and dependency risk; a pen test attacks the deployed system and proves what is actually exploitable, including infrastructure the repo never mentions. A mature security program runs both, but few teams need to buy both in the same quarter.

Which should come first, the code audit or the pen test?

Audit first in almost every case. Pen testers billing days to rediscover flaws that ten minutes with the source would have shown is the classic sequencing mistake, and it produces an expensive report with half the coverage. Review and fix the code, then point the pen test at the hardened system so the testers spend their time on chains and business logic abuse.

Will a code audit satisfy a SOC 2 or customer requirement for a penetration test?

No. If a compliance framework or a customer contract explicitly says penetration test, only a pen test checks that box, so the paperwork wins on timing. An audit beforehand still pays off, because remediating findings before the test window produces a cleaner report to hand over.

If a pen test proves real exploits, why bother reading the code at all?

Because a pen test only sees what the attack surface exposes during the testing window. An unauthenticated endpoint behind a feature flag, a vulnerable transitive dependency, or a query helper that makes every call site injectable are invisible from outside and obvious from inside. Proof of exploitability is valuable, but it is a sample, not an inventory.

Is a penetration test worth it for a pre-launch product?

Usually not yet. Pre-launch, the system is still changing weekly and there may be no production-like environment to attack, so the results go stale immediately. That stage is better served by having a human read the code; a free code audit is a cheap way to do exactly that before you spend pen-test money.

Code Audit vs Penetration Test

Two different questions about the same system

Teams often use “audit” and “pen test” interchangeably, then buy the wrong one. The distinction is simple once you frame it as two different questions.

A code audit asks: is this code built correctly? An auditor reads your source, your dependency tree, your auth logic, your queries, and your configuration, and reports what is wrong or fragile, whether or not anyone could exploit it today.

A penetration test asks: can this running system be broken into? A tester attacks your deployed application the way a real adversary would, usually without source access, and reports what they actually got into and how.

Both are point-in-time assessments performed by humans. Beyond that, almost everything differs: the vantage point, the evidence produced, the cost, and the kinds of problems each one surfaces.

Side by side

Dimension	Code audit	Penetration test
Vantage point	Inside: reads source, config, dependencies	Outside: attacks the deployed, running system
Primary question	Is the code built correctly?	Can this system be exploited in practice?
What it catches	Logic flaws, insecure patterns, missing authorization checks, vulnerable dependencies, architectural weaknesses, maintainability risk	Exploitable weaknesses reachable from the attack surface: injection, auth bypass, misconfigured servers, chained exploits
What it misses	Whether a flaw is reachable in production; infrastructure and network issues outside the repo	Anything not exposed at the surface: dormant flaws, dead-but-dangerous code, technical debt, unexploitable bugs waiting for one config change
Evidence produced	Findings with file, line, and root cause; fix guidance	Proof of exploit: what was accessed, how, with reproduction steps
Who runs it	Senior engineers reading code	Offensive security specialists
Typical cost	Free to roughly $15k to $50k depending on scope	Roughly $10k to $60k for a serious engagement
Speed	Days to a few weeks	One to four weeks including reporting
When it fits	Pre-launch, post-acquisition, after fast AI-assisted growth, when quality is the concern	Compliance requirements, customer security reviews, validating defenses on a mature system

What a code audit finds that a pen test cannot

A pen test only sees what the attack surface exposes during the testing window. A code audit sees everything in the repository, which matters for a few classes of problems:

Dormant vulnerabilities. An unauthenticated admin endpoint behind a feature flag is invisible to a pen tester today and a breach when the flag flips. An auditor reading the router sees it immediately.

Root causes, not symptoms. A pen tester finds one injectable parameter. An auditor finds the query-building helper that makes every call site injectable, and tells you to fix it once. Our writeup on how a code audit works walks through this in detail.

Dependency and supply chain risk. Vulnerable transitive dependencies rarely show up in black-box testing unless the tester gets lucky. Reading the lockfile is deterministic. See auditing third-party dependencies for why this category keeps producing incidents.

Non-security defects. N+1 queries, missing indexes, absent test coverage, and structural debt will never appear in a pen test report. They still take products down.

What a pen test finds that a code audit cannot

The reverse blind spots are just as real:

Deployment and infrastructure reality. The code can be perfect while the S3 bucket is public, the staging database is internet-facing, and the WAF is misconfigured. None of that is in the repo.

Exploitability proof. An audit says “this is vulnerable in principle.” A pen test says “we exfiltrated the user table through it.” When you need to convince a board, a customer, or an insurer, the second sentence carries more weight.

Exploit chains. Skilled testers combine three low-severity issues into one critical path. That adversarial creativity against the live system is the discipline’s core value.

Everything outside the source you control. Third-party services, SSO integrations, and network segmentation get exercised by a pen test and ignored by a source review.

Cost and sequencing

In our experience the most common sequencing mistake is buying an expensive pen test against code that was never reviewed. The testers spend billable days rediscovering issues that ten minutes with the source would have shown, and the report reads like a code audit performed at ten times the price and half the coverage.

The efficient order for most teams:

Automated baseline first. Dependency scanning and static analysis in CI. Cheap, continuous, catches the pattern-shaped bugs. (See the glossary entries on SAST and DAST for where tooling fits.)
Code audit second. A human reads the code, fixes root causes, and cleans out the findings a pen tester would otherwise bill you to rediscover.
Pen test third. Against the hardened system, where the testers’ time goes to genuinely adversarial work: chains, business logic abuse, infrastructure gaps.

If a compliance framework (SOC 2, ISO 27001, a customer contract) explicitly requires a penetration test, that requirement wins on timing. Buy the pen test when the paperwork demands it, but still audit the code first if the calendar allows, because remediating audit findings before the test window produces a cleaner attest report.

The verdict

These are complements, not substitutes. A mature security program eventually includes both. But if you are choosing where the next dollar or the next week goes:

Best for a code audit: you own the source, the product is pre-launch or recently grown fast (especially with AI-generated code), no human has ever read the codebase adversarially, and you want root causes fixed cheaply and early.

Best for a penetration test: the system is deployed and reasonably mature, you need documented proof of exploitability, or a customer, insurer, or compliance framework specifically requires one.

The general rule: audit before you test. Reading the code is the cheaper way to find most flaws; attacking the system is the only way to prove which ones matter in production.

Get a free code audit

If your codebase has never had a human security review, that is the gap to close first. You can get a free code audit from us: a Webisoft engineer manually reviews your code and sends you a written findings report. It is genuinely free, with no obligation, and it will tell you whether you are ready for a pen test or still have homework to do first.