BetaWe're currently in beta. Signing in will place you on our waitlist.

Black Box vs White Box

Two Approaches to Pentesting

TurboPentest offers two testing modes that differ in how much information the pentest has about your application. The choice between them affects which tools run, what vulnerabilities can be found, and how deep the analysis goes.

Black-box testing examines your application from the outside, simulating an external attacker with no access to source code. White-box testing adds static code analysis by connecting your GitHub repository, giving the pentest access to your source code in addition to the external attack surface.

The naming comes from traditional pentesting terminology. A "black box" is opaque — the tester cannot see inside. A "white box" is transparent — the tester can see the internal code and architecture.

Black-Box Testing

Black-box pentesting tests your application exactly as an attacker would encounter it: from the outside, with no insider knowledge. TurboPentest deploys 11 tools during Phase 1 of a black-box pentest:

ToolCategoryWhat It Tests
NmapNetworkOpen ports, services, version detection
OWASP ZAPWeb appXSS, injection, CSRF, misconfigurations
NucleiWeb appKnown CVEs, misconfigurations, exposures
NiktoWeb appDangerous files, outdated server software
FFUFWeb appHidden directories, backup files
OpenVASVulnerabilityFull network vulnerability assessment
TestSSLSSL/TLSCertificate issues, weak ciphers, protocol vulnerabilities
SubfinderReconSubdomain enumeration
HTTPXReconHTTP response probing, technology detection
Wafw00fReconWAF detection and fingerprinting
PentestToolsMultiAdditional vulnerability checks

After Phase 1 reconnaissance, P4L4D1N's AI agents analyze the results and conduct deeper testing with exploit validation.

When to use black box: You do not have a GitHub repository, your source code is in a different version control system, or you specifically want to assess only the external attack surface — what an attacker without insider access could find.

White-Box Testing

White-box testing includes everything in black-box testing plus three additional tools that analyze your source code:

ToolCategoryWhat It Tests
SemgrepSASTCode-level vulnerabilities, insecure patterns
TrivySCAVulnerable dependencies in package manifests
GitleaksSecretsHardcoded API keys, tokens, passwords in code

This brings the total to 14 Phase 1 tools. The code analysis findings are also fed into P4L4D1N's AI agents, which can cross-reference external vulnerabilities with code-level issues for deeper insights.

Connecting GitHub for White-Box Testing

To enable white-box testing, you connect your GitHub repository through OAuth or the GitHub App integration. When creating a pentest, you provide the repository URL alongside the target URL:

curl -X POST https://turbopentest.com/api/pentests \
  -H "X-API-Key: $TURBOPENTEST_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "targetUrl": "https://app.example.com",
    "repoUrl": "https://github.com/org/repo"
  }'

TurboPentest clones the repository at the start of the pentest and runs static analysis tools against the current state of the default branch. Repository access is read-only — TurboPentest never modifies your code.

Benefits of White-Box Analysis

White-box testing finds vulnerability categories that are invisible from the outside:

Hardcoded secrets — Gitleaks scans your entire Git history for API keys, database passwords, JWT signing keys, and other secrets that were committed to code. Even if a secret was committed and then deleted, it exists in Git history and can be recovered by an attacker who gains repository access.

Vulnerable dependencies — Trivy checks your package manifests (package.json, requirements.txt, Cargo.toml, etc.) against vulnerability databases. A dependency with a known CVE might not manifest as an externally exploitable vulnerability today, but it is a ticking time bomb that could be triggered by a configuration change or input pattern.

Insecure code patterns — Semgrep identifies code-level vulnerabilities like SQL injection sinks, insecure deserialization, hardcoded credentials, missing input validation, and unsafe cryptographic usage. These findings tell your developers exactly which lines of code need attention.

Cross-reference insights — When P4L4D1N's agents have both external findings and code analysis results, they can correlate them. For example, if ZAP detects a potential injection point externally and Semgrep confirms that the corresponding code path does not sanitize input, the finding confidence level increases significantly.

When to Choose Each Mode

Choose black box when:

  • You do not have a GitHub repository
  • Your source code is not on GitHub (GitLab, Bitbucket, self-hosted)
  • You want to specifically assess the external attack surface only
  • You want a faster pentest (fewer tools means shorter Phase 1)

Choose white box when:

  • You have a GitHub repository and can grant read access
  • You want the most comprehensive coverage possible
  • You need to satisfy compliance requirements that mandate code-level security analysis
  • You want P4L4D1N's agents to cross-reference external findings with source code

For most organizations with GitHub repositories, white-box testing is the recommended default. The additional code analysis tools add minimal time to the pentest but significantly expand the types of vulnerabilities that can be discovered.

On this page