DEV Community: CodeAnt AI

Why Your $6,500 Penetration Test Will Cost You More Than the $47,000 One

Amartya Jha — Wed, 09 Sep 2026 11:09:58 +0000

Two penetration testing quotes land in your inbox.

One says $6,500.

The other says $22,000.

Both vendors say they use AI. Both promise comprehensive coverage. Both have credible-looking reports, experienced consultants, and a convincing sales call.

So why is one more than 3× the price?

Because “penetration test” isn't a standardized unit of work.

The difference usually isn't the PDF at the end. It's everything that happens before the PDF exists: how much of the attack surface gets mapped, how deeply authentication and authorization are tested, whether findings are manually validated, whether vulnerabilities are chained into attack paths, whether source code is reviewed, and what happens after the report lands.

This matters even more when the pentest is being used for compliance, enterprise security reviews, or a customer audit.

A cheap assessment can absolutely be useful. A $6,500 test isn't automatically bad, just as a $22,000 test isn't automatically good.

The question is:

What are you actually buying at each price point?

The Quick Numbers

For planning purposes, penetration testing in 2026 can range from roughly $3,000 for a limited external assessment to $100,000+ for a large, integrated engagement covering applications, APIs, infrastructure, source code, and multiple testing perspectives.

Penetration test type	Typical 2026 planning range
Limited black box / external assessment	$3,000–$8,000
Full black box web application assessment	$8,000–$25,000
Gray box / authenticated assessment	$10,000–$40,000
White box / source code assessment	$15,000–$60,000
Integrated black + gray + white box	$25,000–$100,000+
Continuous / recurring assessment	$5,000–$20,000/month

These aren't standardized market prices. Actual pricing varies substantially by scope, application complexity, number of assets, number of roles, source-code size, infrastructure, methodology, tester involvement, and deliverables.

And that's exactly why comparing two quotes by the final number alone doesn't work.

The Scope Is Usually Where the Difference Starts

“Web application penetration test” sounds specific.

It isn't.

One vendor might mean:

One production application and its public login page.

Another might mean:

The web application, API, authenticated endpoints, staging environment, cloud assets, JavaScript bundles, authentication flows, and all discovered subdomains.

Those are completely different engagements.

Before comparing prices, turn the scope into something measurable.

Ask:

How many applications are included?
Which production and staging environments?
Which domains and subdomains?
How many APIs and endpoints?
Are authenticated endpoints included?
How many user roles?
Is multi-tenant isolation tested?
Is cloud infrastructure included?
Are source repositories included?
Are third-party integrations in scope?
What is explicitly excluded?

A written scope document is more useful than a paragraph in a sales proposal.

Methodology Depth Changes the Price

The second major variable is how the testing is performed.

Two vendors can test the same application and produce very different results.

A shallow engagement might look like:

Run automated scanners.
Identify vulnerable versions.
Match responses against known signatures.
Generate findings.
Deliver a PDF.

A deeper assessment might involve:

Passive reconnaissance.
Attack-surface enumeration.
Subdomain and cloud asset discovery.
API endpoint mapping.
Authentication testing.
Authorization testing.
Manual business-logic testing.
Controlled exploitation.
Privilege escalation.
Cross-tenant access testing.
Attack-path construction.
Source-level investigation.
Remediation validation.
Retesting.

The target can be identical.

The amount of work is not.

That's why price alone is a poor proxy for pentest quality.

$3,000–$8,000: Baseline External Testing

At the lower end of the market, you're generally getting a limited external assessment.

The exact methodology varies, but this tier may emphasize:

Automated vulnerability discovery
Known-CVE detection
Technology fingerprinting
Basic port and service enumeration
TLS configuration checks
Common web vulnerabilities
Structured reporting

This can be valuable for establishing baseline visibility.

But buyers should check whether the engagement includes manual exploitation and validation.

A scanner saying:

“Potential SQL injection detected”

is not equivalent to a tester demonstrating that a controllable parameter reaches a SQL query and validating the impact safely.

The distinction is:

potential vulnerability vs. confirmed vulnerability.

If the quote is inexpensive because manual validation isn't included, that's important to know before comparing it with a much more hands-on assessment.

$8,000–$25,000: Full External / Black Box Testing

This is where the engagement can become a genuine methodology-driven external pentest.

Depending on scope, testing may include:

DNS enumeration
Subdomain discovery
Certificate transparency analysis
Port and service enumeration
Web application fingerprinting
JavaScript analysis
Endpoint discovery
API enumeration
Authentication testing
Authorization testing
Common injection classes
SSRF
File upload vulnerabilities
Access-control weaknesses
Business-logic testing
Cloud exposure
Manual exploitation

The important question isn't whether a proposal contains the word “manual.”

Ask what is actually manual.

For example:

Are authenticated API endpoints manually tested?

Are authorization boundaries tested across roles?

Are findings reproduced by a human tester?

Are exploit chains investigated?

Are business-logic workflows tested?

Those questions reveal far more than a generic “OWASP methodology” statement.

$10,000–$40,000: Gray Box / Authenticated Testing

Gray box testing introduces something external testing can't reproduce:

legitimate application context.

Instead of asking only:

“What can an anonymous attacker access?”

the tester can ask:

“What can this authenticated user access that they shouldn't?”

This is where some of the most interesting authorization vulnerabilities appear.

Consider a SaaS application with:

Admin
Manager
Employee
Read-only user

and thousands of tenant-specific resources.

Testing isn't simply:

GET /api/invoices/1234

The tester needs to establish:

User A → Tenant A → Resource A
User A → Tenant B → Resource B
Manager → Admin functionality
Employee → Manager functionality
Read-only → Write functionality

The goal is to determine whether the application's authorization model matches the intended trust boundaries.

This is where vulnerabilities such as BOLA/IDOR, privilege escalation, broken function-level authorization, and cross-tenant access become particularly important.

And the number of roles and workflows can dramatically increase the testing effort.

$15,000–$60,000: White Box / Source Code Testing

Source access changes the problem entirely.

A black box tester sees:

HTTP request
      ↓
HTTP response

A white box tester can investigate:

HTTP request
      ↓
Controller
      ↓
Middleware
      ↓
Authorization check
      ↓
Service
      ↓
Database query
      ↓
Dangerous sink

That makes vulnerabilities visible that may be difficult or impossible to identify externally.

A serious source-code assessment can include:

Authentication implementation
Authorization middleware
API controllers
Input validation
Dataflow analysis
Sensitive sinks
Cryptographic usage
Secrets
Dependency usage
Git history
Infrastructure-as-code
CI/CD configuration
Security-sensitive framework configuration

The depth of this work matters enormously.

“Source code included” doesn't necessarily mean:

“Every line of the repository will be manually reviewed.”

Ask what is actually being analyzed and how findings are traced back to the implementation.

$25,000–$100,000+: Integrated Testing

The most useful full assessments aren't simply:

black box + gray box + white box.

They are integrated.

Information discovered during one phase informs another.

For example:

External recon
      ↓
API discovered
      ↓
Authenticated access obtained
      ↓
Authorization weakness identified
      ↓
Source code traced
      ↓
Attack path constructed
      ↓
Fix implemented
      ↓
Production retest

That produces a much stronger understanding of the actual risk than three disconnected reports.

For a mid-sized SaaS application, an integrated engagement might fall somewhere around $25,000–$50,000.

Larger applications with multiple services, environments, APIs, cloud infrastructure, and complex authorization models can move toward $50,000–$100,000+.

Enterprise-scale testing can go beyond that.

Continuous Testing: $5,000–$20,000/Month

Annual pentesting has an obvious limitation.

It tells you what was exposed when the test happened.

If your engineering team deploys every week, the application tested in January may not resemble the application running in December.

A new API gets deployed.

A new subdomain appears.

A cloud bucket gets created.

An authentication flow changes.

A service gets exposed.

A dependency changes.

The attack surface moves continuously.

Recurring testing addresses that problem by shortening the time between changes and security validation.

It doesn't necessarily replace a comprehensive periodic assessment.

Instead:

Periodic pentest = deep assessment

Continuous testing = ongoing validation

The two can complement each other.

Cost vs. Coverage

Engagement	Typical range	Strongest at finding	Common gap
Automated assessment	$3K–$8K	Known technical weaknesses	Business logic and attack chains
Black box	$8K–$25K	External attack surface	Source-level vulnerabilities
Gray box	$10K–$40K	Authorization and authenticated workflows	Internal implementation details
White box	$15K–$60K	Code-level vulnerabilities	Runtime behavior without execution
Integrated	$25K–$100K+	Cross-layer attack paths	Primarily constrained by scope
Continuous	$5K–$20K/mo	Changes introduced over time	Depth depends on cadence and methodology

The important word in this table is gap.

Every testing model sees some things better than others.

The Finding Quality Test

Here's one of the easiest ways to compare vendors.

Ask for a redacted sample technical finding.

Look at what you're actually getting.

A useful finding should tell an engineer:

What is vulnerable?

Not:

“Application may be vulnerable to authorization issues.”

But:

GET /api/v1/invoices/{id} does not verify that the authenticated user belongs to the invoice's tenant.

How was it validated?

Show the relevant request, response, prerequisites, and safe proof of impact.

Why does it happen?

For example:

Request
  ↓
Controller
  ↓
Invoice ID accepted
  ↓
Database lookup by ID
  ↓
Tenant ownership never checked

What is the impact?

Can an attacker read another tenant's invoice?

Modify it?

Delete it?

Access sensitive customer data?

How should it be fixed?

Ideally, the remediation guidance points engineers toward the actual control that needs to change.

This is where two reports with the same number of findings can have radically different value.

The Attack-Path Question

A pentest shouldn't always treat every vulnerability as an isolated row in a spreadsheet.

Consider:

Low-privilege account
        ↓
Information disclosure
        ↓
Internal endpoint discovered
        ↓
Authorization bypass
        ↓
Sensitive API access
        ↓
Credential exposure
        ↓
Cloud privilege escalation

Each individual finding might have a moderate severity.

Together, they can represent a serious attack path.

Ask the provider:

Do you identify and validate chained attack paths, or do you report vulnerabilities independently?

That answer can be more revealing than the number of tools listed in the proposal.

The Retest Question

This is another major difference between quotes.

Ask:

Is retesting included?

And more importantly:

What does “retest” actually mean?

A useful retest should verify that:

The vulnerability is no longer exploitable.
The underlying security control works as intended.
The fix didn't introduce another bypass.
The change is present in the environment that actually matters.

A staging retest doesn't necessarily prove that production is fixed.

Also clarify how many retest cycles are included and whether they are billed separately.

The Compliance Deliverables Gap

The pentest itself isn't always the only deliverable you need.

Depending on the framework and auditor, you may need supporting evidence around:

Scope
Testing dates
Findings
Severity
Remediation
Retesting
Final status
Risk acceptance
Evidence handling
Data retention
Data deletion

Don't assume these documents are automatically included because the proposal says “compliance-ready report.”

Ask what you actually receive.

And ask how sensitive information collected during testing is handled after the engagement.

The Checklist to Put Beside Every Quote

Before signing a pentest SOW, make every vendor answer the same questions.

Scope

Which applications?
Which environments?
Which domains and subdomains?
Which APIs?
Which third-party integrations?
What's explicitly excluded?

Authentication

Are login flows tested?
MFA?
Password reset?
Session management?
Tokens?
Account recovery?

Authorization

Horizontal privilege escalation?
Vertical privilege escalation?
BOLA/IDOR?
Cross-tenant access?
Role boundaries?

Application logic

Manual business-logic testing?
Workflow manipulation?
Race conditions?
Abuse cases?

Infrastructure

AWS?
Azure?
GCP?
Kubernetes?
Containers?
IAM?
Cloud storage?

Source

Is source code included?
How much is reviewed?
Is dataflow analysis performed?
Is Git history analyzed?
Is IaC reviewed?

Validation

Are findings manually confirmed?
Is controlled exploitation performed?
Are attack chains investigated?
Is exploitability demonstrated safely?

Retesting

Is it included?
How many cycles?
Is production retested?
Is a final retest report provided?

Evidence

What reports are included?
What compliance documentation ships with the engagement?
How is sensitive test data stored?
When is it deleted?
Is deletion documented?

This turns a vague pricing comparison into an actual coverage comparison.

So, Is the $22,000 Pentest Worth It?

Not necessarily.

The $22,000 test isn't automatically better.

And the $6,500 test isn't automatically a waste of money.

The better question is:

What risk does each engagement leave untested?

If the $6,500 assessment covers only unauthenticated external scanning while the $22,000 engagement includes authenticated APIs, authorization testing, manual business logic testing, cloud assets, exploit validation, attack-path analysis, and retesting, you're not comparing two prices for the same product.

You're comparing two different security assessments.

That's the part of the pricing conversation that often gets lost.

Don't compare the number at the top of the quote. Compare the attack surface, methodology, validation, evidence, and lifecycle coverage underneath it.

FAQ

How much does a penetration test cost in 2026?

Planning ranges can start around $3,000 for limited external testing and exceed $100,000 for large integrated assessments. The actual price depends heavily on scope, application complexity, authenticated workflows, infrastructure, source-code access, methodology, and deliverables.

Why can two pentest quotes differ by 3×?

Because “penetration test” doesn't define a standardized amount of work. One quote may include automated scanning and limited validation, while another may include authenticated testing, source review, manual business logic testing, exploit validation, attack-path analysis, and retesting.

Is a cheap penetration test useless?

No. A limited assessment can provide useful baseline visibility. The important thing is understanding what it is designed to detect and what it explicitly doesn't cover.

Should retesting be included?

Ideally, yes, or at least the retesting process and cost should be explicit in the SOW. Otherwise, the initial quote may not represent the total cost of completing the testing lifecycle.

Is black box, gray box, or white box testing best?

None is universally “best.” Black box provides an outside-in view, gray box is particularly useful for authenticated authorization and workflow testing, and white box exposes implementation-level weaknesses. For high-risk applications, combining perspectives can provide much stronger coverage.

This piece is adapted from a longer breakdown on the CodeAnt AI blog, including a detailed quote-comparison framework and an analysis of alternative penetration testing pricing models.

External Penetration Testing in 2026: A Technical Methodology, Tool Stack, and Attack Surface Guide

Amartya Jha — Wed, 09 Sep 2026 10:46:46 +0000

External penetration testing is often reduced to a familiar sequence:

nmap → nuclei → Burp → report

That workflow is useful, but it misses the hardest part of the engagement.

Finding the assets worth testing.

A production application is rarely the entire external attack surface.

There may be a staging environment on another subdomain, an old API version on a different hostname, a forgotten VPN portal, a cloud storage bucket, a CI/CD interface, an exposed database, or a service that was intended to be internal but is reachable from the internet.

If the tester doesn't discover those assets, none of the vulnerability scanners matter.

This guide presents a technical external penetration testing methodology from the perspective of an attacker starting with only a target organization and its public footprint.

The focus is on:

Passive reconnaissance
DNS and certificate intelligence
Attack-surface discovery
Active host and port enumeration
Web and API discovery
Vulnerability identification
Manual validation
Safe exploitation
Cloud exposure
Commonly missed attack paths
Tool selection
Reporting evidence

The commands below are intended for systems you are authorized to test. Production systems should be tested within the agreed scope, rate limits, and rules of engagement.

1. Define the Attack Surface Before Testing It

The first mistake in external penetration testing is treating the client's domain as the attack surface.

It isn't.

The domain is the starting point.

The actual attack surface can look more like:

company.com
├── www.company.com
├── app.company.com
├── api.company.com
├── api-v2.company.com
├── staging.company.com
├── dev.company.com
├── vpn.company.com
├── sso.company.com
├── git.company.com
├── ci.company.com
├── monitoring.company.com
└── legacy.company.com

Cloud
├── public S3 buckets
├── public load balancers
├── exposed databases
├── Kubernetes APIs
└── forgotten public IPs

The first objective is therefore:

Build an inventory of externally reachable assets before attempting to exploit them.

This is where passive OSINT and attack-surface discovery become more important than simply running a vulnerability scanner.

2. Phase One: Passive Reconnaissance

Passive reconnaissance gathers information without directly probing the target infrastructure.

The goal is to answer:

What domains belong to the organization?
What IP ranges are associated with it?
What subdomains exist?
What technologies are publicly visible?
What third-party services are being used?
What infrastructure has historically existed?
Have credentials or secrets appeared in public repositories?

2.1 DNS Enumeration

Start with the basic DNS records.

dig +short company.com A
dig +short company.com AAAA
dig +short company.com MX
dig +short company.com NS
dig +short company.com TXT

Each record can provide a different piece of infrastructure intelligence.

A / AAAA

These identify IPv4 and IPv6 addresses associated with the domain.

MX

Mail records can reveal:

Microsoft 365
Google Workspace
third-party email providers
dedicated mail infrastructure

TXT

TXT records commonly contain:

SPF configuration
domain verification records
SaaS integrations
cloud-provider verification
email security configuration

NS

Nameservers identify the DNS infrastructure responsible for the domain.

3. Test for DNS Zone Transfers

A misconfigured authoritative DNS server may allow an AXFR request.

dig axfr company.com @ns1.company.com

A successful response can disclose the entire DNS zone.

For example:

dev.company.com
staging.company.com
internal.company.com
db01.company.com
vpn.company.com
old-api.company.com

A failed AXFR is expected.

A successful transfer is materially different because it can expose internal naming conventions and infrastructure that may not appear through ordinary enumeration.

4. Certificate Transparency

Certificate Transparency logs are one of the most useful passive sources for discovering forgotten hostnames.

A simple crt.sh query:

curl -s "https://crt.sh/?q=%25.company.com&output=json" |
    jq -r '.[].name_value' |
    sort -u

Normalize the results before continuing.

curl -s "https://crt.sh/?q=%25.company.com&output=json" |
    jq -r '.[].name_value' |
    sed 's/\*\.//g' |
    sort -u

Certificate data can reveal hosts that aren't linked from the organization's main website.

For example:

app.company.com
api.company.com
staging.company.com
qa.company.com
legacy.company.com

The important point is that discovery is not vulnerability confirmation.

staging.company.com isn't a finding simply because it exists.

It is an asset that now needs testing.

5. ASN and IP Range Discovery

If the engagement includes network infrastructure, determine which public ranges are associated with the organization.

For example:

whois -h whois.radb.net -- '-i origin AS12345' |
    grep route:

ASN information can reveal infrastructure that isn't directly associated with the primary domain.

You can then use the resulting ranges as input to the active reconnaissance phase.

This is particularly useful for organizations operating their own infrastructure rather than relying entirely on cloud providers.

6. Historical URL Discovery

Current crawling only tells you what exists now.

Historical sources can reveal endpoints that existed previously.

Two common tools are:

gau company.com

and:

waybackurls company.com

Then filter for interesting paths:

gau company.com |
    grep -Ei '\.(json|xml|config|bak|sql|zip|env)$'

Or search for administrative functionality:

gau company.com |
    grep -Ei '(admin|debug|internal|api|graphql|swagger)'

Historical URLs are particularly useful because applications evolve.

An endpoint may disappear from the current interface while remaining deployed.

7. Public Repository Reconnaissance

Public source repositories can expose much more than source code.

Search for:

API keys
cloud credentials
internal hostnames
database URLs
deployment scripts
.env files
private package registries
CI/CD configuration

For example:

"company.com" API_KEY
"company.com" AWS_SECRET
"company-internal"
"database.company.com"

Secret scanning tools can help automate this:

trufflehog github --org=company

A discovered credential still needs validation.

Don't assume that every string matching AWS_SECRET is an active credential.

The tester should establish:

Is it syntactically valid?
Is it still active?
What identity does it belong to?
What permissions does it have?
Does it provide access to in-scope resources?

That turns a potential secret leak into a measurable security finding.

8. Build the Initial Asset Inventory

At this stage, consolidate the passive results.

A useful working inventory might look like:

hostname                  IP              source
----------------------------------------------------------
www.company.com           203.0.113.10    DNS
api.company.com           203.0.113.20    CT
staging.company.com       203.0.113.30    CT
vpn.company.com           203.0.113.40    DNS
legacy.company.com        203.0.113.50    Wayback

Don't immediately start exploiting.

First remove:

duplicates
third-party assets outside scope
CDN infrastructure
unrelated shared hosting
dead DNS records

Then resolve the remaining hosts.

9. Phase Two: Active Reconnaissance

Now the tester starts interacting directly with the target.

The objective is to determine:

Which hosts are alive?
Which ports are open?
What services are running?
Which applications are exposed?
Which technologies are being used?
Which endpoints exist?

10. Subdomain Enumeration

Use multiple discovery sources where appropriate.

For example:

subfinder -d company.com -silent -o subdomains.txt

Amass can provide additional enumeration:

amass enum -passive -d company.com -o amass.txt

Merge the results:

cat subdomains.txt amass.txt |
    sort -u |
    tee all_subdomains.txt

Then resolve and probe them:

cat all_subdomains.txt |
    httpx -silent \
    -status-code \
    -title \
    -tech-detect \
    -follow-redirects \
    -o live_hosts.txt

Now the tester has something much more useful than a raw subdomain list:

https://app.company.com       200   Customer Portal
https://api.company.com       200   API
https://staging.company.com   200   Staging
https://vpn.company.com       302   VPN Login

11. Full Port Enumeration

For identified IP addresses:

nmap -p- --open -sV -sC \
    -oA nmap_full_scan \
    [TARGET_IP]

For large ranges, scanners such as RustScan can accelerate initial port discovery before handing results to Nmap for service detection.

The important distinction is:

Port discovery tells you where something is listening.

Service enumeration tells you what it is.

For example:

22/tcp    SSH
80/tcp    HTTP
443/tcp   HTTPS
3306/tcp  MySQL
6379/tcp  Redis

Each one becomes a separate testing path.

12. Prioritize the Interesting Ports

Not every open port deserves equal attention.

High-interest services include:

21      FTP
22      SSH
23      Telnet
25      SMTP
53      DNS
80      HTTP
443     HTTPS
445     SMB
1433    MSSQL
3306    MySQL
3389    RDP
5432    PostgreSQL
5900    VNC
6379    Redis
9200    Elasticsearch
2375    Docker API
6443    Kubernetes API

But don't turn this list into a severity checklist.

An exposed port is an observation.

The actual finding depends on what is accessible through it.

For example:

5432/tcp open PostgreSQL

is not equivalent to:

5432/tcp open PostgreSQL
Authentication disabled
Unauthenticated database access confirmed
Production data accessible

The second is a security finding.

13. Web Technology Fingerprinting

For HTTP services:

httpx -u https://company.com \
    -status-code \
    -title \
    -tech-detect \
    -server \
    -content-length

Look for:

framework fingerprints
server versions
exposed headers
reverse proxies
CDNs
application frameworks
CMS platforms
API technologies

Technology identification can influence the next stage of testing.

For example:

nginx
PHP
Laravel
GraphQL
WordPress
Spring Boot
ASP.NET

each suggests a different set of likely endpoints and vulnerabilities.

14. Directory and Endpoint Discovery

Once an application is identified, enumerate paths.

ffuf -u https://company.com/FUZZ \
    -w /usr/share/wordlists/dirb/common.txt \
    -mc 200,204,301,302,307,401,403

For extensions:

ffuf -u https://company.com/FUZZ \
    -w wordlist.txt \
    -e .php,.json,.xml,.txt,.bak,.zip

Interesting responses include:

200 OK
401 Unauthorized
403 Forbidden
500 Internal Server Error

A 403 can be interesting because it proves the endpoint exists.

A 500 can also be useful because error handling sometimes exposes:

stack traces
framework versions
database errors
internal paths
debug information

15. API Enumeration

Modern external attack surfaces are increasingly API-heavy.

Start by identifying:

/api
/api/v1
/api/v2
/graphql
/swagger
/openapi.json
/api-docs

Search historical URLs:

gau company.com |
    grep -Ei '/api/|graphql|swagger|openapi'

If an OpenAPI specification is publicly accessible:

curl -s https://api.company.com/openapi.json

You may immediately obtain:

endpoint names
parameters
object identifiers
authentication schemes
request methods
API versions

This can dramatically improve manual testing.

16. Authentication Testing

External authentication testing should go beyond:

“Does the login page exist?”

Test the complete authentication boundary.

Questions include:

Is MFA enforced?
Can MFA be bypassed?
Are password-reset tokens predictable?
Do reset links expire?
Can sessions be reused?
Are tokens invalidated after logout?
Are API tokens scoped?
Are legacy authentication endpoints still active?
Do mobile and web authentication paths behave differently?

A common mistake is testing only the primary web login.

The real authentication surface may include:

/web/login
/api/login
/mobile/auth
/oauth/token
/sso/login
/password/reset
/admin/login

17. Authorization Testing

Authorization flaws are often more valuable than generic version-based findings because they depend on application logic.

Consider an API:

GET /api/users/1001

Change the identifier:

GET /api/users/1002

If user 1001 can access user 1002's information, the issue is an Insecure Direct Object Reference or broader broken object-level authorization problem.

The same principle applies to:

/orders/1001
/invoices/1001
/projects/1001
/files/1001
/payments/1001

The tester should ask:

Does the server verify that this authenticated principal is actually authorized to access this object?

Changing an ID and receiving a 200 response isn't enough by itself.

The response needs to demonstrate unauthorized access.

18. Test Alternate API Versions

One of the easiest blind spots is assuming that:

/api/v2

has the same security controls as:

/api/v1

Test both.

Look for differences in:

authentication
authorization
input validation
rate limiting
object-level access controls
error handling

An old API doesn't need to be linked from the frontend to remain exploitable.

If it is internet-accessible, it is part of the attack surface.

19. Vulnerability Scanning

Once the attack surface is mapped, automated vulnerability detection becomes much more useful.

For example:

nuclei -l live_hosts.txt \
    -severity critical,high,medium \
    -tags cve,exposure,misconfig \
    -o nuclei.txt

Run scanners against known technology where possible rather than blindly scanning everything.

The output should become a triage queue.

Not the final report.

20. Scanner Finding vs Real Finding

Consider:

Nuclei:
Apache CVE detected

That's a lead.

The validation workflow should be:

Scanner match
     ↓
Identify exact version
     ↓
Confirm affected component
     ↓
Determine whether vulnerable feature is reachable
     ↓
Reproduce safely
     ↓
Establish impact
     ↓
Collect evidence

Only then should it become a confirmed finding.

This matters because scanners can produce false positives from:

backported patches
incorrect version detection
reverse proxies
custom builds
disabled vulnerable modules
unreachable vulnerable functionality

21. Validate Exposed Redis

If Redis is exposed:

redis-cli -h [TARGET_IP] ping

A response of:

PONG

shows connectivity.

It doesn't automatically prove unauthenticated administrative access.

The next question is whether commands requiring authentication are permitted.

For example, safely establish the access level permitted under the engagement rules.

The finding should ultimately describe what access was demonstrated, not merely that port 6379 was open.

22. Validate Database Exposure

For a PostgreSQL service:

psql -h [TARGET_IP] -U [TEST_USER] -d [DATABASE]

For MySQL:

mysql -h [TARGET_IP] -u [TEST_USER] -p

The purpose is to establish whether:

authentication is required
credentials work
access is restricted
the exposed account has excessive privileges
sensitive data is accessible

Never dump unnecessary production data simply to prove access.

A small, controlled proof is generally enough.

23. Exposed Management Interfaces

Management systems deserve special attention because they often have significantly more privileges than ordinary applications.

Common examples:

Jenkins
Grafana
Kibana
Argo CD
Rancher
GitLab
Prometheus
Docker
Kubernetes

The tester should determine:

Is the interface publicly accessible?
Is authentication required?
What identity is created after authentication?
What actions can that identity perform?
Can the interface reach internal infrastructure?

A publicly reachable Jenkins login page isn't automatically a vulnerability.

An unauthenticated Jenkins instance allowing job execution is an entirely different problem.

24. Cloud Attack Surface

External testing increasingly means testing cloud infrastructure rather than traditional perimeter devices.

Common areas include:

Object storage

Check for:

public listing
public reads
public writes
unintended object exposure
backup files

Public load balancers

Identify:

backend services
alternate listeners
forgotten ports
administrative endpoints

Cloud-hosted databases

Look for publicly reachable:

RDS
Cloud SQL
MongoDB
Redis
Elasticsearch

Kubernetes

Look for exposed:

Kubernetes API
Dashboard
Ingress controllers
Metrics
Management interfaces

Cloud security failures often come from resources that were created temporarily and never removed.

25. Public S3 Bucket Discovery

Bucket discovery can begin with known naming patterns, but DNS and application source code can provide better candidates.

For a bucket you are authorized to test:

aws s3 ls s3://bucket-name --no-sign-request

A successful listing demonstrates public listing access.

Then determine whether objects are publicly readable.

Do not assume that because a bucket exists, all of its contents are public.

Test the actual permission boundary.

The distinction between:

bucket exists

and:

anonymous principal can list and download objects

is the difference between asset discovery and a confirmed exposure.

26. Exposed `.git` Directories

A public .git directory can potentially expose repository history.

Check:

curl -I https://company.com/.git/HEAD

If accessible:

curl https://company.com/.git/HEAD

Depending on what is exposed, an attacker may be able to reconstruct repository information.

The security impact depends on what the repository contains.

Potentially sensitive material includes:

source code
credentials
deployment configuration
internal endpoints
historical secrets

27. Exposed `.env` Files

A simple check:

curl -i https://company.com/.env

A response containing environment configuration can be severe if it exposes active credentials.

Potential entries include:

DB_HOST=
DB_USERNAME=
DB_PASSWORD=
AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=
STRIPE_SECRET_KEY=
JWT_SECRET=

Again, the key question is whether the values are actually active and what access they provide.

A leaked secret should be validated carefully and reported with enough evidence to demonstrate impact without unnecessarily exposing the secret itself.

28. Subdomain Takeover Testing

A typical workflow:

subdomain discovered
        ↓
DNS record inspected
        ↓
CNAME points to third-party service
        ↓
resource no longer exists
        ↓
service confirms resource can potentially be claimed
        ↓
controlled validation

A dangling CNAME alone is not sufficient evidence.

The tester needs to establish whether the third-party resource is actually claimable.

29. The Findings Automation Commonly Misses

The most interesting external pentest findings aren't always CVEs.

They are often inconsistencies.

Different authorization between UI and API

The UI checks permission A.

The API checks permission B.

Production and staging have different security controls

Production requires MFA.

Staging doesn't.

API v1 and v2 implement authorization differently

One version checks object ownership.

The other trusts the object ID supplied by the client.

Legacy endpoints remain accessible

The frontend stopped using /api/v1.

The server never stopped serving it.

Forgotten infrastructure has stronger connectivity than expected

A staging server is internet-facing but also has access to internal production services.

These findings require understanding relationships, not just signatures.

That's why manual testing remains essential even when automated scanning is extensive.

30. Attack-Path Thinking

The strongest pentests don't treat findings as isolated rows in a spreadsheet.

They ask whether findings can be chained.

For example:

Forgotten subdomain
        ↓
Staging application
        ↓
Debug endpoint
        ↓
Cloud credential exposure
        ↓
Overprivileged IAM identity
        ↓
Production storage access

None of the individual observations necessarily represents the complete impact.

The chain does.

Another example:

Exposed management interface
        ↓
Weak authentication
        ↓
Administrative access
        ↓
CI/CD job execution
        ↓
Cloud credentials
        ↓
Production environment

This is why external penetration testing is different from simply producing a vulnerability scan.

The tester is trying to understand what an attacker can do with the access they obtain.

31. External Pentesting Tool Stack

A practical toolchain might look like this:

Phase	Tools	Purpose
DNS	`dig`, `dnsx`	DNS enumeration
Subdomains	`subfinder`, `Amass`	Host discovery
Certificate data	`crt.sh`	Passive hostname discovery
HTTP probing	`httpx`	Live host identification
Port scanning	`Nmap`, RustScan	Port and service discovery
Web discovery	`ffuf`, Gobuster	Endpoint enumeration
Historical discovery	`gau`, `waybackurls`	Old endpoints
OSINT	Shodan, Censys, theHarvester	Public infrastructure
Vulnerability scanning	Nuclei	CVEs and misconfigurations
Secret detection	TruffleHog	Public credential discovery
Web testing	Burp Suite	Manual HTTP testing
Exploitation	Metasploit	Controlled exploitation
Cloud	AWS/Azure/GCP CLI tools	Cloud validation
SMB/Windows	enum4linux	SMB enumeration

The exact stack should change according to the target.

A SaaS application doesn't need the same workflow as an enterprise network containing VPN concentrators, Windows infrastructure, and exposed management systems.

32. External vs Internal Penetration Testing

These engagements begin from fundamentally different trust assumptions.

	External	Internal
Starting point	Internet	Internal network
Credentials	Usually none	Usually provided or obtained
Recon	OSINT, DNS, public infrastructure	Network and directory enumeration
Primary target	Perimeter	Internal systems
Typical findings	Exposed services, web/API flaws	AD, privilege escalation, lateral movement
Main question	Can an attacker get in?	What can they do after getting in?

An external pentest shouldn't be treated as a cheaper version of an internal pentest.

They model different attack positions.

33. Reporting a Finding Properly

A useful finding should answer five questions:

What is vulnerable?

Identify the exact asset and component.

Where is it?

Provide the hostname, endpoint, port, or resource.

How was it validated?

Give a reproducible proof.

What can an attacker do?

Explain the actual impact.

How should it be fixed?

Provide a practical remediation.

For example, instead of:

Redis exposed to internet — Critical

write:

Unauthenticated Redis instance accessible from the public internet

redis.company.com:6379 accepts unauthenticated commands from an external network. During validation, the tester was able to enumerate the accessible Redis environment without credentials. Network exposure should be restricted to trusted application hosts and authentication should be enforced.

That is substantially more useful.

34. Evidence Matters

Good evidence should allow another engineer to reproduce the finding.

Useful evidence includes:

Request
Response
Hostname
Port
Timestamp
Authenticated identity
Relevant configuration
Minimal proof of impact

Avoid collecting unnecessary sensitive data.

For example, if a database contains 10 million customer records, you don't need to export all 10 million records to prove unauthorized database access.

A single authorized test record or metadata response may be enough.

35. A Practical External Pentest Workflow

Putting everything together:

                 TARGET
                    │
                    ▼
             Passive OSINT
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
         DNS       CT       ASN/IP
          │         │         │
          └─────────┼─────────┘
                    ▼
             Asset Inventory
                    │
                    ▼
          Active Reconnaissance
                    │
          ┌─────────┼─────────┐
          ▼         ▼         ▼
       HTTP       Ports      APIs
          │         │         │
          └─────────┼─────────┘
                    ▼
          Vulnerability Testing
                    │
                    ▼
             Manual Validation
                    │
                    ▼
          Controlled Exploitation
                    │
                    ▼
             Attack-Path Analysis
                    │
                    ▼
                Reporting
                    │
                    ▼
                Retesting

The important part is that each phase informs the next.

Certificate Transparency discovers a hostname.

The hostname resolves to an IP.

The IP exposes a service.

The service identifies an application.

The application exposes an API.

The API contains an authorization flaw.

The authorization flaw provides access to another object.

That is the attack path.

36. What a Good External Pentest Actually Proves

At the end of the engagement, the important question isn't:

How many vulnerabilities did we find?

It's:

What could an external attacker actually accomplish?

A good external penetration test should establish:

What infrastructure is publicly reachable
What applications are exposed
Which services are vulnerable
Which authentication controls can be bypassed
Which authorization boundaries fail
Which sensitive resources are accessible
Which findings can be chained
What level of access an attacker can obtain
What remediation actually closes the attack path

Ten validated findings can be more valuable than 500 scanner alerts.

37. External Penetration Testing in a Continuously Changing Environment

The traditional model is:

Pentest
   ↓
Report
   ↓
Fix
   ↓
Retest
   ↓
Wait
   ↓
Next annual pentest

The problem is the environment changes during the waiting period.

A new hostname can appear tomorrow.

A new API can be deployed next week.

A cloud resource can become public after a configuration change.

A development environment can be exposed without ever entering the original pentest scope.

This is why external attack-surface monitoring is increasingly complementary to periodic penetration testing.

The methodology doesn't fundamentally change.

The cadence does.

Instead of:

discover → test → report → wait

the model becomes:

discover → test → validate → remediate → retest → repeat

CodeAnt AI's analysis of continuous vs. annual penetration testing goes deeper into this difference in testing cadence.

38. External Penetration Testing Checklist

Reconnaissance

[ ] DNS records
[ ] Zone transfer
[ ] Certificate Transparency
[ ] ASN discovery
[ ] IP ranges
[ ] Public repositories
[ ] Secret exposure
[ ] Historical URLs
[ ] Search-engine indexing
[ ] Public cloud resources

Attack Surface

[ ] Subdomains
[ ] Live hosts
[ ] IPv4
[ ] IPv6
[ ] Open ports
[ ] Service versions
[ ] Web technologies
[ ] APIs
[ ] Staging environments
[ ] Legacy applications
[ ] Management interfaces

Web/API

[ ] Authentication
[ ] MFA
[ ] Password reset
[ ] Session management
[ ] Authorization
[ ] IDOR/BOLA
[ ] API versioning
[ ] GraphQL
[ ] File upload
[ ] Debug endpoints
[ ] Sensitive files
[ ] Security headers

Infrastructure

[ ] RDP
[ ] VNC
[ ] SSH
[ ] SMB
[ ] FTP
[ ] Databases
[ ] Redis
[ ] Elasticsearch
[ ] Docker API
[ ] Kubernetes API
[ ] VPN
[ ] CI/CD
[ ] Monitoring interfaces

Cloud

[ ] Public buckets
[ ] Public databases
[ ] Public management interfaces
[ ] Exposed credentials
[ ] IAM permissions
[ ] Forgotten resources
[ ] Cloud metadata exposure

Validation

[ ] Scanner findings manually validated
[ ] False positives removed
[ ] Exploitability demonstrated
[ ] Impact established
[ ] Attack paths analyzed
[ ] Evidence collected
[ ] Remediation documented
[ ] Retesting performed

Frequently Asked Questions

What is external penetration testing?

External penetration testing simulates an attacker operating from outside an organization's network. The tester begins with publicly available information and attempts to discover and exploit internet-facing applications, services, infrastructure, APIs, and cloud resources within the authorized scope.

What tools are used for external penetration testing?

Common tools include Nmap for port and service discovery, subfinder and Amass for subdomain enumeration, httpx for HTTP probing, ffuf and Gobuster for endpoint discovery, Nuclei for automated vulnerability detection, Burp Suite for manual web testing, and tools such as TruffleHog for secret discovery.

No individual tool provides complete coverage. Effective testing combines automated discovery with manual validation.

What should be tested first in an external pentest?

Attack-surface discovery should come before deep vulnerability testing. Start with domains, DNS, certificates, subdomains, IP ranges, cloud resources, historical URLs, and public repositories. Then move into active host discovery, port scanning, application enumeration, and vulnerability testing.

Is an open port automatically a vulnerability?

No. An open port indicates that a service is reachable. Whether that represents a vulnerability depends on the service, authentication, configuration, network controls, patch level, and what an attacker can accomplish after connecting.

What is the difference between vulnerability scanning and penetration testing?

Vulnerability scanning primarily identifies potential weaknesses using automated detection techniques. Penetration testing goes further by manually validating vulnerabilities, testing application logic, demonstrating impact, and determining whether individual weaknesses can be chained into meaningful attack paths.

Why is API testing important in external penetration testing?

Modern applications often expose significant functionality through APIs. APIs may implement authentication and authorization differently from the web interface, and older API versions can remain accessible even after the frontend stops using them. Testing alternate API paths is therefore an important part of external attack-surface analysis.

How often should external penetration testing be performed?

The required frequency depends on the organization's regulatory, contractual, and risk requirements. Periodic manual penetration testing can be supplemented by continuous external attack-surface monitoring to identify newly exposed assets and configuration drift between formal engagements.

Conclusion

External penetration testing is not fundamentally a port-scanning exercise.

It's an exercise in mapping trust boundaries from the outside.

The process starts with passive information:

DNS
Certificates
ASN data
Repositories
Historical URLs
Cloud infrastructure

That becomes an asset inventory.

The inventory becomes active reconnaissance:

Subdomains
IPs
Ports
Services
Applications
APIs

Those discoveries become testing targets.

Then comes the part that requires the most judgment:

Is this actually vulnerable?
Can it be exploited?
What access does it provide?
Can it be chained with another weakness?
What can an attacker ultimately accomplish?

That distinction matters.

A scanner can tell you that port 5432 is open.

A penetration tester determines whether the database is authenticated, what account is accessible, what data is exposed, and whether that access creates a meaningful attack path.

A scanner can discover /api/v1.

A tester determines whether the old API still works, whether authentication is enforced, whether authorization is correct, and whether it exposes functionality that /api/v2 properly protects.

A scanner can identify a staging hostname.

A tester asks why it exists, what it contains, what credentials it accepts, and what systems it can reach.

That is the difference between finding vulnerabilities and understanding an attack surface.

And as cloud infrastructure, APIs, CI/CD systems, and ephemeral environments continue to change, the attack surface is no longer something that can be accurately measured once a year.

The methodology remains:

Discover → Enumerate → Test → Validate → Exploit → Chain → Report → Retest.

The challenge is making sure you're still discovering the right things when the environment changes tomorrow.

IDOR: The Vulnerability Class Your Scanners Will Never Find

Amartya Jha — Tue, 08 Sep 2026 06:57:57 +0000

In 2023, a researcher changed a single number in a URL, /api/orders/10021 to /api/orders/10022, and got back a complete order record belonging to someone else. Name, address, items purchased, last four digits of a payment card. No exploit chain, no malware, no clever payload. Just a missing ownership check.

That's IDOR: Insecure Direct Object Reference. In the OWASP API Security Top 10 it's called BOLA, Broken Object Level Authorization, and it's API1:2023. Different name, same failure: the application confirms you're logged in, but never confirms you're allowed to touch the specific object you asked for.

It's arguably the most consistently present vulnerability class in modern web apps and APIs, and it causes more real SaaS data breaches than SQL injection, XSS, and RCE combined, not because it's sophisticated, but because it's invisible to most of the tooling teams rely on by default.

The precise definition

An IDOR exists when three things are all true: the app accepts a user-supplied identifier for an internal object, uses that identifier to fetch the object, and never verifies the requesting user is actually authorized to access that specific object. The vulnerability isn't in the identifier existing or being guessable. It's in that third step, the missing gap between "an ID was supplied" and "this object got returned anyway."

The right security question was never "can the user change the ID." It's "after the ID changes, does the server still check whether this specific authenticated user is allowed to touch this specific object." If the answer is no, you have an IDOR/BOLA.

What it actually looks like, across six different shapes

Sequential IDs. GET /api/orders/10021 returns User A's order legitimately. Swap it to /api/orders/10022, and if that returns User B's order without an ownership check, that's the classic pattern. The sequential IDs aren't the bug, the missing authorization check on top of them is.

BOLA in an API. A vehicle-control API: POST /api/vehicles/ABC123/doors/unlock works fine for the owner. Swap the vehicle ID to one belonging to someone else, and if the server unlocks it anyway, that's API1:2023 by definition, OWASP uses almost this exact example.

UUIDs don't fix it. GET /api/documents/f47ac10b-58cc-4372-a567-0e02b2c3d479 looks unguessable, but User A can still get User B's UUID through a shared link, an API response, a notification, browser history, any legitimate flow. Predictability affects how easily an ID is discovered. Authorization determines whether it can be used. Those are separate properties, and switching ID format only fixes the first one.

File references. GET /static/invoices/10021.pdf swapped to 10022.pdf is the same bug wearing a different hat, applies equally to profile images, exported reports, generated PDFs, chat transcripts.

GraphQL. A mutation like deleteDocument(id: "doc-10022") can delete an object the caller doesn't own just as easily as a REST endpoint can leak one. The identifier's transport (URL path, query param, JSON body, GraphQL variable) is irrelevant. The server still has to authorize the object before acting on it.

Multi-tenant. GET /api/organizations/acme/invoices swapped to /api/organizations/other-company/invoices is the same failure at organizational scale, and it's the most damaging variant because a single missing check can expose an entire company's data instead of one user's.

The taxonomy that actually matters for triage

Horizontal — same privilege level, different user. The most common type. CVSS roughly 6.5 (read) to 8.8 (write/delete).
Vertical — a standard user reaches admin or elevated-privilege data by supplying a privileged resource's ID. Roughly 7.5–9.1.
Blind — the action succeeds but nothing comes back in the response. No visible data exposure, so it's chronically underestimated, but it causes real integrity failures: deleted content, modified state, disrupted workflows, with no trace unless you check the target resource afterward. Roughly 5.0–8.8.
Second-order — an identifier gets accepted in one step of a workflow, stored, and reused later without re-validating ownership. No automated tool understands multi-step context this well; the endpoint looks completely correct in isolation. Often 7.5–9.5, because it tends to bypass the most sensitive step in a workflow.
Multi-tenant — cross-organization access. A force multiplier: one horizontal IDOR leaks one user's data, one multi-tenant IDOR can leak an entire org's, potentially thousands of records in a single request. Almost always 8.8–9.5.
Mass assignment — the request body includes fields like user_id, owner_id, or role that the client shouldn't be able to set, and the server processes them unfiltered.

Scoring it correctly

Most IDOR findings get under-scored because whoever's scoring focuses on the single HTTP request instead of what it enables at scale. The good news is that almost every parameter is fixed across web/API IDORs, so scoring mostly comes down to one variable: impact.

Fixed CVSS 4.0 parameters for nearly every case: Attack Vector Network, Attack Complexity Low, Attack Requirements None, Privileges Required Low, User Interaction None. Two exceptions: second-order IDORs get Attack Requirements Present, since specific workflow state has to exist first, and unauthenticated IDORs (rare, but they happen) get Privileges Required None, which pushes the score straight to critical.

Scenario	What changes	CVSS 4.0
Read, single low-sensitivity record	VC: Low	~5.3
Read, single high-sensitivity record (PII/financial)	VC: High	~6.9
Read, all records for one user	VC: High	~7.1
Read, all records across all users	VC: High + SC: High	~8.8
Read, multi-tenant, full org exposure	VC: High + SC: High	~9.1
Write, modify another user's resource	VI: High	~8.8
Write, modify an admin-level resource	VI: High + SC: High	~9.1
Delete, another user's data (blind)	VI: High	~7.5
Delete, critical business records	VI: High + SC: High	~8.5
Multi-tenant, any of the above	Always add SC: High	8.8–9.5

Two questions decide almost the entire score: how many records are actually in scope, and can the attacker write or delete, or only read. Write and delete consistently score higher than read at equivalent scope, and multi-tenant always adds SC: High because impact extends beyond the attacker's own org.

Why your existing tools structurally can't catch this

DAST operates at the HTTP request level: send a request, look at the response, compare patterns. It has no concept of ownership. That's not a maturity gap in any particular tool, it's a structural limit of request-level testing without object-ownership context.

Static analysis flags patterns like "identifier from user input used in a query without a visible authorization check nearby," and in practice this produces a false-positive rate that consistently exceeds 50%. Engineers burn time dismissing noise, and real IDORs buried in a complex call chain still get missed, because an authorization check exists somewhere in the codebase, just not the right one at the right level for this specific resource.

The actual test IDOR needs is a runtime, cross-identity question: is this authorization check actually enforced, for this resource type, from this identity, at this point in this specific workflow. That requires an authenticated identity, a resource it owns, a second identity that doesn't own it, and systematic testing of every endpoint with both, comparing results. That's a fundamentally different exercise than anything a single-request scanner does.

Testing methodology, phase by phase

IDOR testing needs at least two accounts with known, distinct resource ownership, and ideally two separate tenants if the app is multi-tenant. From there:

Endpoint discovery. Pull every endpoint from the OpenAPI spec and from JS bundle analysis, since bundles often expose internal paths the spec omits. Flag every endpoint that accepts an object identifier, note whether it's in a path, query param, body, or header, and classify by method, since write/delete IDORs generally outscore read-only ones.

Horizontal testing. Replay Account A's authenticated request using Account B's resource IDs, across every method, not just GET. Test batch endpoints specifically by mixing owned and unowned IDs in one request, batch endpoints frequently check authorization once for the whole collection instead of per item. Test export/download endpoints, teams treat these as secondary and skip authorization review on them constantly. Test search/filter parameters using another user's ID as the filter value.

Vertical testing. Look for admin resource IDs leaking through error messages or metadata, then try accessing them with a standard-user token.

Multi-tenant testing. Find every place org_id/tenant_id shows up (path, query param, body) and try substituting another org's ID in each location independently. Path-based org scoping (/api/orgs/{org_id}/resources) is the most common pattern and the one most often missing validation.

Second-order testing. Map multi-step workflows, create a resource as Account A, then try to resume or complete the workflow as Account B. The common failure: ownership gets checked at creation but never re-checked at resumption.

Blind testing. Hit every DELETE and action-POST endpoint with another user's resource ID. A 204 No Content is not a passing result by itself, the only way to confirm impact is to check the resource afterward as its actual owner and see whether it changed.

Fixing it

The fix is always server-side, object-level authorization, never identifier obscurity.

# VULNERABLE
invoice = Invoice.query.get_or_404(invoice_id)
return jsonify(invoice.to_dict())

The identifier might be valid, but nothing here confirms the authenticated user owns this invoice.

# SECURE
invoice = Invoice.query.filter_by(
    id=invoice_id,
    user_id=current_user.id
).first_or_404()

return jsonify(invoice.to_dict())

The change that matters isn't the identifier format, it's the ownership constraint applied server-side. A few patterns that generalize: derive ownership exclusively from the authenticated session, never from anything the client claims; make an ownership filter a structural requirement on every query touching user-owned data, not an optional extra; for multi-tenant apps, enforce row-level tenant isolation at the ORM or database layer so it can't be skipped by a careless handler; explicitly filter mass-assignment fields like user_id, owner_id, and role out of client-writable input; and for multi-step workflows, re-validate ownership at every single step, never assume a check from step one still holds by step three.

Testing it manually with Burp

Browse the app authenticated, capture requests carrying anything that looks like an object reference, not just numeric IDs: UUIDs, usernames, slugs, filenames, tenant IDs, GraphQL variables. Send a request for your own object to Repeater and confirm the baseline response. Then change only the object identifier, keep the same auth token, and see what comes back.

Don't trust status code alone. A vulnerable endpoint can return 200 OK with someone else's data, and a properly protected one might also return 200 OK with an error message in the body instead of a 403. Compare status, response body content, whether the object identifier in the response actually matches what was requested, response length against a known-denied baseline, and any side effects (did it modify or delete something).

Confirmation requires all of: User A is authenticated, User A can access Object A, Object B belongs to User B, User A swaps the reference to B, the server returns or modifies Object B, and no additional authorization check intervened. That mismatch between "who's authenticated" and "what they were allowed to touch" is the entire vulnerability.

The UUID misconception, one more time

"We switched to UUIDs so IDOR isn't a problem anymore" is one of the most persistent wrong beliefs in web security. UUIDs prevent enumeration. They do nothing to prevent unauthorized access once an identifier is obtained through some legitimate path, a shared link, a leaked response, a notification email. The fix was never about hiding the identifier. It's ownership verification at the server, full stop, and it's identical work whether the ID is 10022 or a UUID.

Why the blast radius here is different

Most vulnerability classes have a bounded blast radius. XSS affects visitors to one page. A given SQL injection exposes one query's results. IDOR's blast radius scales directly with your user count and data sensitivity, because it's one missing check away from every record that check was supposed to protect. A SaaS app with 10,000 customer records has 10,000 records riding on a single ownership filter. A multi-tenant platform with 500 customer orgs has 500 organizations' worth of data one parameter swap away from any authenticated user who thinks to try it.

It doesn't take exploit code or specialized tooling. It takes patience and arithmetic, and it lives entirely in application logic, which is exactly the layer most default scanning tooling doesn't reach. The only detection method that actually works is authentication-aware, ownership-tracking, multi-identity testing that asks "what if this belonged to someone else" at every endpoint, every method, every workflow step, systematically rather than opportunistically.

CodeAnt AI's penetration testing platform is built around exactly that cross-identity testing model, authenticating as multiple real identities simultaneously and tracking ownership across the full API surface rather than scanning requests in isolation. For the multi-tenant variant specifically, which tends to be the highest-severity flavor of this bug, see CodeAnt's multi-tenant SaaS penetration testing guide.

Black Box vs White Box vs Gray Box Pentesting: Picking the Right One (Most Teams Don't)

Amartya Jha — Mon, 07 Sep 2026 11:16:50 +0000

"What type of penetration test do we need" is usually the second question a team asks, right after "do we need a pentest." It deserves more thought than it gets, because the three methodologies, black box, white box, and gray box, don't just differ in thoroughness. They differ in what they're structurally capable of seeing at all. A clean report from one says nothing about the other two.

The difference comes down to one variable: what the tester knows and can access before the engagement starts. That starting point determines which vulnerability classes are reachable and which are, by construction, invisible to that particular test.

Black box: attacker starting from nothing

A black box tester gets a domain. No credentials, no source, no architecture docs. The question this answers is precise: what can someone on the internet, with zero inside knowledge, actually do to your data?

Reconnaissance is the foundation, and it's more thorough than most teams expect. Subdomain enumeration brute-forces DNS across 150+ prefix patterns, not just www and api, but dev, staging, uat, internal, jenkins, grafana, admin. Certificate Transparency logs get queried too, since every TLS cert ever issued for the domain is publicly logged there, which surfaces historical subdomains DNS brute-forcing misses entirely, including ones nobody remembers are still running a server. Port scanning covers all TCP ports, not just 80/443, which is how an exposed Redis instance or an unauthenticated Elasticsearch cluster gets found. It happens more than it should.

Cloud asset discovery extends the same logic to infrastructure that isn't the app itself: S3 buckets checked for public read/write, Azure Blob containers for anonymous access, GCP buckets for allUsers permissions, CI/CD dashboards (Jenkins, CircleCI, GitHub Actions) checked for missing auth, monitoring endpoints (Grafana, Kibana, Datadog) checked the same way.

JS bundle analysis is the step most traditional black box engagements skip, and it's one of the highest-value ones. A modern SPA ships 5–15MB of minified JavaScript to every visitor's browser, and that bundle gets statically analyzed for hardcoded secrets across 30+ pattern types, AWS keys, Stripe live keys, GitHub tokens, JWT secrets, Twilio and SendGrid credentials, each one verified for validity before it's reported. Comparing staging and production bundles also surfaces endpoints that were pulled from prod but are still live on a non-production URL with weaker controls, which is a surprisingly common way to find a forgotten API.

Every discovered endpoint gets hit unauthenticated first, and the response gets classified: 200 OK with real data means no auth enforced, full stop. 500 can mean the request got processed before the auth check ever ran. 403 gets checked for a bypass rather than taken at face value. CORS gets tested against 7+ attacker-controlled origins, since misconfigured CORS shows up in production constantly.

Findings get chained, not reported in isolation. A tenant ID leaking from a profile endpoint plus an IDOR on the records endpoint equals full cross-tenant access. A hardcoded internal hostname in the JS bundle plus an unauthenticated endpoint on that internal API equals unauthenticated access to something that was never meant to be reachable at all. The combination is consistently more dangerous than either finding alone.

What black box structurally cannot see: auth bypasses buried in middleware config that still return normal-looking responses, business logic flaws behind a login wall, secrets sitting in Git history, anything on an internal service never exposed to the internet, dependency vulnerabilities that need code access to assess reachability. This isn't a weakness in the methodology, it's the direct consequence of the threat model. A black box test simulates someone with nothing. It can only ever see what nothing gets you.

White box: reading the implementation directly

White box gives the tester the code. Configs, infrastructure definitions, dependency manifests, architecture docs, version history. The question shifts from "what can an attacker discover" to "what's actually wrong in the implementation, whether or not it's visible from outside."

Security configuration gets read directly, which catches things scanning never will. A Spring Security filter chain excluded for an entire /api/v2/ namespace looks completely normal from outside, the endpoint just responds. An external scanner has no way to know the auth layer got skipped entirely for that namespace. Same story with Express middleware ordering: an admin endpoint can return 200 OK with real data to an unauthenticated request because the auth middleware got registered after the route handler, and nothing about the HTTP response gives that away.

Secrets scanning covers current HEAD and history separately. A credential committed and later deleted from the working tree is still sitting in version control, recoverable by anyone with clone access, and that's a distinct check from scanning what's currently checked in.

Dataflow tracing is where white box earns its reputation for precision. Instead of "SQL injection detected," a proper trace produces something like: app/views/products.py, line 14, search_products(), the category parameter from request.GET reaches a raw query via string formatting, payload ' OR '1'='1' --, effect: returns all products regardless of category or featured status, root cause: Product.objects.raw() with f-string interpolation instead of a parameterized query. That specificity is the difference between an engineer fixing the actual line and an engineer guessing at what "SQL injection" means for their codebase.

Dependency analysis goes past CVE matching into reachability. A vulnerable package that's imported but never actually called from a code path the app executes is a very different risk than the same CVE sitting in a function that runs on every file upload. Reachability analysis is what separates the two, and it's the single biggest lever for cutting dependency-scan false positives.

Gray box: what a legitimate account can get away with

Gray box starts with authenticated access, one or more real test accounts, sometimes limited docs or API specs on top. The question: what can someone do once they already have valid credentials?

Access control and privilege escalation testing hits every admin-level endpoint with non-admin credentials, and JWT claims get manipulated directly to check whether role or tenant claims are actually re-validated server-side or just trusted from the token.

IDOR testing here is systematic, not exploratory. Every endpoint accepting an object identifier, sequential integer, UUID, slug, username, filename, tenant ID, or an ID buried in a JSON or GraphQL body, gets evaluated for object-level authorization. The core test: can a user authorized for Object A simply substitute Object B's identifier and read, modify, or delete it. In multi-tenant apps this same check has to run at the org boundary, not just the user boundary, since a missing tenant check leaks an entire company's data instead of one account's. (We've written the technical breakdown of this vulnerability class in full, including every variant and how to test for it, if you want to go deeper than this section.)

Business logic testing is where gray box finds things nothing else reaches, because none of these produce an anomalous HTTP response or match a known CVE signature. They require understanding what the app is supposed to enforce, then checking whether it actually does, at every entry point:

Can the order total be modified in the request before payment confirms?
Can a single-use discount code be replayed by resending the validation call?
Can checkout step 5 be hit directly without completing steps 1 through 4?
Can a free-tier account call a premium endpoint directly via the API?
Can rate limits be evaded by rotating user IDs or spoofed IP headers?
Can negative quantities reduce a total in an e-commerce flow?
Does a race condition in inventory or balance checks survive two simultaneous requests?

None of this shows up in a scanner's output. All of it ships to production regularly.

The comparison that actually matters

	Black box	White box	Gray box
Simulates	External attacker, no prior knowledge	Insider/attacker with implementation access	Legitimate user or compromised account
Starting point	Domain + public info	Source, config, architecture, dependencies	Test credentials + selected context
Strong at	Exposed services, unauth endpoints, cloud misconfig	Code-level auth flaws, data flow issues, secrets, dependency risk	IDOR, privilege escalation, broken access control, business logic
Structurally misses	Anything needing auth or internal visibility	Runtime behavior specific to production conditions	Unauthenticated external exposure
Answers	"What can an external attacker reach?"	"What's actually wrong in the implementation?"	"What can an authenticated user get away with?"

None of these are difficulty tiers stacked on top of each other. They're three different threat models with three different structural blind spots, and the important asymmetry is this: a clean result from any one of them tells you nothing about the other two. A spotless black box report doesn't mean the code is clean. A spotless white box audit doesn't mean nothing's exposed externally. A spotless gray box assessment says nothing about whether the unauthenticated surface holds up.

Picking one (or more)

If you've never had a real assessment, run all three together. Partial coverage produces the worst outcome in security, which is false confidence from a report that never looked where the actual risk was sitting.

If you're pre-launch with a product handling customer data, prioritize gray box plus white box. Business logic flaws and code-level auth bugs are exactly what ships in a first release, and the external surface can be addressed continuously once the app is actually live and has real exposure to test against.

If you've already run black box tests before (most first pentests are black box by default) and never gone further, white box is very likely your highest-value next investment. Most prior engagements never touched the code, and that's where the deepest, highest-severity findings tend to live.

If your specific concern is a compromised account crossing into another customer's data, gray box is the direct answer, since it's the only methodology built to test tenant and object-level boundaries under real authenticated conditions.

Why chaining across all three beats running them separately

The real value isn't additive coverage, it's that findings from one perspective give the other two something to test against. Black box finds an exposed API. White box traces that same endpoint into its authorization logic and shows exactly how (or whether) access gets enforced. Gray box then hits that endpoint with real credentials to check whether an authenticated user can swap an object ID and reach someone else's data.

A vulnerability that spans layers like this is easy to miss with any single methodology and hard to miss once the three are cross-referenced against each other. An exposed endpoint only becomes dangerous paired with a missing authorization check behind it. A code-level weakness only becomes exploitable once you know the corresponding endpoint is actually reachable from outside. Treat black box, white box, and gray box as three independent security programs and you'll keep missing exactly this kind of finding, the one that only exists at the seam between them.

CodeAnt AI's penetration testing platform runs black box, white box, and gray box as a single engagement with attack-chain validation across all three, rather than three disconnected reports that never talk to each other.

Red Team Authorization: Solving the Paradox of Testing People Who Can't Know They're Being Tested

Amartya Jha — Mon, 07 Sep 2026 07:48:24 +0000

A red team engagement exists to answer one question: can your security team detect and respond to a real attack. For that answer to mean anything, the security team being tested, the blue team, cannot know the test is happening.

That single constraint breaks the normal authorization model. Standard authorization flows through the people who own the systems being tested, and for a pentest, that includes security and IT. For a red team, those are exactly the people who have to stay in the dark. Get this wrong in one direction and the blue team finds out, which ruins the test. Get it wrong in the other direction and nobody with real authority actually approved the engagement, which puts the testers in genuine legal exposure if something goes sideways mid-operation. Both failure modes defeat the entire point of running a red team in the first place.

The fix is compartmentalization: authorization flows from a small group of executives who are explicitly, provably not part of the blue team being evaluated.

Why this isn't just a stricter pentest authorization

A red team authorization letter is a different document with different legal and operational requirements, not a pentest letter with a tighter NDA bolted on. A red team may deliberately interact with people, facilities, and defensive systems that have no idea a test is running.

	Standard pentest	Red team engagement
Objective	Identify and validate vulnerabilities	Test detection, response, and containment
Who knows	Security, IT, system owners	Restricted executive/legal group; blue team often excluded
Signing authority	CISO, CTO, or delegated security exec	Exec sponsor with authority over the target, independent of the blue team
Scope	Apps, APIs, infra, cloud assets	Technical systems plus facilities, personnel, identities, defensive controls
Social engineering	Usually excluded or separately authorized	May be explicitly authorized
Physical access	Usually excluded or separately authorized	May include offices, badge systems, tailgating
Blue-team awareness	Usually expected	Often intentionally restricted
Emergency contact	Testing firm + client security contact	24/7 executive sponsor who can confirm the op immediately
Law enforcement	Addressed in emergency procedures	Must explicitly define how authorization gets verified on the spot

Who's actually allowed to sign

The signing rule is simple to state and easy to get wrong in practice: the signer cannot be part of the group whose detection capability is being evaluated.

If the CISO manages the SOC being tested, the CISO cannot sign.
If the entire security function is in scope, it goes to CEO or board level.
If security manages but doesn't operationally run the specific test target, the CISO may sign, provided they're genuinely separate from the blue team in question.

This isn't "the CEO always signs." It's that the signer needs actual authority over the assets in scope and needs to sit outside the operational group being evaluated. Most red team authorizations end up at CEO or board level for a simple reason: the engagement is testing the security function itself, and the person who runs that function can't objectively authorize their own team's evaluation.

Cloud providers have their own rules, and they change

Red team authorization from your organization doesn't extend to permission from your cloud provider. AWS, Azure, and GCP each publish their own acceptable-use and security-testing policies, and they get updated. Verify the current version immediately before the engagement rather than trusting whatever was true last year.

For every cloud provider in scope, document: the provider and account/subscription/project identifier, specific regions and resources, the approved testing window, approved and explicitly prohibited techniques, any notification or approval requirements the provider imposes, emergency contacts, executive authorization, and stop conditions. Treat this as its own verification step, separate from the signed authorization letter, not something you assume is automatically covered by it.

The sealed envelope model

When getting an executive signature at engagement start is genuinely difficult for legal, timing, or organizational reasons, a sealed envelope approach works: the fully signed authorization exists, but it's only opened if a legal issue comes up, law enforcement gets involved, or the organization faces an inquiry that requires documented proof. This lets the engagement run under strict compartmentalization while real, verifiable authorization still exists if it's ever needed.

The get-out-of-jail card

Anyone doing physical access or social engineering work in the field should be carrying a physical card, not a digital one, that lets them verify the engagement on the spot if security or police stop them.

Requirements that actually matter here: a 24/7-reachable number, not an office line that goes to voicemail at 11pm; an authentication code the contact can verify against; the named contact is the executive sponsor, never someone on the security team; every field operator carries one; and it's a printed copy, because a phone can be confiscated, dead, or locked during exactly the moment you need it.

What the rules of engagement have to nail down

The authorization letter grants permission. The rules of engagement define the edges of that permission, and for a red team both documents matter equally: objectives (detection, response, containment, physical security, identity, or full lifecycle), in-scope and out-of-scope targets down to specific systems and facilities, permitted and prohibited techniques, the exact testing window, how discovered sensitive data gets handled, whether persistence is allowed and when it must be removed, the detection protocol once the blue team notices, stop conditions, emergency contacts, the law-enforcement verification procedure, third-party boundaries, evidence preservation, and cleanup requirements at close.

What happens when the blue team actually catches you

This is the part standard pentest authorization letters never have to address, and it's where most of the real risk lives.

Blue team detects but doesn't escalate to law enforcement. Define in advance whether the red team keeps operating as if undetected, or stops. Most engagements specify continuing unless the executive sponsor says otherwise. This should never be improvised live.

Blue team escalates to the CISO. If the CISO is in the "doesn't know" group, they might treat this as a real incident and call the police. The authorization needs a defined procedure for the executive sponsor to step in before that happens.

Blue team calls law enforcement. This is the scenario that produced the well-known Coalfire arrests. Officers show up, testers get detained. The get-out-of-jail card is the first line of resolution. The 24/7 executive sponsor is the second, and the letter needs to state plainly that they're reachable to confirm the engagement directly to law enforcement, not to a lawyer, not by email, directly.

Blue team successfully contains the attack. Decide ahead of time whether the engagement resets, ends, or triggers an immediate debrief, so nobody's making that call under pressure in the moment.

At minimum, pre-define stop conditions for: production availability materially affected, customer data placed at risk, an unintended third party affected, law enforcement involvement, the blue team activating emergency response, the red team hitting a prohibited system, or the executive sponsor simply ordering a stop.

What a red team letter needs that a standard one doesn't

A compartmentalization section naming exactly who knows the engagement is happening and who must not be told, by name, not by role. A written confirmation from the executive sponsor that they're reachable for the full engagement window, treated as a primary operational requirement rather than a footnote. A defined blue-team response protocol so nobody improvises under pressure. A documented decision on whether local law enforcement was pre-notified, which is genuinely the single most effective way to avoid an arrest scenario. Precise physical scope, "the company's offices" is not scope, list addresses, floors, access types, and whether tailgating or badge cloning are in bounds. Verified cloud-provider authorization per account. An explicit reference to the signed rules of engagement so there's no ambiguity about what's actually authorized. And a named person with clear stop/terminate authority, plus the conditions under which the team must halt without waiting for sign-off.

Permission under secrecy is a different problem than permission

A standard pentest is about getting permission. A red team is about getting permission while deliberately keeping most of the organization unaware it exists, and that constraint changes the shape of every document involved. Authorization can't be broad, can't be assumed, and can't reuse the pentest template with a confidentiality clause added. The moment the wrong people find out, the test is worthless. The moment the right people haven't formally signed off, the engagement is a real legal liability for everyone in the field.

Limited awareness, explicit authority, and a clear escalation path, defined before testing starts, is the whole model. Get it right and the engagement runs exactly as designed: realistic, controlled, defensible. Get it wrong and you either lose the test or put your own team at risk. There's no middle version of this.

For the baseline structure this builds on, see CodeAnt AI's guide to penetration test authorization letters. For how these engagements get scoped and reported end to end, see CodeAnt AI's penetration testing platform.

SOC 2 Penetration Testing: What Auditors Actually Check For (And Where Most Programs Fail)

Amartya Jha — Mon, 07 Sep 2026 07:21:44 +0000

Day three of a SOC 2 Type II audit. The auditor pulls up the penetration testing section of the audit program and asks: "Can you show me evidence that exploitable vulnerabilities identified during your penetration test were corrected, and that the corrections were tested?"

Not "did you do a pentest." Not "can I see the report." The question is specifically about correction and verification.

The engineering lead can produce the pentest report without much trouble. A retest report that confirms each finding was actually patched and verified in production is harder to find. A documented timeline from finding to fix to verification, harder still. Evidence that the retest ran against the same environment, same methodology, as the original test, almost nobody has that on hand.

The control gets marked as an exception. The report ships with a qualified opinion on CC7.1. The enterprise sales cycle gets a little longer.

This plays out constantly, not because companies skip security testing, most don't, but because they run testing without understanding what SOC 2 specifically needs that testing to produce as evidence.

SOC 2 is an opinion, not a certificate

SOC 2 (Service Organization Control 2) is an AICPA auditing standard. It evaluates whether your controls meet the Trust Services Criteria relevant to your service. It is not a certification body handing out badges, it's an attestation: an independent CPA firm's formal opinion that your controls meet the criteria. That opinion is the report you hand to customers.

Five TSC categories exist. Security (CC) is mandatory. The other four are optional add-ons depending on what you handle:

Category	Required?	Pentest relevance
Security (CC)	Yes	Direct — CC6, CC7, CC8, CC9
Availability (A)	Optional	Infra resilience, DDoS
Processing Integrity (PI)	Optional	Business logic, data validation
Confidentiality (C)	Optional	Data access, encryption
Privacy (P)	Optional	PII handling, access verification

Here's the part that trips people up: SOC 2 barely uses the phrase "penetration testing" anywhere in its text. Companies search for an explicit line item, don't find one, and conclude testing is optional. It isn't. The requirement is implicit in CC6.6 (protection against external threats) and CC7.1 (detection of security events), and AICPA's supplemental guidance explicitly names penetration testing as an appropriate way to satisfy them. Every Big Four firm and most regional CPA firms with a SOC 2 practice treat annual pentesting as table stakes for the Security category.

The real question was never whether you need a pentest. It's whether the one you ran generates the specific evidence an auditor is trained to look for.

Type I vs Type II: different questions entirely

	Type I	Type II
Core question	Are controls suitably designed?	Did controls operate effectively over time?
For pentest	Do you have a program, and is it reasonably designed?	Did the program actually run and produce results people acted on?

Type I checks that a program exists and looks reasonable. You need: a written, dated, approved pentest policy; one completed test report inside the observation window; evidence the tester was qualified and independent; a finding list with severities; a remediation plan (doesn't need to be finished, just documented). Type I auditors will not ask for a retest report, proof that remediation worked, or evidence testing covered everything critical. They're checking existence and design, not execution.

Type II checks execution across the whole period, and the evidence bar jumps considerably:

Pentest report(s) covering the observation period
Evidence critical/high findings were actually remediated
A retest report confirming remediation worked — the single most commonly missing item
Timeline evidence: find date, fix date, retest date
Remediation SLA documentation and proof you hit it
Evidence the test covered systems that touch customer data
Risk acceptance documentation for anything left unremediated

Common failure patterns at Type II, roughly in order of frequency: a pentest report exists but no retest report does; the retest didn't cover every original finding; remediation happened in staging, not production (production is what's audited, staging evidence doesn't count); remediation took longer than the stated SLA, which is worse than having no SLA; risk acceptances existed only verbally; the test ran against an older version than what's in production; the gap between the last test and the audit exceeds twelve months.

Timing rules nobody reads until it's too late

SOC 2 Type II has a minimum six-month observation period per AICPA guidance, though in practice enterprise buyers expect twelve. Your testing needs to produce evidence across that whole window, not one point inside it.

Three structural options, in order of evidence strength:

	Cadence	Coverage	Best for
A	Annual (1 test + 1 retest)	System as of test date	Stable, low-change systems
B	Semi-annual (2 tests + 2 retests)	Two snapshots across the period	Most SaaS teams
C	Continuous (monthly)	Full period	High-velocity development

Rules that catch teams off guard:

The test must occur inside the observation period. A test run two months before your period started evidences the prior period, not this one.
For a twelve-month period, at least one test needs to land inside those twelve months.
The retest must also happen inside the period, after remediation.
The gap between your last test and period-end shouldn't exceed roughly six months. Beyond that, expect the auditor to ask about it.

The single most common mistake: running the pentest in Q1 for a Q1–Q4 audit period and never scheduling a follow-up. The auditor eventually asks what covered Q3 and Q4. The honest answer, nothing, doesn't cause an automatic qualified opinion by itself, but it's a gap you'll have to explain, and it's rarely a satisfying explanation. Fix: schedule a second test, or at minimum a targeted retest, around the six-month mark.

Scope: follow the data, not the architecture diagram

The scoping principle that matters more than any other: test everything that touches, stores, processes, or transmits the data your SOC 2 covers. Testing systems that don't touch customer data while skipping the ones that do is a scoping failure auditors catch quickly.

Component	In scope?	Controls	Notes
Public web app	Yes	CC6.6	Primary requirement
Authenticated API	Yes	CC6.1, CC6.3	Document endpoint coverage
Admin panel	Yes	CC6.1, CC6.3	High-value target
Customer data store	Yes	CC6.1, C1.1	Often tested via the app layer
Cloud IAM	Yes (if cloud-hosted)	CC6.6, CC8.1	IAM privilege audit
CI/CD pipeline	Recommended	CC8.1	High supply-chain risk
Mobile apps	Recommended	CC6.6	If customer-facing
Staging/QA	No	—	Test production
Third-party SaaS tools	No	CC9.2	Review their SOC 2 instead

Two scope gaps auditors flag constantly: cloud infrastructure ("AWS manages that" is not a scope rationale, IAM misconfigurations and exposed buckets are CC6.1/CC6.6 findings and belong explicitly in scope) and APIs (most breaches happen at the API layer, but plenty of testing programs only cover what renders in a browser).

The retest report is the thing nobody has

If there's one document to obsess over, it's this one. Fixing a bug isn't the same as evidencing the fix worked. The retest needs to come from the same external firm that ran the original test, re-executing the original test cases against the patched, production system, and producing a second report confirming which findings actually closed. Internal QA can supplement this, it can't replace it.

What auditors actually ask, verbatim-adjacent

These aren't hypothetical. They're the standard interview pattern:

"Do you have a penetration testing policy?" — wants a written, approved, dated document, not "yes, we do pentests"
"When was your last test?" — wants a date inside the observation period
"Who conducted it?" — wants a named external firm, not "our developer ran some scans"
"How do you know remediations worked?" — wants a retest report, not self-attestation
"Show me a critical finding remediated within your SLA" — wants discovery, fix, and retest dates all inside the policy timeline
"What about findings you didn't fix?" — wants a signed risk acceptance with a named owner and compensating controls
"Was the test conducted against production?" — many teams test staging to avoid disruption; auditors know this trick and ask directly
"Did the test cover cloud infrastructure?" — app testing and cloud config review are not the same exercise
"What version was running when the test occurred?" — a test of v1.2 doesn't evidence v2.8; put the version number in the authorization letter
"Are you getting better year over year?" — wants CVSS severity trend data across periods; a flat or worsening trend is a flag in renewal audits

The pattern behind every good answer is the same: name the document, cite the date, name the firm, show the timeline. If you can't do that in one sentence, that's the gap.

Nearly every exception traces back to one of three root causes: no retest report, timing (test ran outside the observation window or was never followed up), or scope (staging instead of production, no cloud layer, browser-only coverage while the API sat untested).

Building the program by stage

First Type I audit. Start four months out, not four weeks. Month one: write and approve the policy, pick a qualified external vendor, scope every system touching customer data, run the test. Month two: triage findings with owners, remediate all criticals before the audit (highs strongly recommended), document risk acceptances for anything left, book the retest. Month three: get the retest report, assemble the evidence package, get management sign-off on findings (minuted), hand it to the auditor. Budget for a sub-50-endpoint SaaS: roughly $8K–$20K for the test, $2K–$6K for the retest, $1K–$3K for policy support if starting cold. The most common failure at this stage is simply starting too late; four weeks isn't enough runway for test, remediation, and retest.

Growth stage, Type II with active shipping. A single annual test doesn't cover code shipped in month nine of a twelve-month period. Reasonable structure: one comprehensive annual test as the baseline, quarterly targeted testing of high-change areas, a security review on any auth/authz change before release, and continuous DAST/SAST/SCA scanning filling the gaps. The most common gap here is months seven through twelve with zero testing evidence, plus new features (a new payment flow, new auth method) shipped after the annual test with no review at all, which is a direct CC8.1 problem.

Enterprise, Type II with MSA obligations. Baseline SOC 2 requirements plus whatever your customer contracts separately demand, and these are two different obligation sets, don't conflate them. Enhanced testing typically means external perimeter, internal network, API, and cloud reviewed together rather than separately, security testing embedded in the SDLC instead of bolted on annually, and a red team engagement every two to three years. Some enterprise customers contractually require quarterly testing, full report access instead of an executive summary, specific tester certifications (CREST, for instance), or a 24–48 hour critical-finding notification window. None of that is SOC 2, it's contract, and it needs its own evidence trail separate from the standard package.

Choosing a provider without guessing

SOC 2 doesn't name specific certifications. It requires a "qualified" party, and your auditor applies judgment to decide whether that bar was met, so you need a defensible case for your choice.

Non-negotiable floor: external to your org (internal or affiliated testers don't satisfy independence, full stop), a formal written report (a spreadsheet of findings is not audit evidence), and a formal retest included in scope, not "we'll review your remediation notes."

Signals worth paying for: CREST organizational certification, OSCP or CISSP on the individual testers, prior SOC 2-specific engagement experience (they should already know what "per-finding verification" means to an auditor, you shouldn't be the engagement where they learn it).

Questions worth asking before signing: can you show a sanitized sample report with unique finding IDs, CVSS scores, and proof-of-concept evidence (not scanner output with a paragraph slapped on)? Is retest included and does it produce its own separate report? Will you confirm in writing you're testing production? What's your process when you find a critical mid-engagement (there should be an out-of-band escalation, not "wait for the final report")? Will you provide a CVSS delta against last year's findings for renewal purposes?

Red flags that end the conversation: automated scanner output passed off as a formal report, no retest service, no unique finding IDs, an inability to map findings to specific TSC control numbers, a default to staging, no professional liability insurance.

The twelve mistakes that actually cause exceptions

Process failures, before the test runs: testing staging instead of production; skipping the retest or letting an internal team do it; leaving critical findings open at audit time (start 90 days out, not 30); running the test before the observation period even opens; switching testing firms every year, which kills your ability to show a CVSS trend.

Documentation failures, after the test: finding triage that happened but was never logged in a ticketing system; management review of the security posture that happened in someone's head instead of in minutes (CC5.3 needs the paper trail); risk acceptances that were a verbal "yeah, we'll live with that" instead of a signed document with a named owner; no sign-off that the scope actually covered customer-data systems.

Policy failures, the ones that look like organizational dysfunction: an SLA policy that says 48 hours for criticals next to a remediation log showing 30 days, which is worse evidence than having no SLA at all; a scope document that excludes cloud infrastructure with "AWS handles that" as the justification.

What a well-run engagement actually produces

A pentest built for SOC 2 evidence, not just technical findings, structures itself around the control mapping from the start: reconnaissance covering every external asset for CC6.6; source-level tracing of auth and authz flows for CC6.1/CC6.3; JS bundle analysis for leaked secrets and exposed endpoints under CC6.7; active exploitation with every finding confirmed working before it's reported, chained findings reported as chains (three mediums that combine into one critical shouldn't ship as three tickets your team deprioritizes); a report where every finding carries proof-of-exploit, root cause down to file and line, CVSS 4.0 with metric justification, and a mapping to the specific control ID, not a general "this relates to SOC 2." Then unlimited retesting at no extra cost, with the retest confirming remediation in production specifically, and a named researcher sign-off, which is what satisfies the "qualified party" language in your own policy.

CodeAnt AI's penetration testing platform is built around exactly this evidence structure, which is also what makes running the semi-annual or continuous testing cadence operationally realistic instead of a once-a-year scramble.

The actual takeaway

Nobody fails a SOC 2 pentest control because their engineers can't find vulnerabilities. They fail it because the retest report doesn't exist, the test ran outside the observation window, or the scope quietly excluded the systems that actually touch customer data. All three are process problems, not technical ones, and all three are fixable months before an auditor ever sits down across the table.

For a deeper breakdown of testing cadence tradeoffs referenced above, see continuous vs. annual penetration testing. For what a retest engagement should actually contain, see what happens during a pentest retest.

The Deployment Velocity Gap: Why Annual Pentesting Can't Keep Up With Modern SaaS

Amartya Jha — Mon, 07 Sep 2026 06:03:28 +0000

Most SaaS teams still pentest once a year. Almost none of them ship code once a year.

That mismatch is the actual security problem worth talking about, more than any single vulnerability class. Security gets validated at one cadence. Risk gets introduced at another. The distance between those two cadences has a name: the deployment velocity gap.

What the gap actually is

The deployment velocity gap is the time between a security-relevant change hitting production and that change actually being evaluated by a penetration test.

In an annual model, that gap can run for months. A system might be genuinely secure the day the assessment wraps, but every deploy after that day creates new, untested surface area: new endpoints, an updated auth flow, a new third-party integration, a reconfigured piece of infrastructure. None of it was in scope for the test that already happened. All of it is in scope for the breach that hasn't happened yet.

This isn't a knock on pentesting as a discipline. It's a scoping problem. A penetration test evaluates a moment in time, and it evaluates a defined scope, both of which shrink in relative value as deployment frequency rises.

You can put a number on your own exposure with something this simple:

def deployment_velocity_gap(test_interval_days, weekly_deployments):
    """
    test_interval_days: 365 = annual, 90 = quarterly, 30 = monthly
    weekly_deployments: how many times code ships per week
    """
    average_gap_days = test_interval_days / 2
    total_deployments = (test_interval_days / 7) * weekly_deployments

    risk_level = (
        "CRITICAL" if average_gap_days > 90 else
        "HIGH"     if average_gap_days > 45 else
        "MEDIUM"   if average_gap_days > 14 else
        "LOW"
    )

    return {
        "average_exposure_window_days": average_gap_days,
        "max_exposure_window_days": test_interval_days,
        "untested_deployments_per_cycle": total_deployments,
        "risk_level": risk_level,
    }

Run it against a team shipping three times a week on an annual test cadence and you get a 182.5-day average exposure window and 156 untested deployments per cycle: CRITICAL. Drop the interval to monthly and the same team lands at a 15-day average window and roughly 13 untested deployments: MEDIUM. The application didn't get safer. The window just got shorter.

Continuous pentesting isn't "scan on every commit"

Worth being precise here, because the term gets diluted fast: continuous penetration testing does not mean pointing an automated scanner at the app on every push and calling it a pentest. Scanners find known patterns at volume. A pentest investigates how a weakness can actually be chained and exploited in the context of a real, running application, with defined scope, authorization, controlled exploitation, and human oversight over the findings.

What continuous testing does mean in practice:

Monthly testing — a recurring assessment at a materially shorter interval than annual.
Sprint-cadence testing — assessments aligned to the development cycle itself.
Targeted testing — auth changes, new APIs, payment flows, and infra changes trigger a focused assessment on top of the recurring one.
Integrated coverage — pentesting sits alongside IDE, PR, and CI/CD controls rather than replacing them.

There's no single "correct" frequency. The right cadence is a function of deployment velocity, data sensitivity, regulatory obligation, and how fast the team can actually act on a finding once it exists.

Scoping a sprint by risk, not by calendar

The more useful version of "test every sprint" is test every sprint proportionally to what changed. A simple risk-scoring pass over merged PRs gets you most of the way there:

class SprintSecurityTestingProgram:
    def classify_test_depth(self, risk_score: int) -> str:
        if risk_score > 100:
            return "FULL_DEPTH — auth changes require complete auth chain review"
        elif risk_score > 50:
            return "TARGETED_DEEP — multiple security-relevant changes"
        elif risk_score > 20:
            return "TARGETED_STANDARD — specific components need focused testing"
        else:
            return "LIGHTWEIGHT — automated testing sufficient"

    def identify_priority_areas(self, changed_components: dict) -> list:
        priorities = []
        if changed_components["authentication"]:
            priorities.append({
                "area": "Authentication",
                "priority": 1,
                "test_focus": "JWT validation, session management, MFA bypass, brute force",
            })
        if changed_components["authorization"]:
            priorities.append({
                "area": "Authorization",
                "priority": 2,
                "test_focus": "RBAC, IDOR, cross-tenant access, role bypass",
            })
        if changed_components["data_access"]:
            priorities.append({
                "area": "Data Access Layer",
                "priority": 3,
                "test_focus": "SQL/NoSQL injection, ownership filter presence",
            })
        return sorted(priorities, key=lambda x: x["priority"])

Auth and authz changes get full-depth review every time. Everything else gets scoped by what it actually touches. That's the difference between a program that scales and one that turns into indiscriminate noise.

The economics people usually get wrong

The lazy comparison is "one annual invoice" versus "a subscription." That comparison undercounts the annual model and overcounts the continuous one, because it ignores retesting, remediation effort, false-positive waste, emergency response, and the actual expected cost of a breach sitting inside a long exposure window.

Cost category	Annual model	Continuous model	Delta
Direct testing cost	$25K–$50K	$48K–$72K/yr (sub)	+$10K–$25K
Retest cost	$8K–$15K	Included	-$12K
Engineering remediation	$19.2K (8 findings × 3 days)	$14.4K (12 findings × 1.5 days)	-$4.8K
False positive waste	$9.6K (30% FP rate)	$1.6K (5% FP rate)	-$8K
Emergency response	$17.5K (35% probability)	$4K (8% probability)	-$13.5K
Expected breach cost	$24.7K (180-day window)	$1.6K (14-day window)	-$23K
Total TCO	~$104K	~$80K	-$24K

Illustrative numbers for a $10M ARR company shipping weekly, 15 engineers at $100/hr, 12% annual breach probability, $500K average breach cost, but the shape of the comparison holds more broadly: the direct testing line goes up, almost everything downstream of it goes down, and the breach-cost line is usually the biggest single swing because it scales directly with how long the exposure window is.

The expected-breach-cost math is worth writing out, because it's the part most TCO comparisons skip:

exposure_window_days_continuous = 14  # sprint cadence
adjusted_breach_probability = breach_probability_annual * (
    exposure_window_days_continuous / 365
)
expected_breach_cost = adjusted_breach_probability * avg_breach_cost

Shrink the exposure window, shrink the probability term, shrink the expected cost. It's linear and it's easy to underweight if you're only looking at the invoice.

Picking a cadence: a decision framework, not a rule

Four questions, roughly in order of how much weight they should carry:

How often do you deploy? Weekly or more and annual testing is covering under 10% of your deployments by construction. Monthly or less and annual/semi-annual is probably fine.

What data do you handle? PII at scale, payment data, or health data pushes you toward quarterly-minimum or continuous regardless of deploy cadence, because breach impact and regulatory exposure are both high.

What's the regulatory environment? PCI DSS, SOC 2, HIPAA, and ISO 27001 all have their own expectations for testing evidence and cadence. Continuous testing can supplement that evidence; it doesn't automatically substitute for a compliance-mandated assessment, and that distinction matters when an auditor is asking.

Can you actually act on findings? A one-person security team that can triage in real time can run continuous. A team with no dedicated security function and no plan for continuous will just accumulate an ignored backlog, which is worse than not having found the issues at all.

Rough mapping:

Deployment frequency	Recommended model
Less than monthly	Annual / semi-annual
Monthly to bi-weekly	Quarterly minimum
Weekly or more	Sprint-based or continuous

SLAs are what keep a continuous program from collapsing

Continuous testing produces continuous findings, and without a severity-tiered SLA, that turns into noise the engineering team eventually starts ignoring.

Severity	CVSS	Acknowledge	Remediate	Retest
Critical	9.0–10.0	4h	48h	within 24h of fix
High	7.0–8.9	24h	7d	within 48h of fix
Medium	4.0–6.9	72h	30d	within sprint
Low	0.1–3.9	1 week	90d	next quarterly

Why continuous programs actually die

Most don't fail because the testing was bad. They fail for one of four operational reasons:

Finding fatigue without triage. Everything gets flagged with the same urgency, engineers tune it out. Fix: CVSS-based SLAs, a security champion per team doing first-pass triage, a weekly standup instead of ad-hoc tickets.
Testing is time-based instead of change-based. A calendar cadence misses whatever shipped between checkpoints. Fix: scope each cycle off actual PR/change data, not the calendar (this is what the sprint risk-scoring class above is for).
Surface monitoring without ownership. New subdomains and endpoints get flagged and nobody owns the follow-up. Fix: a rotation that owns the alert queue, with an explicit SLA (72h is reasonable) for investigating new surface.
Compliance-minimum thinking. The program quietly reverts to "just enough for the auditor." Fix: report on breach-probability and incident-cost terms at the board level, not just pass/fail testing status, so the program's ROI stays visible.

Metrics that actually tell you if it's working

Metric	Annual baseline	Continuous target
Mean time to detection	~180 days	<14 days
Mean time to remediation	~45 days (batch quarterly)	<7 days
Vulnerability escape rate	~25% (found by someone else first)	<5%
SLA compliance rate	~60%	>95%
False positive rate	~40%	<10%
Attack surface coverage	~70%	>95%

None of these should be optimized in isolation. The point of tracking them together is to see whether the gap between "change ships" and "change gets validated" is actually shrinking over time, not just whether a test happened.

Where AI actually changes the equation

The reason traditional pentest firms can't support a monthly cadence isn't unwillingness, it's structural: a human consultant works a target sequentially over one to two weeks, and that timeline doesn't compress just because you want it to.

What changes the math is running large numbers of specialized exploit agents in parallel against a target instead of one consultant working through it linearly, and carrying codebase context forward between engagements instead of starting cold every time, which is closer to how an attacker who's already been inside your codebase (via source access, leaked credentials, or a prior foothold) would actually operate. That combination, source-aware testing plus accumulated context, is what makes a 48-hour full-engagement turnaround and unlimited free retesting operationally sustainable instead of a pricing gimmick.

If you want to see how that model works end to end: CodeAnt AI's continuous penetration testing platform.

The actual takeaway

Annual pentesting isn't wrong. It's a point-in-time answer to a problem that, for most SaaS teams now, is continuous. The question worth asking isn't "did we pass our last pentest," it's "how long does a newly introduced risk sit untested before anyone looks at it." If that number is measured in months, the testing cadence and the deployment cadence have drifted apart, and that drift is the actual attack surface.

For the cost-side deep dive behind the TCO numbers above, see CodeAnt's guide to penetration testing costs. For the operational checklist on choosing a recurring testing vendor, see PTaaS provider SLAs: what to look for.

How a GitHub Triage Role Hijacked an Already-Authorized Claude Code Action Run

Amartya Jha — Mon, 31 Aug 2026 09:14:02 +0000

A GitHub collaborator with only the triage role could shift Claude Code Action's authorized trigger boundary and inject post-authorization input into a repository-writing run.

HackerOne #3918594 · Claude Code Action v1.0.185, commit 9db594c7a0e82298c121c18b7f08aa1579ce7341 · CVSS 4.0 score 7.5, High

Authorizing an automated job is really two promises: who gets to start it, and which data it's allowed to see once running. Most security reviews focus on the first and barely glance at the second, which is exactly where CodeAnt AI Security Research went looking in Claude Code Action, the GitHub bot that lets Claude respond to issues and pull requests and push changes back to a repository.

What we found: a collaborator holding nothing more than GitHub's triage role, no write access, no ability to launch Claude directly, could wait for a maintainer to authorize a run and quietly shift that run's own idea of when it had been authorized, so the already-privileged job treated data the collaborator posted afterward as if it had always been there.

This is not ordinary prompt injection. The data in question was created after the cutoff meant to exclude it, and it only got in because that cutoff itself was silently reassigned to a different person's action.

What Claude Code Action is supposed to guarantee

Two controls sit between a GitHub event and a repository-writing Claude run.

The first is a write-permission gate: before Claude gets any repository-writing tools, the Action checks whether the actor behind the triggering webhook actually has write access to the repo.

The second is a temporal cutoff: comments posted or edited after the trigger moment are filtered out of the context Claude sees, so nobody can sneak extra instructions in after a maintainer has already greenlit the run.

Both controls sound airtight individually. We went looking for whether the actor the first control checks and the timestamp the second control uses actually describe the same underlying event. They didn't, at least not for one common trigger type.

Reconstructing a timestamp from the wrong source

For most trigger events, Claude Code Action reads its timestamp from the webhook payload that fired. issues.labeled events work differently: the Action instead queries GitHub's API for the issue's full label history, filters to every event where a matching label was applied, and picks whichever happened most recently.

The resolver, in essence, does this:

const matches = events.filter(
  event => event.event === "labeled" && event.label?.name === labelName
);
const latest = matches.sort(byCreatedAtDescending)[0];
return latest?.created_at;

GitHub's label-event data includes both an actor and a unique event identifier. Neither gets used here. The resolver treats "an event of this type, with this label name, that happened most recently" as if that were enough to identify one specific, authorized event. It isn't.

Two decisions, checking two different things

Split this into the two questions the Action is actually answering.

The first: is this actor allowed to start a write-capable run? Answered by checking context.actor on the original webhook. A maintainer passes; a triage-level collaborator does not.

The second: which repository context belongs to that now-authorized run? Answered, for label triggers, by a live query that ignores actor entirely and just grabs the newest matching event.

permission identity: the original webhook's actor and event
content identity:    whichever live event matches type and label most recently

Those two answers are supposed to describe the same moment. Once they don't, anyone who fails the first question can still shape the outcome of the second, as long as they have enough GitHub permissions to produce a matching event of their own.

Watching the boundary actually move

We built a deterministic timeline to prove this out:

09:59  A maintainer-authored task already exists on the issue
10:01  Maintainer applies the "claude" label
10:02  Triage-level collaborator comments RELEASE_APPROVAL=attacker-controlled
10:03  Same collaborator removes the "claude" label, then reapplies it

At 10:01, when the run is supposed to be authorized, the 10:02 comment doesn't exist yet, so it has to stay out of scope no matter what.

Run the resolver with only the original 10:01 event visible, and it correctly returns 10:01, comment excluded. Add the 10:03 relabel event back in, and the resolver instead returns 10:03. The exact same comment, unchanged, now reads as pre-trigger content and lands in the prompt.

None of this required forging a webhook or impersonating the maintainer. The collaborator used only the ordinary label-management permissions GitHub already grants that role. The authorized job did the substitution itself, by trusting a live, mutable history over the event it was actually triggered by.

What was and wasn't the trusted boundary

To be clear: issue comments were never treated as trusted input, they're expected to be arbitrary and untrusted. Triage collaborators managing labels isn't a flaw either, GitHub deliberately gives that role exactly that capability.

The actual protected boundary is narrower: the snapshot of context that existed at the moment a maintainer's authorization fired. Claude Code Action explicitly filters out anything added after that snapshot so a privileged run's inputs can't shift after the fact.

That distinction, control over post-authorization input rather than simple access to untrusted content, is what separates this from a garden-variety prompt injection report.

Following the mutation all the way to a commit

We split verification into two independent layers so neither claim depended on the other.

The first layer isolated the resolver and prompt-building logic itself: resolveTriggerTimestamp(), fetchGitHubData(), the permission check, and prompt generation, fed scripted responses standing in for a maintainer and a triage-level actor. It confirmed the maintainer's webhook passes the gate cleanly, the triage actor's own webhook fails it every time, and only a later same-label event from the triage actor moves the cutoff.

The second layer went further, into the Action's bundled runtime and its real tag-mode tool access: edit, commit, push, loopback-only, against a local bare repository. The issue held an ordinary maintainer task: take the latest RELEASE_APPROVAL value, write it to a file, commit and push it. The attacker's comment held nothing but a plain value, no jailbreak language. Wherever the rebinding took effect, Claude wrote, committed, and pushed that value; wherever it didn't, the value was simply absent.

Isolating exactly what changed

We designed five controls so each one changed a single security-relevant variable at a time:

Scenario	Permission check	Cutoff selected	Attacker's value	Repository sink
Triage actor triggers directly	Rejected	Never reached	Never reached	No write occurs
Only the maintainer's original event exists	Allowed	10:01	Excluded	No attacker-chosen file
A later event with a different label exists	Allowed	10:01	Excluded	No attacker-chosen file
A later same-label event from the triage actor exists	Allowed, under the maintainer's webhook	10:03	Included	File committed and pushed
Same later event, but actor binding is enforced	Allowed, under the maintainer's webhook	10:01	Excluded	No attacker-chosen file

Every case reproduced across three clean runs each. Notably, the sink-level proof recorded zero permission denials the entire time, because as far as the Action's own logic was concerned, it was still faithfully executing the maintainer's original, authorized job.

What a repository actually loses

Any repository using issues.labeled with a Claude trigger label, combined with a write-capable workflow token, was exposed to having its authorized job's inputs quietly mutated by a collaborator well below write access.

Depending on the maintainer-authored task, admitted data could shape generated source or config, release metadata, the content of Claude's commits, which branches got pushed, and anything downstream that trusted those commits without a second look.

We rated this High rather than Critical: exploitation needs a label-triggered workflow, a collaborator with triage permissions, a timing window before the authorized job finishes its live lookup, and a maintainer task where the admitted data meaningfully changes the output.

Anthropic's assigned score reflects that conditionality:

CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

The actual root cause

Underneath the GitHub-specific details, this is a case of mutable semantic attributes standing in for a real event identity.

what should have been bound: the webhook's own, immutable event
what actually got bound:     the newest live event sharing type and label name

event === "labeled" and label.name === "claude" describe a whole class of events, not one specific event. Picking the newest member of that class makes the boundary sensitive to anything that happens after the original authorization, as long as it matches type and label.

The permission check was correct the moment it ran. The comment filter was correct for whatever timestamp it was handed. The failure lived entirely in the handoff between those two steps, where the timestamp's actual origin got lost.

How we'd fix it

The durable solution carries one authenticated event identity, unbroken, from authorization through context collection through execution.

Where GitHub exposes a trusted, immutable delivery identifier, use that instead of reconstructing anything from live history.

Where a live lookup is unavoidable, require the selected event's actor to match the original webhook's actor, anchor candidates to a job-receipt timestamp so nothing afterward can drag the cutoff forward, and fail closed on ambiguity.

Preserve the original webhook payload for trigger-time state, and add regression coverage for a different actor relabeling the issue mid-run.

What this means for agentic CI more broadly

Authorizing a job isn't only a decision about who may start it. It's also, implicitly, a decision about which inputs it's allowed to consume, and if that snapshot can shift after approval, the authorization can be correct while the resulting behavior isn't.

Two events sharing an action type and a label name are not the same event; they can belong to different actors and trust levels even when every field looks identical.

A role check reviewed in isolation ("can this role trigger the workflow") misses the more useful question: what can a role that fails it still influence once a stronger role has already passed.

Disclosure timeline

Date	Event
August 5, 2026	Report submitted to Anthropic through HackerOne (#3918594)
August 13, 2026	Anthropic validated the issue, assigned High severity, CVSS 4.0 score 7.5
August 14, 2026	Bounty of $XXXX awarded
August 24, 2026	Editorial cutoff; report still triaged and private, no confirmed fixed version

Checking your own exposure

Start by seeing whether your workflow even uses this trigger pattern:

grep -rn -E "anthropics/claude-code-action|issues.*labeled|types:\s*\?labeled" .github/workflows/

You're in scope if your workflow triggers on issues.labeled with a Claude trigger label, runs in tag mode or otherwise grants workspace edits plus commit and authenticated push, and hands the job a write-capable token.

Anyone with GitHub's triage role, or any other sub-write role, can add and remove labels freely without writing code, generating the newer same-label event this bug depends on.

Until a fixed version is confirmed, restrict who can apply your Claude trigger label to write-and-above roles, treat anything a label-triggered run commits or pushes as unreviewed until a human looks at it, and keep downstream CI or deploy steps from auto-consuming those commits.

Where this leaves things

Claude Code Action's write-permission gate worked exactly as intended: it rejected the triage collaborator's own attempts to start a run, every time. The vulnerability sat one layer deeper: an already-authorized job later reconstructed its own trigger boundary from mutable history, and accepted a newer event belonging to the very principal it had just rejected.

The invariant here is simple to state and easy to violate: the event that defines a privileged agent's input boundary has to be the same event that authorized the run. Keep that identity intact, and later activity, however legitimate on its own, can't quietly rewrite an earlier authorization decision.

This was originally published by CodeAnt AI's Security Research Team. Read the complete breakdown here →

Escaping Claude Code's Sandbox: A TOCTOU Bug That Let Repo Code Overwrite Host Files

Amartya Jha — Mon, 31 Aug 2026 09:08:39 +0000

A parent-directory swap timed against a permission check let sandboxed repo code redirect a host-owned file write. CVSS 7.7, High.

HackerOne #3882177 · Claude Code 2.1.217, macOS arm64 · CVSS 4.0 score 7.7, High

Sandboxing runs on a simple promise: code inside it cannot reach outside it. Claude Code, Anthropic's coding agent, keeps that promise on macOS by boxing in Bash and everything it spawns, while leaving one door unlocked: a trusted editor process that applies the file changes Claude has permission to make.

We at CodeAnt AI Security Research tested whether that door could be reached from the wrong side of the sandbox. It could. A process confined entirely to the Bash sandbox got the trusted, host-owned Edit tool to overwrite a file the sandbox had already been denied direct access to. No outside-write approval appeared anywhere, and no permission check failed. The file simply changed.

Two kinds of trust sharing one filesystem

Claude Code splits authority during a session. Bash commands and their children run inside an OS-level sandbox with restricted filesystem access, so a repository's tests and builds can execute without full run of your machine. Built-in tools like Edit run in the trusted host process, the part actually allowed to touch your project.

Permissions decide whether Claude may call a tool at all. Sandboxing then restricts what Bash and its descendants can do at the OS level regardless of permission. In acceptEdits mode, edits auto-approve only inside the working directory; Seatbelt enforces that boundary for sandboxed processes, which is why a direct outside write returns EPERM.

None of that is the problem. The problem sits one layer up: the assumption that the file a permission check looked at is still the file the trusted writer touches a moment later.

A file path is a set of directions, not a destination

A path like /workspace/project/config.json isn't a pointer to one fixed object. It's a sequence of instructions: enter this directory, then this one, then open this file. Every step resolves fresh, at the moment something reads it.

Change one directory partway through that walk, without touching the final filename, and you change where the whole path ends up. Turn project into a symlink pointing elsewhere, and the same string now means something entirely different.

That's a time-of-check-to-time-of-use problem (TOCTOU for short): a gap between when something is verified and when it's used, wide enough for the underlying object to change in between. Claude Code's Edit tool had exactly that gap.

Where the two checks stopped agreeing

Static analysis of Claude Code 2.1.217's embedded JavaScript showed how Edit authorizes and writes a file, in equivalent pseudocode:

checkParentResolutions(target);
await mkdir(dirname(target), { recursive: true });
await replaceFile(target, content);

The tool checks the target's parent directories, checks again to catch ordinary symlink swaps, creates any missing directories, then writes the file.

That second check narrows the window for simple symlink substitution but doesn't close it. It only compares path strings at one instant, never binding authorization to a stable directory handle or inode. And the recursive mkdir call, which takes real wall-clock time, runs after that last check and before the write. That's the gap.

Turning an ordinary developer workflow into the trigger

We didn't want to assume a repository could hand-pick an arbitrary Edit call, so we used a sequence any Claude Code user would recognize as normal:

A developer opens a repository they don't fully control.
They ask Claude to run the tests and fix whatever's failing.
Claude runs the repo's own test command inside the sandbox, exactly as designed.
A pretest step quietly launches a small helper process, still confined to the sandbox, and has it wait.
The test fails, reporting a missing fixture at a path that looks entirely ordinary.
Claude, being helpful, creates that fixture using its built-in Edit path.

The repository controls the test, the failure message, and the fixture path. It never has to guess what Claude would independently choose.

A simplified target: <workspace>/slot/signal/private/tmp/demo/outside/payload.txt. signal starts as an ordinary directory; next to it sits armed, already a symlink to /. The helper never leaves the sandbox: a direct outside write gets EPERM every time. Its only useful move: renaming two entries it already owns inside the project.

The swap itself

The helper needed to know exactly when to move. The signal is the mkdir call itself: the moment the first missing directory gets created, Claude Code's final resolution check has already run and passed.

At that instant it calls renameatx_np with RENAME_SWAP, exchanging two directory entries atomically:

before: signal = ordinary directory, armed = symlink to /
after:  signal = symlink to /, armed = ordinary directory

The untouched, textually identical target path now resolves somewhere else entirely. Effective target: /private/tmp/demo/outside/payload.txt.

Claude Code's host-side writer, unrestricted by the sandbox, finishes exactly as it was going to: creates a temp file, renames it over the target. It has no reason to suspect anything changed. The sandboxed helper never touched the outside file itself. It only flipped an entry it already owned.

Only the last step of the path was actually guarded

Claude Code's writer does refuse to follow a symlink in the final path component, a genuine defense that stops a simpler attack cold.

It doesn't help here, because this race happens on an ancestor directory, not the final component. Guarding only the last link in the chain does nothing to guarantee the earlier links stayed the same object they were when permission was granted.

The permission system reasoned about a string and a resolution it observed once. The writer, later, walked that same string again and got a different answer. That mismatch is the entire vulnerability.

Proving it beyond a single lucky run

We built the reproduction to leave zero ambiguity about which boundary was crossed: isolated canary files, a throwaway home directory, a deterministic local model fixture, and no Anthropic credentials or live services involved.

Five variations, each changing exactly one property, separated the bug from expected behavior. Each ran three consecutive times, clean every time:

Scenario	Outcome	What it proves
Direct `Edit` call to a path outside the workspace	Denied	The permission layer correctly recognizes outside writes
Sandboxed helper tries writing the outside canary directly	`EPERM`	Seatbelt correctly blocks the attacker from the real target
Same directory layout, swap never triggered	Canary untouched	The path is safe as long as object identity doesn't change
Swap timed against the `mkdir` signal	Canary overwritten, zero permission denials logged	The host writer crossed the workspace boundary
A sibling dev project watched by an autoreloader	Modified source executed	An ordinary downstream tool turns the overwrite into execution

What this actually gets an attacker

With this primitive, a malicious repository, a compromised dependency, or a prompt-injected command running inside the Bash sandbox could get the trusted host process to overwrite an attacker-chosen, user-writable file anywhere outside the workspace: modifying sibling projects, tampering with build configuration, corrupting files CI reads downstream, and in some cases running arbitrary code, when something already present picks up the changed file on its own.

To be precise: this isn't an unconditional remote-code-execution bug. Getting from "overwritten" to "executed" needs an existing consumer already watching that location. On its own, the proven impact is arbitrary modification of a file outside the authorized workspace.

Anthropic rated the report High, CVSS 4.0 score 7.7:

CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Why checking twice wasn't enough

The root cause is an authorization-to-use binding failure: the identity authorized at time T1 isn't the identity actually used at time T2. Rechecking the path narrows that gap but can't close it, since any later step that takes real time hands an attacker another window.

We also found the identical check-then-mkdir-then-write ordering in Claude Code's Write tool during static review. We're flagging the pattern, not claiming a second confirmed exploit.

Fixing it properly

The durable fix ties authorization and the eventual write to the same filesystem objects, not to a string re-resolved twice:

Open the trusted workspace root once and hold its descriptor for the whole operation.
Walk every ancestor relative to that descriptor using openat-style calls, never by re-resolving the full path.
Open each directory with O_DIRECTORY | O_NOFOLLOW, keeping descriptors alive until the write completes.
Create missing directories with mkdirat, relative to an already-verified parent.
Perform the final write with openat and renameat, not plain pathname operations.
If a component must be reopened across an async gap, verify its device and inode identity first.
Apply the same pattern everywhere this boundary shows up: Edit, Write, and any shared helper.

A pathname recheck before the final write is still worth having as defense in depth. It just can't be the only defense.

The broader lesson for agentic tools

Sandboxing a process doesn't remove its ability to influence what a privileged process does next. It can still shape diagnostics, file paths, and filesystem state the trusted side later consumes.

A pathname is not a durable identity; it's a recipe re-executed on demand. Any system that authorizes based on one resolution and acts on a later one needs to preserve object identity across that gap, not just recheck the string.

The strongest proof here was the contrast between a write that returned EPERM and a write, moments later, from the trusted side, that succeeded against the same target.

Should you worry about this right now

Check your version first: claude --version. This finding was reproduced on Claude Code 2.1.217, macOS arm64. Confirm affected and fixed ranges directly with Anthropic.

You're in the risk zone if: you're on macOS, you let Claude run repository commands in the Bash sandbox while using the built-in Edit/Write tools, you run in acceptEdits mode, and you regularly open repositories you don't fully trust.

Until a fixed build is confirmed, prefer explicit per-edit approval over acceptEdits for code you don't control, and watch for sibling projects or build watchers running alongside your workspace, since that's what turns an overwrite into execution.

The takeaway

The invariant this bug violated is easy to state and hard to implement everywhere it needs to hold: the object that receives a write has to be the same object, reached through the same verified chain of ancestors, that the permission system actually authorized.

If a system checks a path once and follows that same path again later, an attacker who can move what's underneath the path (without touching the string itself) can walk past every check while each one still reports success.

This was originally published by CodeAnt AI's Security Research Team. Read the complete breakdown here →

CVE-2026-71511 · Read a member's card, receive their password hash

Amartya Jha — Tue, 25 Aug 2026 09:20:02 +0000

CVSS 6.5 · Sensitive data exposure (CWE-200) · Fixed in Dolibarr 24.0.0

Every reply is supposed to pass a redactor that blacks out secrets. The Users redactor blacks out the password. The Members redactor, same job, next desk, forgot that one line, and hands the password verifier out with the card.

The attack in six steps

Every API reply runs through a "cleaner". Its job is to strip secrets before anything is sent back.
Line the two cleaners up side by side. The one for users against the one for members. (this is the break)
The Users cleaner removes the stored password hash. Exactly as it should.
The Members cleaner doesn't. One missing line, doing the identical job one desk over.
A "read members" key receives every member's password verifier. And from the list route, all of them at once.
Confirmed live, not a placeholder. Matched to the database, and it validated the real password. → credential exposure.

Before an application sends any record back to a caller, something has to decide what to leave out. Passwords, keys, the private machinery of an account, all of it is supposed to be stripped on the way out, by a step whose only job is redaction. When that step is thorough, you never think about it. When it isn't, secrets walk out in plain sight.

This is the story of two of those redactors, doing the same job for two similar kinds of record, where one remembered to black out the password and the other simply didn't, and how that one missing line handed every member's password verifier to anyone allowed to read a member card.

It is a simple example of how sensitive data exposure can happen inside an otherwise legitimate API response. The endpoint itself works as designed. The problem is that the Dolibarr security check responsible for removing sensitive credential data was incomplete.

Found by holding two things side by side

This finding didn't come from a clever attack. It came from comparison. Dolibarr redacts a user record and a member record with two separate pieces of code meant to do the same thing. So we put them next to each other and read them line for line.

The user redactor removed the stored password verifier before sending, exactly right. The member redactor, doing the identical job one desk over, didn't. One missing line, in one of two near-twin functions.

This is the kind of issue that can be missed by a straightforward application security assessment. Nothing needs to be injected or bypassed in the traditional sense. The vulnerability appears when two pieces of code responsible for protecting the same sensitive data are compared and found to enforce different rules.

What that one line leaks

The consequence is not subtle. An account holding nothing more than the right to read members, an ordinary, widely-granted permission, receives, along with each member's ordinary details, the stored verifier for that member's password. And because the same gap sits on the route that lists all members, you don't get them one at a time. You get the whole set in a single reply.

We confirmed the value was the real thing rather than a harmless placeholder by matching it back to the database and checking it corresponded to the member's actual password. It was live.

For a security researcher or penetration tester, that distinction matters. This was not simply a field that looked sensitive in a source-code review. We verified that the API returned real credential material and traced it back to the underlying application data.

The whole pattern in one line

If you want the entire theme of this research compressed into a single example, it is this one. The safe way already existed. The correct redactor was written, working, and sitting a file away. The neighbouring code that did the same job just skipped it. Not a hard problem, not a clever oversight, just a copy that wasn't quite a copy.

That is what “split-brain authorization” looks like at its smallest: two places responsible for the same rule, quietly disagreeing, with no one comparing them until someone does.

What closes it

The fix in 24.0.0 brings the member redactor in line with the user one, so the stored password material is stripped before any member record is sent, from single-record and list replies alike.

The lesson is almost embarrassingly practical: when two parts of a codebase are supposed to enforce the same rule, the highest-value test is often not an exploit at all. It is reading them side by side and asking whether they actually match. One of them got it right. Diffing it against its neighbour is how you find the one that didn't.

This is also why effective application penetration testing combines testing the running application with understanding how security controls are implemented. A response can look perfectly normal while still exposing sensitive data if one authorization or redaction path behaves differently from its counterpart.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71510 · Ask enough yes/no questions and you know everyone's salary

Amartya Jha — Tue, 25 Aug 2026 09:18:01 +0000

CVSS 6.5 · Authorization oracle → blind disclosure (CWE-863 / CWE-200) · Fixed in Dolibarr 24.0.0

You can't see the salary column, but the search box will happily answer “is this person's salary above 50,000? yes or no.” Ask twenty smart questions and you've read the exact number without ever seeing it.

The attack in six steps

The user list has a search filter: you can narrow it by a column's value.
It's safe from SQL injection: the obvious attack was checked, and it holds.
The unasked question: which columns may you filter on?: the answer was any of them, including salary and the password hash. (this is the break)
Those columns are stripped from the reply: so you never actually see the value.
But "filter salary above X" returns a row, or nothing: that single yes/no is a leak.
Binary-search the answers to the exact number: salaries recovered blind, plus a case-folded image of the hash. → blind disclosure.

There is a whole class of secret you can steal without ever being shown it. You don't need the system to hand you the value. You only need it to answer yes-or-no questions about it, honestly, as many times as you like. Twenty good questions are enough to pin down almost any number.

This is the story of a search box that would answer exactly those questions about columns it was supposed to keep hidden, salaries, and even the stored password verifier, and how a low-privilege account read them precisely, blind, without the system ever displaying a single one.

It is the most subtle finding in the set, because nothing here looks broken. No error, no leak on the screen, no obvious hole. Just a search filter answering a question it should have refused to consider.

This is the kind of web application security issue that can slip past a straightforward vulnerability scan: the search feature is not injectable, the response does not expose the sensitive field, but the application's authorization logic still lets a low-privilege user interrogate it.

The obvious attack, and the one underneath it

The user list has a search filter, so you can narrow the list by a column's value. The reflex is to test it for injection: can you break out of the query and run your own? We checked, and the answer was no. On that front it is safe, and a lot of reviews would stop there satisfied.

The second, quieter question is not about breaking the query at all. It is about authorization: which columns are you even allowed to filter on? The answer turned out to be all of them, including the salary fields and the password verifier that the results are so careful never to display.

This is where security testing has to go beyond checking whether an endpoint returns the expected response. A penetration test also needs to ask whether a low-privilege user can use an otherwise legitimate feature to access information they are not authorized to interrogate.

Turning a filter into a yes/no oracle

Those columns are stripped from what comes back, so you never see a salary in the list. But you can still filter on one. And a filter you can apply to a hidden column is a question the system will answer: ask it to show everyone whose salary is above fifty thousand, and either a matching row comes back or it doesn't. Row or no row. Yes or no.

That single bit is the whole leak. Ask “above 50,000?”: no. “above 25,000?”: yes. “above 37,000?”: and so on, each question halving the range that's left. In a couple of dozen questions you have squeezed the exact figure out of a value the screen never showed you. Point the same technique at the stored password verifier and you can walk it out piece by piece.

The honest part: what it is not

A responsible finding has to say where the danger stops, and we were careful to. The password material you can recover this way is not a usable key to log in with: Dolibarr stores it in a form it will not accept back as a login, and the recovered image is case-folded rather than exact. So this is a serious disclosure, real salaries, real hidden fields, read blind, but it is not, by itself, account takeover. We tested that boundary, confirmed it held, and wrote the disproof into the report so a reviewer could see we had actually checked rather than assumed.

That distinction matters for trust. It is easy to inflate a finding by implying the worst. It is more useful, and more credible, to show exactly how far it goes and exactly where it stops.

Why it's easy to miss, and what closes it

This is the kind of hole endpoint-by-endpoint testing walks straight past. The filter isn't injectable. The response doesn't leak. Nothing throws an error. The only thing wrong is that a question was allowed which never should have been, and you only see it if you ask, of a search feature, not “can I break this,” but “which fields am I permitted to ask about.”

The fix in 24.0.0 restricts which columns the filter will accept, so hidden fields can no longer be interrogated through the back door of a yes/no search. The lesson is to treat a filter as an authorization surface, not just an injection surface: every column you let a caller filter on is a column you are willing to answer questions about, one bit at a time.

This is also why security research needs to look beyond individual endpoints. In this case, the issue was not an obvious injection vulnerability. It was the interaction between filtering, authorization and sensitive fields, which is exactly the kind of behaviour that deeper application security testing can uncover.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

CVE-2026-71509 · Approve your own expenses — and your whole team's

Amartya Jha — Tue, 25 Aug 2026 09:16:07 +0000

CVSS 6.5 · Approval / access-control bypass (CWE-862) · Fixed in Dolibarr 24.0.0

The big “Approve” button correctly needs a manager. But the plain “edit this report” form lets you type approved and name anyone as the approver, straight into the fields, with no manager required.

The attack in six steps

Expense reports need a second person to approve: basic separation of duties.
The dedicated Approve button checks for it: the front door is genuinely locked.
But the generic "update report" route writes the same fields: status and approver, set directly. (this is the break)
Nothing checks the approver differs from the author: or that you hold the approval right at all.
Mark your own claim approved and name anyone as approver: from an account that can only file claims.
Your claim, and a subordinate's, enter the payable queue: the second signature never happened. → self-approved payouts.

Expense approval is a textbook example of separation of duties: the person who files a claim must not be the person who approves it. That one rule is what stands between a company and an employee quietly signing off their own reimbursements. Dolibarr knows the rule, and the obvious button that approves a report enforces it properly.

This is the story of a second, plainer path that writes the very same fields the Approve button does, without asking whether the person approving is the person who filed.

The front door is locked. The side door was left open, and it leads to the same room.

The question with an obvious answer, and a real one

With any approval workflow, the first question to ask is the classic one: can the same person file a claim and approve it? We asked it of the dedicated Approve action, and the answer was a reassuring no. That action checks for the right permission, exactly as it should. A shallow security test stops here and calls it safe.

The real answer lived one path over. Alongside the Approve button, Dolibarr has a generic “update this expense report” path, the kind of catch-all that lets you edit a report's details. And that path lets you write the report's status and its approver directly, as if they were ordinary fields like a date or a note.

This is where API security testing and business logic testing matter. An endpoint can correctly protect its dedicated privileged action while another route exposes the same state change without enforcing the same authorization rules.

Signing your own name on the approval line

So an account that can only file claims opens the generic update path, sets the status to approved, and writes itself, or anyone it likes, into the approver field. Nothing checks that the approver differs from the author. Nothing checks that the account holds the approval right at all. The claim moves into the payable queue, approved, with a name on the approval line that the filer chose.

We did it to our own claim, and then to a subordinate's, from an account that was never supposed to approve anything.

Why a correct check isn't enough

The uncomfortable lesson here is that the Approve button being correct bought almost nothing. A control is only as strong as the weakest path that can reach the same state. If one carefully guarded action sets a field, and a second, generic action sets the same field with no guard, then the second action is the real security boundary, and it is wide open.

The damage is money leaving on approvals that never happened. In a company relying on Dolibarr to enforce the two-person rule on reimbursements, this quietly dissolves it: a single employee can file and approve, or approve for others, and push claims into the queue that pays them.

For Dolibarr security testing, this is an important distinction. Testing only the intended approval workflow can miss a business logic vulnerability exposed through a generic update endpoint. Effective penetration testing has to trace sensitive state changes across every route that can create them.

What closes it

The fix in 24.0.0 brings the generic update path under the same rule the Approve action already enforced. The status and approver fields can no longer be written freely, and the separation between filing and approving holds on every path, not just the obvious one.

The takeaway generalises to any workflow with a privileged step: find every path that can write the state, not just the one built for it. A locked front door means nothing while a back-office form writes the same fields with no check at all.

This is also the kind of authorization gap that a web application penetration test should look for: not just whether a user can access an endpoint, but whether they can use an alternative endpoint to reach a privileged application state they were never meant to control.

The fix. Upgrade to Dolibarr 24.0.0. That closes this finding. Want to know where your own app disagrees with itself? → Start with a free CodeAnt pentest

← Back to all nine findings

DEV Community: CodeAnt AI

Why Your $6,500 Penetration Test Will Cost You More Than the $47,000 One

The Quick Numbers

The Scope Is Usually Where the Difference Starts

Methodology Depth Changes the Price

$3,000–$8,000: Baseline External Testing

$8,000–$25,000: Full External / Black Box Testing

$10,000–$40,000: Gray Box / Authenticated Testing

$15,000–$60,000: White Box / Source Code Testing

$25,000–$100,000+: Integrated Testing

Continuous Testing: $5,000–$20,000/Month

Cost vs. Coverage

The Finding Quality Test

What is vulnerable?

How was it validated?

Why does it happen?

What is the impact?

How should it be fixed?

The Attack-Path Question

The Retest Question

The Compliance Deliverables Gap

The Checklist to Put Beside Every Quote

So, Is the $22,000 Pentest Worth It?

FAQ

How much does a penetration test cost in 2026?

Why can two pentest quotes differ by 3×?

Is a cheap penetration test useless?

Should retesting be included?

Is black box, gray box, or white box testing best?

External Penetration Testing in 2026: A Technical Methodology, Tool Stack, and Attack Surface Guide

1. Define the Attack Surface Before Testing It

2. Phase One: Passive Reconnaissance

2.1 DNS Enumeration

A / AAAA

MX

TXT

NS

3. Test for DNS Zone Transfers

4. Certificate Transparency

5. ASN and IP Range Discovery

6. Historical URL Discovery

7. Public Repository Reconnaissance

8. Build the Initial Asset Inventory

9. Phase Two: Active Reconnaissance

10. Subdomain Enumeration

11. Full Port Enumeration

12. Prioritize the Interesting Ports

13. Web Technology Fingerprinting

14. Directory and Endpoint Discovery

15. API Enumeration

16. Authentication Testing

17. Authorization Testing

18. Test Alternate API Versions

19. Vulnerability Scanning

20. Scanner Finding vs Real Finding

21. Validate Exposed Redis

22. Validate Database Exposure

23. Exposed Management Interfaces

24. Cloud Attack Surface

Object storage

Public load balancers

Cloud-hosted databases

Kubernetes

25. Public S3 Bucket Discovery

26. Exposed .git Directories

27. Exposed .env Files

28. Subdomain Takeover Testing

29. The Findings Automation Commonly Misses

Different authorization between UI and API

Production and staging have different security controls

API v1 and v2 implement authorization differently

Legacy endpoints remain accessible

Forgotten infrastructure has stronger connectivity than expected

30. Attack-Path Thinking

31. External Pentesting Tool Stack

32. External vs Internal Penetration Testing

33. Reporting a Finding Properly

What is vulnerable?

Where is it?

How was it validated?

26. Exposed `.git` Directories

27. Exposed `.env` Files