Penetration Testing Process, Types, and Key Tools: A Developer's Decision Guide

Your team ships code faster than ever: AI-generated PRs, automated deployments, weekly releases. Your SAST tools flag risky patterns and your code reviews catch logic errors. But neither answers the one question that decides whether a finding becomes a breach: can an attacker actually exploit this in production?

Penetration testing answers that question. It validates exploitability under real adversarial conditions, tests authentication flows, chains vulnerabilities across services, and proves whether a theoretical risk translates into real business impact. The catch is that a traditional engagement takes six weeks and costs $50k or more, while an automated scanner runs fast but misses the context that makes a vulnerability exploitable in the first place.

This guide walks the five-phase penetration testing process, explains when to use black box, white box, or gray box, compares traditional firms against modern platforms, and shows how a continuous attack-and-defend loop closes the gap between "the code looks secure" and "the code is secure."

Why the Process Matters: Proving Exploitability, Not Just Finding Issues

Most engineering teams have built a defensive stack: SAST, dependency scanners, secret detection, AI code review. All of it answers one question, does this code look secure? Penetration testing answers a different one, is this code exploitable under adversarial conditions?

The distinction is not academic. AI code review operates at the file and function level. It can tell you whether a single authorization check looks correct or whether a query is parameterized. What it cannot see from a pull request diff is how those pieces compose:

• Cross-service attack chains: an authentication bypass in Service A that enables privilege escalation in Service B, which exposes PII through Service C's API.

• Business logic flaws: a discount code that stacks with promotional pricing because two microservices never share state.

• Authorization context collapse: a GraphQL resolver that enforces object-level permissions in one code path but skips them through a batch query.

CodeAnt AI's offensive testing found 476,000 healthcare records exposed through a three-step chain (subdomain enumeration, then authenticated session hijacking, then a GraphQL Broken Object Level Authorization flaw) that defensive tools flagged zero issues for. Each component looked secure in isolation. The vulnerability only existed in how they composed under attack.

That gap has a cost, and it is growing. Vulnerability exploitation rose to 20% of breaches as an initial access vector in the Verizon 2025 Data Breach Investigations Report, up 34% year over year, and the window between disclosure and exploitation has collapsed: VulnCheck found that roughly 29% of newly exploited vulnerabilities were attacked on or before the day their CVE was published. A defensive signal that "looks secure" is no longer enough when the average finding has to be proven, fast.

The Five-Phase Penetration Testing Process

The process is what separates a tool that flags a potential issue from a platform that proves an exploit. It runs in five phases.

Phase 1: Reconnaissance, mapping the attack surface

The goal is to enumerate every publicly exposed asset and entry point before active testing begins. That means subdomain enumeration through certificate transparency logs and DNS records, JavaScript bundle analysis that reveals API endpoints buried in minified code, public storage discovery (S3 buckets, Azure containers), and technology fingerprinting.

Reconnaissance catches the assets you forgot existed, and passive recon is valuable precisely because it is undetectable, your WAF logs will not show it.

Phase 2: Scanning, identifying vulnerabilities

Now you actively probe the discovered assets: port scanning for running services, web vulnerability testing for injection and SSRF candidates, API probing for broken authentication, and GraphQL introspection that reveals the full schema including internal mutations.

Scanning identifies potential vulnerabilities. It does not prove them, and external-only tools miss authenticated flows, multi-tenant isolation, and business logic entirely.

Phase 3: Exploitation, proving real impact

This is where a candidate becomes a confirmed finding. The tester constructs a working proof-of-concept, autonomous exploit agents test hundreds of attack patterns, and code-aware exploitation uses the source to understand exactly why a check fails.

# Confirmed Broken Object Level Authorization exploit
curl -X GET 'https://api.company.com/api/v2/users/8472/profile' \
  -H 'Authorization: Bearer [user_1234_token]'
# 200 OK, accessed user 8472's profile using user 1234's token

# Impact: any authenticated user can read any other user's PII
# by iterating the user_id. CVSS 8.1 (High)

# Confirmed Broken Object Level Authorization exploit
curl -X GET 'https://api.company.com/api/v2/users/8472/profile' \
  -H 'Authorization: Bearer [user_1234_token]'
# 200 OK, accessed user 8472's profile using user 1234's token

# Impact: any authenticated user can read any other user's PII
# by iterating the user_id. CVSS 8.1 (High)

# Confirmed Broken Object Level Authorization exploit
curl -X GET 'https://api.company.com/api/v2/users/8472/profile' \
  -H 'Authorization: Bearer [user_1234_token]'
# 200 OK, accessed user 8472's profile using user 1234's token

# Impact: any authenticated user can read any other user's PII
# by iterating the user_id. CVSS 8.1 (High)

The code-aware version does more than confirm the bug. It identifies why it exists: the authorization middleware checked for a valid JWT but never verified that the requesting user had permission to access the specific user_id in the path.

Phase 4: Post-exploitation, demonstrating the chain

Single vulnerabilities rarely cause catastrophic breaches. This phase shows how an initial foothold becomes a deeper compromise, testing privilege escalation, lateral movement, and data exfiltration.

# Step 1: the BOLA exploit reaches user 8472, who happens to be an admin
curl -X GET 'https://api.company.com/api/v2/users/8472/profile' \
  -H 'Authorization: Bearer [basic_user_token]'
# Response includes: "role": "admin", "api_key": "sk_live_..."

# Step 2: the stolen admin key exports the full user table
curl -X POST 'https://api.company.com/api/v2/admin/users/export' \
  -H 'X-API-Key: sk_live_...'
# Response: CSV with 2.3M user records

# Step 1: the BOLA exploit reaches user 8472, who happens to be an admin
curl -X GET 'https://api.company.com/api/v2/users/8472/profile' \
  -H 'Authorization: Bearer [basic_user_token]'
# Response includes: "role": "admin", "api_key": "sk_live_..."

# Step 2: the stolen admin key exports the full user table
curl -X POST 'https://api.company.com/api/v2/admin/users/export' \
  -H 'X-API-Key: sk_live_...'
# Response: CSV with 2.3M user records

# Step 1: the BOLA exploit reaches user 8472, who happens to be an admin
curl -X GET 'https://api.company.com/api/v2/users/8472/profile' \
  -H 'Authorization: Bearer [basic_user_token]'
# Response includes: "role": "admin", "api_key": "sk_live_..."

# Step 2: the stolen admin key exports the full user table
curl -X POST 'https://api.company.com/api/v2/admin/users/export' \
  -H 'X-API-Key: sk_live_...'
# Response: CSV with 2.3M user records

A medium-severity authorization flaw becomes critical when it chains into admin access and mass exfiltration. Severity lives in the chain, not the isolated finding.

Phase 5: Reporting, audit-grade documentation

The deliverable is a compliance-aligned report where every finding carries a working PoC, a CVSS score with vector, control mapping, root-cause analysis traced to the exact code, remediation guidance, and re-test results.

Because every finding ships with a working curl PoC, the false-positive rate is near zero. If the exploit does not run, it is not a finding.

Black Box vs White Box vs Gray Box

The knowledge you give the tester decides what gets found. We go deep on all three in Black Box vs White Box vs Gray Box Penetration Testing. Here is the practical summary.

• Black box gives the tester zero internal knowledge, no credentials, no code. It is right for annual external-resistance checks, testing third-party SaaS you do not control, and validating perimeter defenses. But it is limited to unauthenticated flows, so it cannot validate authorization boundaries or business logic, and it misses the middleware-ordering bug that only shows up in the code.

• White box gives full source, architecture, and credentials for every role. It uniquely finds logic vulnerabilities that need code-level understanding, cryptographic flaws, and side-channel leakage. The cost is coordination: repository access, architecture walkthroughs, and engineer time, which makes it impractical to run continuously, and it can surface theoretical findings that assume unrealistic attacker knowledge.

• Gray box gives authenticated access plus partial code intelligence, enough to understand API structure, data flows, and business logic without full source. It mirrors the most realistic threat model, an attacker with a compromised account, and it is the modern default. Most critical SaaS vulnerabilities require authenticated access to exploit: Broken Object Level Authorization, IDOR, and GraphQL over-fetching all assume valid credentials.

Tools and Approaches: Firms vs Scanners vs AI-Native Platforms

The three categories are not interchangeable. Each trades depth, speed, and cost differently.

• Traditional firms bring deep contextual analysis, custom attack scenarios, and named-consultant credibility (OSCP, GWAPT, GPEN). The trade-off is a six-to-eight-week engagement at $50k to $200k, delivering point-in-time findings that are already stale when they arrive. Best for annual compliance, pre-IPO validation, and novel attack surfaces.

• Automated scanners are fast (hours), cheap ($5k to $20k a year), repeatable, and CI/CD-friendly. But they generate high false-positive noise, cannot reason about attack chains, struggle with authenticated flows and GraphQL, and see HTTP responses rather than source. Best for continuous monitoring of known patterns and PCI ASV scanning. This is the vulnerability-scanning-versus-testing distinction that decides what you can actually rely on.

• AI-native platforms combine the two: code-aware gray box that understands the codebase, autonomous exploit-chain construction, unlimited retesting, and performance-based pricing. The automated pentesting guide covers how they run. The trade-off is integration overhead and the governance of granting offensive agents code access.

From Point-in-Time Reports to a Continuous Attack-and-Defend Loop

The five-phase process is sound, but run once a year it describes a system that stopped existing a few hundred deploys ago. The shift that matters is running that process as a continuous loop, and it changes the question a security team asks from "how severe is this finding?" to "can this actually be reached?"

That reframing is the whole point. A vulnerable dependency, scanned alone, is one line in an SCA report. Placed in a graph that connects your repositories, containers, cloud resources, and exposed subdomains, it becomes a dependency pulled into a backend service, shipped in a container, running behind a load balancer that exposes a public endpoint. Severity lives in reachability, and a finding without a reachable path is an educated guess.

The loop runs in five stages, each feeding the next:

1. Model. Build one graph from internal signals (code, dependencies, secrets, cloud config, identity) and external signals (domains, open ports, live endpoints, leaked credentials, threat intelligence), and rebuild it on every commit and infrastructure change.

2. Attack. Autonomous agents attempt attack paths against the reachable surface, recording what worked, what failed, and which controls held.

3. Prove. A path validated end to end is marked proven. An unvalidated path stays labeled considered, so the report never overstates what was demonstrated.

4. Fix and reset. The root cause is remediated (not just the exposed host) and the same path is re-tested to confirm it is closed.

5. Learn. The verified pattern is abstracted and fed back into the model, so a later commit that reopens the path gets caught.

The distinction between proven and considered is what keeps the output honest. A proven path drives immediate remediation. A considered path tells the team where the model will test next, rather than inflating the report with theoretical criticals. And because the loop records the full testing trail, every call, command, timestamp, and response code, an engineer can reproduce a path before fixing it, and an auditor gets evidence of exactly what was tested and when, instead of taking a PDF on trust.

Why composition is the vulnerability: a real CVE

The clearest proof of why this approach matters is a vulnerability where every component passed review and the composition was the flaw. CodeAnt AI's security research team found an authentication bypass in the widely used Java library pac4j-jwt, where an attacker could authenticate as any user, including an administrator, using nothing but the server's public RSA key. It was assigned CVE-2026-29000 with a CVSS score of 10.0.

No single piece was broken. The JWT specification allows unsigned tokens, the underlying library behaved correctly, and pac4j's null check was correct in isolation. Authentication disappeared only where those pieces met. That is exactly the failure class a file-level tool cannot see and a composition-aware loop is built to find. The full breakdown is in the CodeAnt security research writeup.

Integrating Pentesting Into Your Workflow

Continuous testing is trigger-based, not calendar-based. Run a test within 48 hours of a high-priority change (new authentication or authorization logic, a new data store, a new public endpoint, a new third-party integration), within a week or two of a medium change (major feature, framework upgrade, infrastructure reconfiguration), and on a schedule for full-scope retests and compliance audits.

Route findings by real risk: a working PoC at CVSS 9.0-plus is a P0 with a 48-hour fix target, CVSS 7.0 to 8.9 is a P1 for the sprint, and everything else batches into technical debt. Then wire the retest loop so a fix is actually validated:

# .github/workflows/pentest-retest.yml
name: Retest critical vulnerability
on:
  pull_request:
    types: [labeled]
jobs:
  retest:
    if: contains(github.event.pull_request.labels.*.name, 'pentest-fix')
    steps:
      - name: Trigger automated retest
        run

# .github/workflows/pentest-retest.yml
name: Retest critical vulnerability
on:
  pull_request:
    types: [labeled]
jobs:
  retest:
    if: contains(github.event.pull_request.labels.*.name, 'pentest-fix')
    steps:
      - name: Trigger automated retest
        run

# .github/workflows/pentest-retest.yml
name: Retest critical vulnerability
on:
  pull_request:
    types: [labeled]
jobs:
  retest:
    if: contains(github.event.pull_request.labels.*.name, 'pentest-fix')
    steps:
      - name: Trigger automated retest
        run

The developer fixes the root cause, the PR merges, the retest re-runs the original exploit, and the finding auto-closes if the exploit now fails or reopens with evidence if it does not. The closed path stays in the model as a recurrence guard. We cover the cadence case in full in Continuous vs Annual Penetration Testing.

A Decision Framework by Organization Profile

The right mix depends on how fast you ship and what governs you.

• A 100 to 300 developer SaaS shipping daily: gray-box continuous testing, weekly automated plus a monthly full validation, with a quarterly manual supplement.

• Enterprise under SOC 2 or ISO 27001: an initial comprehensive white-box assessment, then gray-box continuous monitoring for the ongoing evidence auditors want.

• Pre-IPO readiness: a premium firm for credibility plus an AI platform for continuous validation through the raise.

• Greenfield product: gray box from day one, then a comprehensive white-box review before launch.

• Post-breach hardening: immediate black and gray box within 48 hours, then continuous testing indefinitely.

  

For most teams deploying more than monthly with compliance requirements, the answer is a hybrid: an annual third-party pentest for independent audit validation, plus a continuous code-aware platform that tests every deployment, retests without fees, and delivers code-level fixes. If you are writing the requirements for either, the RFP template has the clauses to demand.

Stop Shipping Findings You Cannot Prove

Penetration testing exists to prove which vulnerabilities an attacker can actually exploit in production, and the highest-ROI version is gray box that combines codebase intelligence with adversarial reconnaissance, focused on the authenticated flows where real business logic lives. But the report is not the finish line. The programs that actually reduce breach risk close the loop from finding to fix to re-test, continuously, at the speed the team ships.

That is what CodeAnt AI is built to do. It builds one living model of your system from the inside and the outside, continuously attacks it, and proves which paths reach critical data, separating what is proven from what is merely considered. Every finding lands with a working PoC, the exact file and line, and a full audit trail an engineer can reproduce and an auditor can verify. It fixes at the root cause, re-tests to confirm the path is closed, and keeps it in the model so a later commit cannot silently reopen it. Retests are unlimited, and you pay only when a high or critical is confirmed exploitable.

Where to start this week

Pick your single highest-risk service, the one shipping most often and touching customer data, and run one gray-box scan scoped to what changed since your last test. Require a working PoC for anything it calls critical, and separate the proven paths from the considered ones. That single exercise tells you, with evidence rather than a severity score, exactly which findings could actually reach your data.

Run a free code-aware pentest →

Related reading

• Black Box vs White Box vs Gray Box Penetration Testing: the knowledge models in full

• What Is VAPT? Vulnerability Assessment vs Penetration Testing: why scanning and testing are not the same thing

• Automated Penetration Testing: how the continuous version of this process runs

• Continuous vs Annual Penetration Testing: the cadence case, with the ROI math

• Offensive Security vs Penetration Testing: where the process sits inside the wider discipline