The argument is economic. A real adversary is not bound by your statement of work. Denying the testers the source narrows what they reach in the time you paid for, not what an attacker reaches in the time they are willing to spend.
What a source code assisted pentest is
An authorized security assessment in which the testing team holds read access to the application source while testing a running instance of it. NIST SP 800-115 frames testing along a spectrum of tester knowledge — no prior information through to full knowledge — and treats the choice as scoping, not rigour.[1]
The code is an input, not the deliverable. A finding qualifies only once the tester has reached the vulnerable behaviour on the running system and can reproduce it. The code explains why it happens and which other call paths share the defect; the running instance establishes that it happens.
How it compares to black box and grey box testing
| Model | Tester holds | Answers | Weakest at |
|---|---|---|---|
| Black box | Only what is publicly reachable | What can an unaided outsider find within the engagement window | Deep authorization and logic flaws behind authenticated, multi-step flows |
| Grey box | Credentials, some documentation | What can an authenticated user or a compromised account reach | Defects in rarely exercised code paths and in dependency usage |
| Source code assisted | Credentials plus read access to source and infrastructure code | Does the weakness exist, and everywhere it exists | Estimating how discoverable an issue is to an external attacker |
| Secure code review | Source, often without a running instance | Which patterns in the code are dangerous | Proving exploitability and filtering unreachable findings |
These are complements. The mature pattern is a source code assisted test as the recurring engagement, plus an occasional black box exercise scoped to measure external discoverability and detection response — a different question, answered by a different exercise.
What the source access actually buys you
The gain concentrates in weakness classes that stay invisible from outside until precisely the right request is made. MITRE's CWE Top 25 is a useful frame for which those are.[5]
Broken object and function level authorization
The code shows which handlers check ownership and which inherit a check a second route never calls. From outside they look identical.
Business-logic and state-machine flaws
Discount stacking, replayed idempotency keys, over-refunds, skippable approvals: missing transitions in code, nothing in the traffic.
Multi-tenant isolation
Tenant scoping in an ORM base class, bypassed by one raw query. A single-line defect with total impact.
Cryptographic misuse
Fixed IVs, unauthenticated ciphertext, a signature check computed but never read. All healthy on the wire.
Secrets in history
A credential removed from the tree but still in an earlier commit reaches anyone who obtains the repository.
Dependency reachability
Whether a flagged CVE sits on a path you call: urgent fix or backlog item.
Exposed services and transport security
Already visible from outside.
Default credentials and unpatched edge infrastructure
A black box test finds these faster.
What to provide, and what to withhold
Under-provisioning access is the most common way these engagements underdeliver: the tester spends the first third of the window waiting on the environment, and the rest covers less ground than a black box test would have.
Read-only repository access
Manifests, lockfiles, infrastructure-as-code, CI config, and full history. History is where committed secrets live.
A running instance that matches production
Debug mode, disabled authorization, or a different database engine produces findings that do not transfer.
Test accounts at every privilege level
At least two in separate tenants. Cross-tenant authorization cannot be tested with one account.
The intended authorization model, in writing
Without it, testers cannot separate a design from a defect, and you receive both as findings.
A named contact and an agreed stop condition
Rules of engagement, escalation path, and the definition of unacceptable impact, settled before testing starts.[1]
Production data
Does not improve the test. Only enlarges the cost of a mistake.
Live production secrets
Same trade, same answer.
How the engagement should run
Map the attack surface from the code
Routes, consumers, scheduled jobs, admin entry points — a longer list than the product team keeps
Locate the trust boundaries
Where input enters, authorization is decided, privilege changes hands
Form ranked hypotheses
“This endpoint should reject a document ID from another tenant”
Test against the running instance
Each hypothesis, in order of impact
Generalize every confirmed finding
Every other call site with the same defect
Retest after remediation
The proof, then the adjacent call sites — partial fixes are the norm
OWASP's Code Review Guide organizes the boundary-mapping work well[3]; the Web Security Testing Guide covers technique for the exploitation half.[2]
How to judge the report you receive
PCI DSS guidance is explicit that a report documents methodology, scope, findings, and supporting evidence — not conclusions alone.[4] A code-assisted engagement earns four more tests.
| Check | What a good report shows | Warning sign |
|---|---|---|
| Proof, not pattern | A request and response, or a state change, that another engineer can reproduce | “The code appears to permit…” with no attempt recorded |
| File and line attribution | Each finding cites the exact location and commit that introduced the behaviour | Findings that could have been written without the repository |
| Completeness sweep | Every affected call site listed, not only the one that was exploited | One instance reported and closed, then the same bug recurs elsewhere |
| Negative results | Named controls that were tested and held, so you know what the coverage was | Only positives, leaving scope coverage entirely unstated |
Common pitfalls
- Accepting static output as findings. A scanner report with a vendor logo on it is not a penetration test. Unreachable code paths generate confident, expensive noise.
- Testing an environment that is not production-like. Configuration, feature flags, and data volume all change which findings are real.
- Reporting severity without reachability. A critical weakness in a path no request can reach outranks nothing. Severity is a function of what the finding can touch.
- Letting the evidence go stale. The test is accurate for the commit it ran against. Without retesting on change, its accuracy decays at the speed of your merge queue.
- Confusing the question. Source-assisted results say whether a defect exists, not how likely an outsider is to stumble on it. Do not use one to answer the other.
Frequently asked questions
What is a source code assisted pentest?
A source code assisted penetration test is an authorized security test in which the testers are given read access to the application source code alongside a running instance of the application. Testers use the code to find and understand candidate weaknesses, then attempt to exploit them against the running system so that every reported finding is backed by observed behaviour rather than by reading alone.
What is the difference between a source code assisted pentest and a code review?
A secure code review reads the code and reports weaknesses it can identify statically; it usually stops at the point of saying a pattern looks dangerous. A source code assisted pentest uses the code as a map and then requires exploitation against a running instance, so the deliverable is a reproducible proof rather than a list of suspicious patterns. Many programs run both, because the code review finds issues in paths that are hard to reach at runtime.
Is a source code assisted pentest the same as white box testing?
They overlap but are not identical. White box testing describes the level of information the tester holds, which can include source code, architecture documents, infrastructure configuration, and credentials. Source code assisted testing specifically names source access as the addition. In practice most engagements sold as white box are source code assisted plus credentialed access, and most engagements sold as grey box are credentialed but not source assisted.
Does giving testers source code make the test less realistic?
It changes what the test measures, and that is usually the point. A black box test measures what an unaided outsider can find within a fixed time budget. A source code assisted test measures whether a weakness exists at all, which is the more useful question when the alternative attacker has months, a leaked repository, or an insider. It should not be used to claim that an external attacker could trivially find the same issue.
What access should we give a source code assisted pentester?
Provide read-only access to the application repository including dependency manifests and infrastructure-as-code, a running non-production instance that matches production configuration, test accounts at every privilege level including at least two accounts in separate tenants, documentation of the intended authorization model, and a named contact for scope questions. Withhold production data and production secrets.
Does a SOC 2 or PCI DSS audit accept a source code assisted pentest?
Generally yes, and assessors often view the additional access favourably because it increases coverage. Neither SOC 2 nor PCI DSS mandates the black box format. What they care about is defined scope, tester independence and competence, a documented methodology, evidence of findings, remediation, and retesting. Confirm the specific expectation with your assessor before scoping, because the requirement is set by the audit programme rather than by the testing method.
How much more does a source code assisted pentest find?
There is no credible universal multiplier, and any vendor quoting one should be asked for their methodology. The categories that reliably improve are broken authorization, business-logic flaws, insecure use of cryptography, injection reachable only through unusual call paths, and secrets committed to history. Categories that improve least are those already visible from outside, such as exposed services, missing transport security, and default credentials.
Primary sources
- NIST. SP 800-115: Technical Guide to Information Security Testing and Assessment
- OWASP. Web Security Testing Guide
- OWASP. Code Review Guide
- PCI Security Standards Council. Information Supplement: Penetration Testing Guidance
- MITRE. CWE Top 25 Most Dangerous Software Weaknesses