A white box penetration test (or white box pentest) gives auditors access to internal information upfront, rather than requiring them to discover it progressively.
This type of pentest is done by providing or integrating with source code, documentation, product specifications, observability and telemetry systems, cloud providers, security tooling and more.
Why would you give away this information?
To find as many exploitable vulnerabilities as possible, before attackers do. This matters more every year: attackers are becoming more efficient as they use AI, which makes even the hardest and most obscure vulnerabilities much more likely to be exploited today, than they were a couple years ago. This asymmetric access to information is key to staying ahead of attackers.
As attack timelines compress, the key element for defenders to protect their system is to leverage information about their internal systems.
How does it differ from a regular pentest?
A white box pentest replaces guessing with actual data.
Regular pentests, also known as black box pentests, require auditors to infer how a system works through reconnaissance, experimentation, as well as trial and error. A white box pentest gives them direct access to most of that information instead.
Objective coverage measurement
With the right data, a white box pentest can exhaustively describe the attack surface. This makes it possible to measure what fraction of that attack surface was actually tested, and ensures no undesired blind spots are left. For example, if the source code defines 240 HTTP endpoints and the test exercised 228 of them, you know exactly which 12 were missed and can decide whether that’s acceptable. A black box test can’t give you that number: it only knows what it found.
Discover more exploitable vulnerabilities
In a black box pentest, when an attacker tries to exploit a potential vulnerability, they need to guess how the system works. The most experienced and skilled pentesters rely on instinct and experience to guess faster. But sometimes, guessing is too hard, or luck isn’t on their side, and the exploitation fails. Or maybe the vulnerability wasn’t exploitable in the first place. Maybe.
In a white box pentest, guessing is replaced by data. Here are a few examples:
Explore more of the attack surface
The attack surface is everything your organization exposes to the world and that attackers can target: applications, endpoints, infrastructure, identities, and more.
In a black box pentest, the attack surface is the scope initially provided by the customer. As the pentest moves forward, the attacker discovers additional domains and endpoints through reconnaissance.
But reconnaissance is usually incomplete. Old endpoints may no longer be used by the application while remaining accessible. Domains that have disappeared from search engines might still point to vulnerable applications. Newly created domains might not be indexed yet, while newly released HTTP endpoints may lie ahead of the application deployment, making them hard to spot. For instance, a pentest that began with www.acme.com led the attacker to discover www.staging.acme.com. The more they discover, the more they can target, and the more likely they are to succeed.
Attackers often use tools and techniques such as DNS brute force and subdomain enumeration to guess existing domain names (e.g., using a dictionary of entries such as admin, staging, www2, auth).
In a white box pentest, the reconnaissance gets a head start. Access to the DNS configuration of the organization replaces slow and error prone dictionary discovery by a direct enumeration, such as querying AWS Route53. Similarly, dormant (legacy) HTTP endpoints that would otherwise have to be guessed can be discovered directly from the application’s source code, or by looking at observability data, such as application logs or traces.
Provide actionable remediation
When a vulnerability is discovered in a black box test, the report includes recommendations such as “sanitize user input”, together with the URL of the affected endpoint.
Remediation then requires identifying the responsible team, locating the vulnerable code, understanding the surrounding context, implementing a fix, evaluating its impact, and finally asking the pentesting team to verify it.
In a white box pentest, access to the source code enables mapping a vulnerability to its precise location. Several options are then possible for remediation, depending on the team’s workflow:
- Create a Linear/JIRA ticket with precise source code information
- Create a pull request with a suggested fix.
Trigger tests on security-significant changes
A black box pentest is usually run “from time to time”, say once or twice a year.
A white box pentest can be automatically scheduled when a significant change is detected in the code, in staging, or in production. For instance, let’s say a new AWS load balancer was added in staging: you can explore it right away. Or perhaps, a significant portion of the authentication code was just rewritten, or a new endpoint was added to a service? A white box pentest lets you target exactly the part of the application that changed.
Is it realistic?
One could think that a white box pentest is too thorough, using information that an external attacker would never have.
But attackers now use AI agents that guess faster, and increasingly better. Context that used to take weeks of reconnaissance to piece together is now within reach. And with that context, they succeed more.
In the past, white box pentests relied heavily on manual handoffs: meetings, whiteboard sessions, back-and-forth questions and shared documentation with testers. Today, integrations with code repositories, cloud providers, and observability tools make that context available automatically, and keep it up to date.
A penetration test looks at a system the way an attacker would. Attackers usually start with little context, so the job begins with reconnaissance, and it never really ends: every discovery leads to the next.
Conclusion
None of this is new. I could have written this post 20 years ago, and the idea would be the same. But then, white box pentests used to be slower and more expensive than black box ones, so most teams settled for black box. AI has dramatically narrowed that gap, at the same time, it’s making attackers faster at guessing what they can’t see.
If you want to improve your security posture, not just get a SOC 2 report, a white box pentest gives you:
- More real vulnerabilities found, including the hard-to-reach ones attackers increasingly go after
- Fixes your engineers can act on right away, pointing to the exact code or infrastructure instead of a generic “sanitize user input”
- A clear view of what was tested, and of what wasn’t
A white box pentest might take more setup up front, but once connected, it tests every significant change as it ships, not once a year.
