Penetration testing (a pentest) is an authorized, simulated attack against your application, API, network or cloud environment. A tester uses the same tools and techniques as a real attacker to find vulnerabilities, prove which ones are exploitable, and show what an attacker could actually do with them. The deliverable is a report that ranks each finding by risk and explains how to fix it.
The key word is authorized. A pentest has a written scope, dates and rules of engagement. Without that, the exact same activity is an attack.
Pentest vs vulnerability scan vs red team
| Activity | What it does | Output |
|---|---|---|
| Vulnerability scan | Automated check for known issues and misconfigurations | A long list of potential issues, some false positives |
| Penetration test | Finds issues, validates exploitability, chains them | Prioritized, proven findings with impact and fixes |
| Red team | Goal-based campaign that also tests detection and response | Whether the blue team noticed and how far attackers got |
| Bug bounty | Ongoing crowd of researchers paid per valid finding | Individual reports, uneven coverage |
A vulnerability scanner tells you a door might be unlocked. A pentest walks through it and tells you which rooms it leads to.
Why companies do penetration testing
- Find exploitable issues before attackers do. Scanners miss logic bugs like broken access control, IDOR or a checkout that accepts negative quantities. Humans (and good AI) find them.
- Compliance. PCI DSS requires penetration testing at least annually and after significant changes. SOC 2 and ISO 27001 audits do not always mandate one, but auditors and enterprise customers routinely ask for a recent pentest report.
- Sales. Security questionnaires from larger customers often ask for your latest pentest date and a summary of results.
- Before a big change. Launching a new product, a new API, a payment flow or a migration to a new cloud setup.
Types of penetration testing
By how much the tester knows
- Black box: the tester starts with only a URL or IP range, like an external attacker. Realistic, but a lot of the budget goes into discovery, and deep code paths stay untouched.
- Grey box: the tester gets user accounts for each role and some documentation (API specs, architecture). This is the most common setup for web apps and APIs because it balances realism and coverage.
- White box: the tester also gets the source code, infrastructure-as-code and configs. It finds the most issues per hour because nothing has to be guessed, including bugs that are hard to reach from the outside.
By target
- Web application: authentication, sessions, access control, injection (see SQL injection), XSS, business logic. Usually mapped to the OWASP Top 10 2025 and the OWASP Web Security Testing Guide.
- API: object- and function-level authorization, mass assignment, rate limits, token handling. APIs return data directly, so a missing authorization check there usually means a data leak.
- Network: external (internet-facing hosts and services) and internal (what an attacker can reach after getting a foothold, such as Active Directory).
- Mobile: the app binary, local storage, certificate pinning and the backend APIs it talks to.
- Cloud: IAM policies, public storage, exposed metadata services, Kubernetes and infrastructure-as-code misconfigurations.
- Social engineering: phishing and pretexting against people, usually a separate engagement.
The phases of a penetration test
- Scoping and rules of engagement. What is in scope, what is out, testing windows, production vs staging, emergency contacts, and written authorization.
- Reconnaissance. Mapping the attack surface: subdomains, endpoints, technologies, exposed files, public repos, leaked credentials.
- Scanning and enumeration. Automated and manual discovery of services, parameters, roles and candidate vulnerabilities.
- Exploitation. Proving the vulnerability is real: reading another user's data, escalating privileges, bypassing auth. Done carefully to avoid damaging data or availability.
- Post-exploitation. What can an attacker do from there? Pivot to other systems, access secrets, persist. This is what turns a medium finding into a critical one.
- Reporting. Findings with severity, evidence, reproduction steps and remediation.
- Retest. After you fix, the tester confirms each issue is actually closed.
Established methodologies include PTES, NIST SP 800-115 and the OWASP Web Security Testing Guide. A good provider will tell you which one they follow.
How much does a pentest cost, and how long does it take?
Prices vary a lot, so treat these as orientation, not quotes. Public 2026 pricing guides published by several pentest vendors commonly cite roughly USD 5,000 to 30,000 for a web application pentest, with large network, cloud or red team engagements going above USD 100,000. Most manual pentests are priced as tester-days times a day rate, so scope drives cost: number of roles, endpoints, integrations and environments.
On timing, published vendor guides put most tests at 5 to 15 working days of active testing, with small apps faster and complex SaaS platforms longer. End-to-end, from first contact to final report, several weeks is normal, and the most common delay is not the testing itself but getting access and environments ready.
Manual vs automated vs AI pentesting
| Manual pentest | Automated pentest | AI pentest | |
|---|---|---|---|
| Strength | Creativity, business logic, complex chains | Speed, repeatability, known patterns | Reads code and context, reasons about exploitability at scale |
| Weakness | Expensive, point-in-time, limited hours | Shallow, noisy, misses logic bugs | Still needs human judgment for high-stakes scope and sign-off |
| Cadence | Once or twice a year | Every deploy | Every commit, pull request or on a schedule |
The problem with the classic model is timing. A manual pentest is a snapshot: the week after the report, your team ships new code that nobody has tested. That is why many teams now combine an annual manual test with continuous testing, usually sold as penetration testing as a service (PTaaS). PTaaS platforms mix automated penetration testing with on-demand human or AI analysis and deliver findings in a dashboard instead of a PDF.
White-box AI pentesting of source code
The newest approach is to point an AI model at the source code itself. Instead of probing a running app from outside, it reads routes, controllers, queries, auth checks and infrastructure files, then reasons like a white-box tester: where does user input go, which endpoints skip the authorization check, which secret was committed three years ago. It goes beyond classic pattern-matching SAST because it can judge whether a flaw is actually reachable and exploitable. (For how static and dynamic testing differ, see SAST vs DAST.)
This is what an AI pentest in Nurbak does: you connect GitHub and scan a repo, and Nurbak's own self-hosted AI model analyzes the code, so the analysis does not send your code to OpenAI or Anthropic. It reports exploitable vulnerabilities with file and line, checks dependencies against known CVEs, flags GitHub Actions, Docker, Terraform and Kubernetes misconfigurations, finds secrets in git history, and gives the repo a 0 to 100 security score with plain-language explanations. With your explicit consent, it can open a Pull Request with the fix and a security regression test. White-box AI testing does not replace a human pentest for a PCI audit, but it closes the gap between them.
How often should you pentest?
- At least annually for any system that handles customer data, and whenever compliance requires it.
- After significant changes: new auth system, new public API, payments, major infrastructure changes.
- Continuously if you deploy weekly or daily. Automated and AI testing on every pull request is part of a mature DevSecOps practice.
What a good pentest report includes
- Executive summary in plain language: overall risk, most critical issues, what to fix first.
- Scope and methodology: exactly what was tested, dates, accounts used, what was out of scope.
- Findings each with severity (CVSS or a clear scale), affected asset, evidence (requests, screenshots), step-by-step reproduction, business impact and specific remediation.
- Attack chains: how low-severity issues combine into a serious one.
- Positive findings: what held up, so you know which controls work.
- Retest results confirming fixes.
Red flags: a report that is mostly scanner output pasted into a template, findings with no proof of exploitation, or no remediation beyond "sanitize input".
How to prepare for a pentest (and get your money's worth)
- Write the scope first. List domains, APIs, mobile apps and cloud accounts, plus what is explicitly out of scope. Vague scope is the main reason quotes vary so much.
- Give testers real accounts. One user per role (admin, regular user, a user in another tenant). Most serious findings are authorization bugs between roles and tenants, and testers cannot find them with a single account.
- Prefer staging that mirrors production. Same code, same config, realistic data. Test production only with clear rules about destructive actions.
- Fix the easy stuff before the test. Outdated dependencies with known CVEs, secrets in the repo and obvious misconfigurations are cheap to find yourself. Paying a senior tester to report them wastes hours that should go to logic flaws.
- Plan the remediation window. Book engineering time for fixes and schedule the retest. A report nobody acts on is just an expensive PDF.
Getting started
If you have never had a pentest, start with your most exposed asset (usually the main web app and its API), decide between grey box and white box, and write down the scope before you talk to vendors. If you want a quick, code-level baseline first, run an AI pentest on your repository: the free scan shows the 3 most important findings in full, and paid plans start at USD 79 per month.