DEV Community: Amartya Jha

Your Perimeter Will Fail. The Real Question Is How Far an Attacker Gets After.

Amartya Jha — Thu, 17 Sep 2026 03:46:16 +0000

TL;DR: External tests and scanners check your perimeter. Neither answers the question that decides how bad a breach gets: once someone is inside, how far can they go? That is what internal penetration testing validates, using an assumed-breach model. Here is what it tests, when you actually need it, and why once a year is no longer enough.

A phishing email lands. A credential leaks in a breach. A contractor's laptop gets compromised. The question is not whether an attacker gets inside. It is what they can reach once they are.

Internal penetration testing answers that. It starts from a foothold already inside your network, a standard user account or a compromised workstation, and finds out whether your segmentation, your Active Directory hardening, and your monitoring can actually stop an adversary who is already past the front door.

And the odds favor the attacker getting that foothold. Stolen credentials are still the single most common way in, the initial vector in 22% of breaches and present in 88% of basic web application attacks, according to the Verizon 2025 Data Breach Investigations Report.

Why the Internal Network Is the Real Attack Surface

Your perimeter gets hardened through constant exposure. Your internal network was designed for productivity and trust: broad AD trusts, over-privileged service accounts, segmentation that exists on a diagram but breaks in practice.

An external test might find SQL injection on your login page. An internal test discovers that once inside, an adversary can enumerate every domain user, crack a service account password through Kerberoasting, move laterally with pass-the-hash, and reach every data store, often within hours.

That is the difference between catching an attack at the first foothold and reading about your breach in the news six months later.

What It Actually Tests

Internal pentesting is adversarial exploitation from an assumed-breach position. It starts from a realistic foothold, a domain user, a compromised workstation, a VPN user, or an authenticated SSO session, and focuses on three things: lateral movement, privilege escalation, and data exfiltration.

The techniques fall into a few families:

Active Directory exploitation: Kerberoasting, AS-REP roasting, DCSync, Golden Ticket.
Credential harvesting: LSASS dumping, NTDS.dit extraction, password spraying.
Network attacks: SMB relay, LLMNR/NBT-NS poisoning, ARP spoofing.
Misconfigurations: over-privileged service accounts, weak ACLs, unpatched systems.

The goal is not to find vulnerabilities. It is to prove exploitability and map the path from initial foothold to critical impact. That path looks like this:

Standard user account
  ↓ (Kerberoasting a vulnerable SPN)
Service account hash
  ↓ (cracked offline, password reused)
Local admin on file server
  ↓ (credential dump from LSASS)
Domain admin session
  ↓ (DCSync attack)
Full Active Directory control

One over-privileged service account plus one reused password is often the whole chain. Hours, not weeks.

Internal vs External vs Vulnerability Scanning

These three get conflated constantly, and the confusion changes how you prioritize fixes.

	Vulnerability scanning	External pentest	Internal pentest
Threat model	Known CVEs	Attacker at the perimeter	Post-breach adversary inside
Start position	Tool, no context	Outside, zero access	Inside, standard creds
Goal	Detect known CVEs	Breach the perimeter	Validate lateral movement and escalation
Depth	Detection only	Validates a breach	Chains exploits to business impact

Scanning tells you what is broken at the component level. External testing shows how attackers chain your app flaws together. Internal testing exposes the architectural assumptions that stop holding the moment someone is inside, like your microservices trusting each other because they are "internal only." For the perimeter half of the picture, see External Penetration Testing: What It Covers and What It Misses.

When You Actually Need It

Two kinds of triggers should put internal testing on your roadmap.

Compliance triggers. PCI DSS 11.4, SOC 2 CC7.1, ISO 27001 8.8, and the HIPAA Security Rule all expect internal testing that validates controls beyond the perimeter, including segmentation.

Business triggers. A merger, a cloud migration, a Zero Trust rollout, a remote-work expansion, a security incident, or a segmentation project. Each one reshapes your internal attack surface in ways that invalidate last year's clean report.

A quick readiness gut-check before you spend the budget: do you have MFA everywhere, patch management inside 30 days, EDR, least-privilege access, and centralized logging? If not, fix those first. Testing too early just restates problems you already know about, and roughly the entire backbone of lateral movement, credential theft, is exactly what MFA blocks.

Choosing an Approach

Traditional firms: elite manual testing, but point-in-time, expensive, and slow, with no code context.
Automated scanners: continuous and cheap, but 30 to 50% false positives and no exploitation validation.
Code-aware platforms: continuous code security plus AI-driven offensive testing informed by codebase intelligence. Testing starts already knowing where sensitive data flows and which endpoints matter, so it is more targeted, findings carry exact file and line numbers, and re-scans are fast.

The code-aware angle is the one worth understanding, because it changes the scope of the test. When the platform has already read your codebase, testers know where the authentication logic lives and can aim at the endpoints that handle high-value operations, validating whether the issues found in code review are actually exploitable in production.

The Takeaway

External tools, researchers, and annual auditors can tell you your perimeter looked clean on the day they checked. None of them can tell you what an attacker reaches once they are inside, on the version of your system you shipped this morning.

Internal penetration testing answers that. Run continuously, it stops being a yearly compliance chore and becomes an early-warning system. If you want to see it on your own environment, scope your five most sensitive internal systems, your customer database, CI/CD pipeline, admin console, source repos, and identity provider, and run a gray-box test against them. Gray box mirrors a realistic insider threat better than any other mode.

Originally published on the CodeAnt AI blog, where the full version includes the readiness decision tree, the preparation checklist, the post-test remediation framework, and an FAQ. If this was useful, drop a comment on what your team runs today, or follow for the rest of the series.

Your Pentest Report Says "SQL Injection on /api/search." It Won't Say Which Line.

Amartya Jha — Thu, 17 Sep 2026 03:42:58 +0000

TL;DR: External penetration testing still matters, but the classic once-a-year model has six structural gaps that hurt teams shipping weekly. Here is what external testing actually covers, where it breaks down, and how a code-aware approach closes the gap between a perimeter finding and the pull request that fixes it.

Your security team just handed you a 73-page external penetration testing report with 50+ findings. "SQL injection on /api/search." But which query? Which file? What's the fix for your ORM? The report doesn't say.

By the time you ship a patch and wait six months for a re-test, your team has merged 200 more pull requests. Any one of them could have introduced the next vulnerability, and nobody is looking.

External penetration testing is still essential. It validates your perimeter, it satisfies auditors, and it tells you what an internet-based attacker sees before they attack. But six structural gaps stop the traditional model from keeping pace with modern release velocity. And the pressure is not theoretical: exploited vulnerabilities jumped to 20% of breaches as an initial access vector, up 34% year over year, in the Verizon 2025 Data Breach Investigations Report.

The Three Depths, In Plain Terms

Before the gaps, fix the three testing depths, because everything else turns on them.

Black box is how an attacker sees you from the outside with zero inside knowledge. Public URLs only, enumerate from scratch. If your network is not penetrable, no attacker can see your code. Great for validating the perimeter, useless for tracing authenticated flows or privilege boundaries.

White box is the opposite. A tester reads your entire codebase, every API call, every database call, and builds a threat model from your logic, dependencies, secrets, and infrastructure. Is there an unauthenticated API call hitting the database directly with no rate limiting? From outside you would never know. From the code you see it on the first read.

Gray box clubs the two together. You know from the code that a public API quietly triggers a downstream internal API that makes a database call. So you step outside the network, act like an adversary, and use that inside knowledge to reach the thing that was never meant to be reachable.

That last one is the interesting bit, and we go deeper on all three in Black Box vs White Box vs Gray Box Penetration Testing.

The Five-Phase Attack Lifecycle

A rigorous external engagement runs through five phases.

Reconnaissance. Certificate Transparency log mining, DNS enumeration, cloud asset discovery, tech fingerprinting. This surfaces the forgotten admin.staging.yourapp.com and the S3 bucket nobody remembers.
Service discovery. nmap, httpx fingerprinting, API discovery through JavaScript bundle analysis, auth boundary probing.
Manual validation. Where professional testing separates from scanning. Custom payloads, chaining low-severity findings into critical ones, business logic a scanner cannot understand. Chaining alone can eat seven to eight hours, and then a human researcher re-validates every finding and pushes it further.
Exploitation. Prove it with a working PoC:

# Authentication bypass PoC
curl -X POST https://api.yourapp.com/admin/users \
  -H "X-Forwarded-For: 127.0.0.1" \
  -d '{"role":"admin","email":"attacker@evil.com"}'

Evidence collection. Audit-grade output: curl PoCs, CVSS scores, control mapping, remediation guidance.

The finding classes that recur are the usual suspects: misconfigured cloud storage, missing auth on API endpoints, OWASP Top 10 issues like SQL injection, and IDOR/BOLA patterns. In every case the report tells you the endpoint, not the line. That gap is the whole point of this post.

The Six Gaps Traditional External Testing Leaves Open

These are not six unrelated problems. They are symptoms of one thing: external testing operates outside your codebase, while your vulnerabilities live inside it.

Gap 1: No code-level context. Testers can confirm /api/users returns user data. Without code access they cannot trace whether user input reaches a dangerous sink or whether an authorization check is bypassed internally.

Gap 2: Point-in-time testing. You pass in January. Over the next 51 weeks you ship 26 releases with new endpoints and auth flows that were never tested. Your clean January report still satisfies the auditor in December, on a fundamentally different attack surface.

Gap 3: The remediation disconnect. "Auth bypass on /api/users. CVSS 8.1. Implement proper authorization checks." Which middleware? Which controller? What data flow? The tester proved the exploit from outside and never saw your code, so engineering guesses, and the guessing loop runs 16 to 20 weeks.

Gap 4: Missing attack chains. Three findings, none critical: GraphQL introspection (Low), BOLA (Medium), weak passwords (Medium). Three months later an attacker chains all three into a full breach. Scanners match signatures one at a time. A two-week engagement does not have time to explore every chain.

Gap 5: Compliance evidence vs real security. An annual report cannot answer "how do you validate security between tests?" or "prove this fix never regressed?" Frameworks increasingly want a continuous evidence trail, not a yearly snapshot.

Gap 6: External-only misses insider knowledge. Real attackers scrape GitHub for leaked creds, read JS bundles for internal endpoints, and operate with partial inside knowledge. A pure black-box test never has that context.

The common thread: a perimeter finding is only half the story. The other half is the line of code that caused it.

Code-Aware Offensive Testing, The Short Version

Code-aware testing operates on both sides of the perimeter at once. The same engine that reviews your pull requests, understands your auth middleware, and traces your data flows also runs reconnaissance against your external surface. When it finds an auth bypass on /api/users, it already knows which middleware handles that route, because it has been reviewing that code for months.

The practical difference shows up in the finding itself. Instead of a CVSS number and a shrug, you get:

finding_id: AUTH-001
file: src/controllers/UserController.java:47
issue: "Missing resource ownership check"
source: req.params.userId
sink: db.query() without validation
remediation: |
  if (req.user.id !== parseInt(userId)) {
    return res.status(403).json({ error: "Forbidden" });
  }

File, line, source, sink, fix. That is what turns a report into a merged pull request.

From Finding to PR Fix

The workflow that actually closes findings is not complicated, it just has to be code-precise.

Triage on exploitability, not raw CVSS. A working PoC makes it P0. Pre-auth jumps the queue. PHI, PII, or payment data in the blast radius means fix now.

Patch at the layer that survives a re-test. Enforce the invariant at the query, not in a decorator:

# Survives re-test: ownership enforced at the query level
def get_document(doc_id, current_user):
    return db.query(Document).filter(
        Document.id == doc_id,
        Document.owner_id == current_user.id  # explicit ownership
    ).first_or_404()

Parameterize input rather than escaping it:

# Fails re-test: escaping is fragile
query = f"SELECT * FROM users WHERE email = '{sanitize(email)}'"

# Survives re-test: parameterization enforced by the driver
db.execute("SELECT * FROM users WHERE email = ?", [email])

Lock the fix with a negative test, then re-scan:

def test_document_access_requires_ownership():
    user_a = create_user()
    user_b = create_user()
    doc = create_document(owner=user_a)
    response = client.get(f"/api/documents/{doc.id}", auth=user_b)
    assert response.status_code == 403  # negative test

When Each Approach Fits

Not every team needs the same thing.

Traditional firms fit stable surfaces, quarterly-or-less releases, and bespoke red-team work. Trade-off: 2 to 4 week turnaround, separate re-test fees, findings as reports not tickets.
Continuous monitoring fits SaaS that needs 24/7 surface detection. Trade-off: flags potential issues but lacks exploitation depth and code-level remediation.
Code-aware offensive testing fits weekly deploys, API-driven architectures, and continuous-evidence compliance. Findings map to code, chains get built, re-scans are fast.

If you ship weekly, handle regulated data, and cannot easily translate reports into developer tickets, the code-aware model is probably the right fit.

The Takeaway

External penetration testing earns its place for compliance and perimeter validation. But a traditional external test alone cannot keep pace with weekly releases. The fix is not to replace it, it is to give it code memory, so a perimeter finding arrives with the line that caused it and the diff that closes it.

If you want to see the gap on your own app, the fastest way is to point a code-aware scan at your ten most sensitive internet-facing endpoints and compare what comes back to what your last report said.

This post was originally published on the CodeAnt AI blog, where the full version includes the complete six-gap breakdown, the compliance evidence workflow, and an FAQ. If you found this useful, a follow or a comment on what your team runs today is always appreciated.

GitLab vs GitHub Is Not a Code Review Decision

Amartya Jha — Wed, 16 Sep 2026 06:12:13 +0000

Every GitLab vs GitHub comparison is really a pricing comparison wearing a feature table. They are useful if you are picking a platform from nothing, which is almost nobody reading them.

The question a team already on one of these platforms actually has is narrower. How does review differ, and is the difference worth doing anything about?

Having looked at both properly, the answer is that they are far closer than the comparisons suggest, and where they differ they differ in opposite directions.

Start With What Makes This Comparison Different

On Bitbucket and Azure DevOps, adding a review tool fills a hole the platform left open. Neither ships meaningful native security scanning.

GitLab and GitHub are the two platforms that do. GitLab has SAST, secret detection, dependency scanning, container scanning and DAST built in as pipeline templates. GitHub has Advanced Security covering secret scanning, dependency review and CodeQL.

So this is not a comparison about who has scanning. It is about tier, depth and noise, and both platforms put their deeper capabilities behind their upper plans.

GitLab's Real Advantage Is Policy Expression

GitHub's model is essentially one rule: require N approvals, and require code owners where CODEOWNERS matches.

GitLab layers named approval rules on top of CODEOWNERS. You can define a Security rule requiring two approvals from one group and a Database rule requiring one from another, both applying independently to the same merge request.

It also supports sections in the CODEOWNERS file itself:

[Security][2]
/src/auth/  @security-team

[Database][1]
/db/migrations/  @data-team

The [2] requires two approvals from that section. There is no GitHub equivalent, and on GitHub the same intent takes two places: a file saying who, and a branch protection setting saying how many.

For a small team that difference is academic. For an organisation whose review policy was negotiated with a compliance function, it is the difference between the policy being enforced and the policy being approximated.

GitLab Also Has Two Scanners GitHub Does Not

Container scanning and DAST have no direct GitHub equivalent, and this almost never appears in these comparisons.

There is a structural difference in how the scanning runs, too. GitLab makes security a pipeline job:

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml

That is the whole basic setup, and the elegance is real: security config is versioned in the repo, reviewed in a merge request, and one hosted template can be shared across an entire estate and changed centrally.

GitHub runs most of Advanced Security as platform settings rather than jobs. Which means the audit question changes from "show me the commit" to "show me who had admin".

GitHub's Advantage Is Everything Around It

The Actions marketplace is substantially larger, and that matters more than it sounds like it should.

A security vendor with a polished GitHub Action and a thin GitLab template will produce a materially worse experience on GitLab, regardless of how good the underlying analysis is. That is a vendor decision rather than a platform one, and it is worth checking per tool rather than assuming parity.

Ecosystem familiarity is the other half. If your open-source contributors, your new hires and your tooling all assume GitHub, that is a real cost to being elsewhere.

Both Native AI Reviewers Have the Same Two Gaps

GitLab Duo and GitHub Copilot code review are more alike than either vendor suggests.

Both are general models reading a diff. Neither performs dedicated static security analysis. And on neither platform does an AI comment satisfy a required approval.

That last point is the one worth internalising. An AI reviewer that comments improves the conversation on a change. It does not alter what can merge. On both platforms, the things that gate are a human approval and a pipeline or status check, and the AI reviewer is neither.

The licensing differs. Duo is an add-on on top of a paid tier, so two per-seat line items. Copilot is a subscription. Neither replaces the platform's separate security product.

The Thing Neither Platform Solves

Both are good at producing findings. Neither tells you which findings an attacker could actually reach in your codebase.

Severity measures impact if exploited. It says nothing about whether exploitation is possible on a path your code actually calls. The gap between those two is where every security backlog comes from, and it grows at whatever rate your scanners run.

That is the problem worth solving, and it is not a platform choice. It is a tooling one. CodeAnt AI runs review and security in the same pass on either platform, checks findings for reachability before a developer sees them, and posts a status check the merge can gate on.

So Which One

GitLab if you want one application covering source, CI and security rather than assembling them, if self-managed is a requirement rather than a fallback, or if your review policy is complex enough that approval rules express it better than a reviewer count.

GitHub if ecosystem reach matters, if the Actions marketplace saves you building integrations, or if open source and contributor familiarity are part of the calculation.

If you already run one, the review differences are not a migration case. Approval rules are nice. Container scanning is genuinely useful. Neither justifies moving a platform every workflow in your organisation is built around.

The Actually Useful Exercise

Forget the comparison. Open your most active repository and list what runs on a merge request today.

AI review, yes or no. SAST, yes or no. Secret detection, yes or no. Dependency and container scanning, yes or no.

Then check which of those can block the merge rather than only reporting.

Most teams find the list shorter than they expected, and the gap is almost never the platform.

Originally published at codeant.ai, with the full feature comparison, a side-by-side walkthrough of the same change on both, and a migration mapping if you are moving between them.

I Automated Copilot Code Review on Every Pull Request. Here's What It Still Can't Do

Amartya Jha — Wed, 16 Sep 2026 06:04:23 +0000

The first time I turned on Copilot code review, I watched it comment on a pull request within ninety seconds, felt genuinely impressed, and then spent ten minutes working out why the merge button was still greyed out.

That gap between what it does and what it changes is the whole story. Copilot reviews. It does not approve, it does not gate, and it does not look for the class of problem that actually ends up in an incident report.

None of that makes it a bad tool. It makes it a tool with a shape, and knowing the shape before you build a workflow around it saves the conversation I had with my own team three weeks later.

Here is the setup, and then the honest part.

Getting It Running

You need a paid Copilot plan, and GitHub CLI v2.88.0 or later if you want to do this from a terminal.

Requesting a review is the same gesture as asking a colleague. Open the pull request, find Reviewers in the sidebar, pick Copilot. Or from the command line:

gh pr create --fill --reviewer @copilot

The @ matters. Older CLI versions will not accept it at all.

One thing nobody tells you: the review runs as a GitHub Actions workflow. When a review does not appear, the Actions tab has a run called Copilot code review with real logs, and that is where the answer usually is. I spent an embarrassing amount of time looking everywhere else first.

The Part That Actually Saves Time

Copilot's comments often come with a suggestion block you can commit straight from the pull request. Useful, and applying them one at a time produces a commit per fix, which turns a tidy branch into fourteen commits called "Potential fix for pull request finding".

Use the Files changed tab and Add suggestion to batch instead. Queue everything, then commit once.

If several comments have no ready-made suggestion, or a fix spans files, there is a third option on the summary comment: Fix batch with Copilot. The coding agent works server-side and pushes to your branch a few minutes later. That handles what suggestion blocks cannot, because it writes changes rather than committing pre-written ones.

You can also argue with it. Reply mentioning @copilot in the thread and it responds, having read the whole conversation. Sometimes it concedes. Sometimes it explains something you had not considered. Occasionally it is just wrong, and you resolve the thread and move on.

Making It Automatic Without Making It Annoying

Manual requesting works until someone forgets, which means review coverage depends on who opened the pull request. That is a strange property for a quality process.

Repository Settings, then Rules, then Rulesets. Create a branch ruleset targeting your default branch and enable Automatically request Copilot code review.

The sub-setting underneath it is the one people miss: re-run on new commits. It is off by default, which is why teams end up with reviews that describe code from three pushes ago.

Two other levels exist and interact. An organisation policy overrides everything, so if an admin has turned it off nobody can opt in. And there is a personal toggle in your own Copilot settings that applies to pull requests you open, which the org policy also overrides.

Tuning It So It Stops Repeating Itself

Out of the box Copilot reviews against a generic idea of good code. A .github/copilot-instructions.md file changes that.

# Review instructions

- This is an ASP.NET Core API. Model binding validates inputs at the
  framework level, so do not flag interpolated strings in parameterised
  query builders.
- Prefer flagging missing null checks on public method parameters over
  naming preferences.
- Do not comment on formatting. Prettier handles it.

Keep it short. Three to five bullets beat a long document, because long instructions get squeezed out of the context budget and stop mattering.

The highest-value thing you can write in that file is what your framework already guarantees. That is the biggest single source of comments you will otherwise resolve every week for the rest of the project.

For larger codebases, per-path files under .github/instructions/ with an applyTo glob in the front matter let you give frontend and backend different guidance. They stack on the project-wide file.

The Billing Thing Nobody Mentions Until the Invoice

Copilot moved to usage-based billing in June 2026. Premium request units were replaced by GitHub AI Credits, metered on tokens, and code review carries a published multiplier of 13 against the requests meter.

Separately, because code review now runs on Actions, reviews on private repositories consume Actions minutes at the normal rate. Public repositories are exempt.

Which means if you enable automatic reviews on a repository where Dependabot opens forty pull requests a week, you are now spending from the same Actions pool your CI uses. Worth checking your spending limits before rolling it out broadly rather than after.

Now the Honest Part

Four things Copilot code review does not do, and each one is why teams end up adding something alongside it.

It cannot approve. Its output is comments, never an approval event. A branch protection rule requiring one approving review is not satisfied by it, and it cannot satisfy a CODEOWNERS requirement either. A critical issue sitting in a Copilot comment merges exactly as easily as no comment at all, unless a person reads it and acts.

It is not a security scanner. It reasons about the change. It does not perform taint analysis, secret detection, dependency scanning, or infrastructure-as-code checks. GitHub has those as Advanced Security, a separately licensed product Copilot neither replaces nor surfaces. If you adopted Copilot thinking AI review covered security, that gap is invisible until it is not.

It is scoped to the diff. It reads the change and nearby context. It is not indexing your repository to trace how a changed function is called three services away, and no amount of instruction tuning fixes that.

It does not track anything. No finding state, no ownership, no resolution timestamp. A comment is a comment. If you need to prove findings were resolved within a window, that is a different category of tool entirely.

The Same Feature Is Different on Azure DevOps

Worth knowing if your organisation runs both, which plenty do after an acquisition.

Copilot code review on Azure DevOps is a separate implementation with the same name. It is in public preview with staged regional rollout, and it carries hard caps: 10 GB repository, 100 changed files, the pull request must be active with no merge conflicts. Enabling it takes three levels, organisation then project then repository, and the automatic-review setting lives under branch policies rather than anywhere you would look first.

It also cannot satisfy a required reviewer or block a merge, same as on GitHub. So on the platform whose main strength is policy enforcement, the native AI reviewer sits entirely outside the policy layer.

GitLab's Duo and Bitbucket's Rovo Dev have the same two properties. Different vendors, different licensing, and none of them does dedicated security analysis or changes what can merge.

What I Actually Do Now

Copilot runs on every pull request through a ruleset, with a short instructions file telling it what our framework already handles. It gives every change a baseline read within a minute, which on a distributed team is genuinely better than waiting three hours for someone to open the tab.

And separately, a tool that posts a status check rather than a comment handles the part a comment cannot: security scanning that runs in the same pass, findings checked for whether they are actually reachable, and a gate that holds the merge when something critical shows up. That is what CodeAnt AI does, across GitHub, GitLab, Bitbucket and Azure DevOps, including self-hosted.

The distinction I would offer anyone setting this up: a fast reviewer and a control are two different things, and Copilot is emphatically the first one. Work out which you were trying to buy.

Originally published at codeant.ai, where there is a fuller version including troubleshooting and the platform-by-platform comparison.

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.

Dissecting FOIS: The Log4j2 Filter That Only Does Half Its Job

Amartya Jha — Tue, 01 Sep 2026 06:56:17 +0000

__Log4j2's FilteredObjectInputStream checks which classes can be rebuilt, but not how large or deep the data can be. Here's how that gap enables an RCE and two gadget-free crashes on a serialized log receiver.

TL;DR

Log4j2's FilteredObjectInputStream (FOIS) checks the class names in a serialized stream and nothing else. It never limits object size or depth.
That one gap gives three problems on a single network log receiver: an unauthenticated RCE, a crash that pins a CPU core, and a 44-byte out-of-memory crash. Two of them need no exploit gadget.
The RCE (Log4j2 #4255) is prior work. CodeAnt's contribution is dissecting the two crashes, the contrast with logback, and the lab numbers.
Exposure is narrow. You need a serialized log receiver on the network, which is not a Log4j default. High severity, low prevalence.
Fix: send logs as text, or add the size and depth caps logback already ships.

At a Glance

A security filter is meant to do one job completely. FOIS does about half of one. It reads the name of every class arriving over the network and rejects anything not on an approved list.

That is a real check, but it is the only check. FOIS never asks how large an object is or how deeply nested, and it never turns on the size and depth limits Java already ships. Those two missing checks turn one log receiver into three problems.

The RCE below (Log4j2 #4255) is not our discovery; it is prior work, credited in full at the end.

What our team adds is the breakdown of the filter itself: the two crashes hiding in the limits FOIS forgot to set, the comparison with the library that got it right, and numbers from a real lab.

Read the full CodeAnt security research →

Lab: Log4j 2.26.1 on JDK 17. Run it yourself with one Docker command.

What FOIS Was Built To Do

Log4j can ship log events between machines as Java objects, and the receiver rebuilds them from raw bytes. Rebuilding attacker-controlled bytes is the flaw behind a decade of Java RCE, so Apache wrapped that step in FOIS in Log4j 2.8.2 (the fix for CVE-2017-5645). FOIS keeps the class names it trusts and throws out the rest.

Two details of that trusted list matter. It allows a class called java.rmi.MarshalledObject, and it trusts whole Java packages by prefix, so everything under java.util and java.lang is waved through. Each one becomes a way in.

The One Mistake

FOIS checks which class is being rebuilt. It never checks how big or how deep. Java can cap array size, nesting depth, and reference count; FOIS turns none of that on. Everything below follows from that.

The Three Impacts

RCE — a java.rmi.MarshalledObject-wrapped gadget hits the FilteredObjectInputStream receiver; the receiver logs msg=null while whoami returns root, unauthenticated code execution as root.

DoS — the same receiver, no gadget: a 5.7 KB nested HashSet pins readObject at 100% CPU permanently, and a 44-byte Object array triggers OutOfMemoryError: Requested array size exceeds VM limit.

One: remote code execution, smuggled inside an allowed class. MarshalledObject is trusted, but it is a container: it carries a second batch of bytes inside itself, and when Log4j opens it, those inner bytes are rebuilt on a fresh stream that FOIS is not watching.

The outer check passes; the real payload rides in behind it. Log4j opens the container on its own during reconstruction, so if the server has a usable gadget library on its classpath, this is unauthenticated RCE.

In the lab against real Log4j 2.26.1 on JDK 17, a wrapped payload ran whoami and returned root, the server stayed up and logged a blank message, and the same payload sent without the container was correctly rejected. (On a modern JDK fewer gadgets survive, but the ones that run commands still work where the right library is present, so the requirement is just a usable gadget on the classpath.)

Two: a CPU bomb the size of a text message. HashSet is allowed, and rebuilding a set recomputes the hash of everything inside it.

A 2015 trick called SerialDOS (Wouter Coekaerts) builds a small nested structure where each layer is shared and referenced twice, so a shape a few dozen levels deep is reachable by an exponential number of paths, and the runtime walks every one. With no depth limit, the receiver runs it to completion:

A few kilobytes freezes the machine, one worker per packet, and it is silent: while the receiver spins there is no log line. The only sign is a thread stuck at 100% CPU.

Three: a 44-byte packet that crashes the process. A serialized array states its length before any data, and the runtime reserves that space immediately. With no size limit, that number can be anything.

A 44-byte packet can claim an array of billions of entries, and the process dies with an out-of-memory error before it even tries to allocate. No gadget, no library, just a lie about size.

The full research walks through the FOIS implementation, reproduces all three impact paths, and includes the lab setup and measurements.

Read the complete analysis →

How logback Solved the Same Problem

logback, Spring Boot's default logger, had the identical socket receiver, and its guard shows what the finished job looks like. HardenedObjectInputStream does everything FOIS does, then the part FOIS skipped: an exact-name allowlist instead of trusting whole packages, a maximum array size and nesting depth (which kills both crashes), and a closed proxy path.

It is immune to all three. The difference between the two libraries is essentially one extra line of filter, the one that turns on the size and depth caps, which FOIS never wrote.

How Exposed Is This, Really?

Less than three impacts suggests, and this is the honest part. Every one needs a serialized log receiver exposed on the network, which is not how Log4j runs by default; Apache removed the built-in socket server years ago. When one researcher tested 53 product builds in default configuration, none were exploitable.

Call it high severity, low prevalence: trivial to hit where a receiver exists, uncommon to have one. Where they do appear, it tends to be logback's own socket receiver, an older Elastic Logstash log4j input, or legacy Log4j 1.x, which has no filter at all.

How To Fix It

If you cannot remove a serialized receiver right away, one runtime setting closes the gaps. It denies the gadget package and adds the size and depth caps at once. The catch: only one such filter applies per process and a later setting silently replaces an earlier one, so every rule lives in a single string.

-Djdk.serialFilter='!org.apache.commons.collections.**;maxarray=10000;maxdepth=16'

That is a stopgap. The durable fix is to stop sending Java objects across a trust boundary: carry log events as JSON or plain text, or remove the serialized receiver. Log4j 3.x already dropped this pattern; the 2.x line still in production keeps it.

Are You Affected?

Only if you run a serialized log receiver reachable on the network, which is a deliberate setup, not a default. Look for a process listening on a log-ingest port (historically 4560) that rebuilds log events off the socket.

If you find one, treat it as high severity, apply the filter above, then move that transport to text or retire it. On Log4j 3.x the pattern is already gone.

Original research: U-Sec / Wujie Security, first credited with the MarshalledObject allowlist bypass behind #4255. The original report was later deleted.
Independent PoCs: joanbono's log4j2-4255-exploit and dinosn's log4j-4255.
CPU-crash technique: Wouter Coekaerts, "SerialDOS," 2015.
Prior writeup: Jeff McJunkin's post, whose 53-product test and detection guidance inform the exposure and fix sections.

Credit: Prior Work

The RCE (issue #4255), the property that any gadget works once the inner stream is unchecked, and the gadgets themselves are prior work. Our contribution is the breakdown of the filter around that RCE, the two crashes from its missing limits, the logback comparison, and the lab numbers.

The Takeaway

A class-name allowlist is not a deserialization boundary. Restricting which objects can be rebuilt may reduce the risk of code execution, but without limits on payload size, object depth, or resource consumption, the same endpoint can remain vulnerable to denial of service.

The bigger lesson is simple: a security control is only as strong as the attack surface it actually closes. An endpoint can look hardened against one exploit path while still being wide open to another.

If your application relies on deserialization, APIs, or other security-sensitive boundaries, automated checks alone may not expose these gaps. That is where adversarial testing matters.

Want to know what your application exposes before an attacker does?

CodeAnt AI helps teams identify security weaknesses across their codebase and infrastructure. For deeper coverage, CodeAnt's pentesting services put those controls to the test from an attacker's perspective, helping uncover exploitable paths that static analysis and automated scanners can miss.

If you want to see the kind of security research behind that approach, read the full Log4j2 FOIS analysis.

Find the weakness before someone else does.

References

Apache Log4j2 issue #4255
logback HardenedObjectInputStream
ysoserial · log4j2-4255-lab · Jeff McJunkin
CVEs: CVE-2017-5645, CVE-2017-5929, CVE-2019-17571, CVE-2023-6378

This breakdown is part of an ongoing effort by CodeAnt AI Security Research to analyse the trust boundaries in widely deployed infrastructure. The lab ran in isolated local Docker containers with synthetic payloads. The underlying issue and the gadgets are prior work, credited above.

Have a receiver like this, or want a deserialization boundary reviewed? Reach us at securityresearch@codeant.ai