Penetration testing: when to order one and what you should get

A penetration test is an assessment in which security specialists, with your agreement, try to break into your product the way an attacker would. It finds vulnerabilities automated scanners miss: access logic flaws, payment bypasses, leaks of other users' data. Order one before launching a product that handles money or personal data, after major changes and regularly — once a year.

Here is how a pentest differs from other checks, when you need one, how to prepare and what to do with the results.

How does a pentest differ from scanning and code audits?

An automated scanner quickly finds known, typical problems: outdated libraries, missing security headers, simple injections. A code audit examines the source. A pentest is an expert's manual work, looking for ways to exploit vulnerabilities and their combinations in the real running product.

Check	What it does	Strengths	Limitations
Automated scanner	Checks against a database of known issues	Fast, cheap, continuous	Does not understand business logic
Code audit	Reads the source	Finds causes, not symptoms	Does not see environment settings
Pentest	Attacks the running system by hand	Finds real attack paths	Costlier; a snapshot in time

Run scanners continuously in CI and pentests periodically. On auditing code and architecture, see software technical audit.

When does a product really need a pentest?

A pentest is needed when the cost of a breach is high: the product handles money, personal or medical data, enterprise customers or critical processes. Large customers, partners, banks and regulators often require one.

• before launching a product with payments or personal data;
• before signing with an enterprise customer who requires a report;
• after major changes: new authentication, a payment module, a public API;
• after a security incident, to find other weak spots;
• yearly for mature products.

On security for financial services, see fintech product development.

Photo: Unsplash

What kinds of pentest are there?

Pentests differ in how much information the tester receives. More information means a deeper check and lower cost per finding, but less resemblance to an outsider's attack.

1. Black box. The tester knows only the site address — like an external attacker.
2. Grey box. Test accounts with different roles are provided — the most popular option for web applications, because most serious problems involve access rights.
3. White box. Source code and architecture are available — maximum depth.

Web products usually choose grey box: it checks whether an ordinary user can reach other users' data or admin functions.

How do you prepare for a pentest?

Preparation determines how much value you get. Above all, define the scope and rules clearly and provide a production-like environment.

• define scope: which domains, APIs, mobile apps and roles are included;
• prepare a test environment with realistic data and real payments and messaging switched off;
• create test accounts for every role;
• agree on rules: what is forbidden, testing hours, an emergency stop contact;
• sign a confidentiality agreement and a testing authorisation;
• warn your hosting provider and team so attacks are not mistaken for real ones.

How do you read the report and act on it?

A good report describes each vulnerability: where it is, how to reproduce it, what an attacker could do, how critical it is and how to fix it. Fix critical and high issues first, then order a retest.

What matters in a report:

• severity on a clear scale, such as CVSS;
• reproduction steps a developer can follow;
• a realistic attack scenario, not just a technical description;
• remediation advice;
• a short executive summary.

After fixing, add the classes of issues found to your code review checklist and automated tests so they do not return. On common vulnerabilities, see OWASP Top 10 explained.

In short

• A pentest is an authorised manual break-in attempt that finds real attack paths.
• Run scanners continuously; pentests before launch, after major changes and yearly.
• Web applications usually get a grey-box test with accounts for each role.
• Prepare the scope, environment, accounts and rules.
• Fix by severity, retest and build the lessons into your processes.