Black-box vs white-box penetration testing: which to choose

Black-box testing means the tester starts with the same public information an external attacker would have — typically just a domain or an IP range. White-box testing provides full access to source code, architecture diagrams, network maps, and accounts at varying privilege levels. Grey-box sits between: limited credentials and partial documentation. The choice changes both cost and what gets discovered.

A black-box engagement closely simulates a real external attack, including the time spent on reconnaissance with tools like Amass, Subfinder, and Shodan, port scanning with Nmap and Masscan, and credential stuffing attempts using leaked password datasets. The realism is valuable for measuring detection capability and incident response. The downside is that 30 to 50 percent of the engagement burns on enumeration that an attacker has time for and a defender does not need to pay to learn.

White-box testing is more efficient per hour. With access to the codebase, the tester can run static analysis with Semgrep or CodeQL, review authentication and authorization logic by hand, and target the riskiest sinks — file uploads, deserialization, ORM string concatenation. White-box almost always finds more bugs because it skips the discovery tax. The PTES standard explicitly recommends white-box or grey-box for in-depth application testing where the goal is bug coverage rather than threat simulation.

The pragmatic answer: for compliance pentests required by ISO 27001 or PCI DSS, choose grey-box — provide a low-privileged account and architecture diagrams. For an annual external attack-surface assessment to validate detection, run black-box. For a new application before launch, run white-box and follow up with focused dynamic testing on the riskiest flows. Splitting the budget across two narrower tests usually returns more findings than one broad black-box engagement of the same total cost.