What a penetration test is, and what it is not
Most of what is sold as penetration testing is a vulnerability scan with a report template on top, and the difference is not a matter of degree. A scanner matches installed software versions against vulnerability databases. A penetration test is a human attempting to reach something they should not be able to reach, using whatever combination of weaknesses gets them there. You can buy either. Confusing them means paying test prices for scan output, and assuming coverage you do not have.
What does a penetration test actually involve?
A tester works towards an objective rather than a checklist: reach the customer database, forge an authenticated session, move from a low privilege account to an administrative one, escape a container onto the node. Findings are the evidence produced along the way. The defining activity is chaining, where two or three individually unremarkable weaknesses combine into something that matters, and no automated tool does this because it requires understanding what your application is for.
In practice the work splits into reconnaissance, mapping the reachable surface, probing for logic and authorisation flaws that no signature exists for, exploitation, then attempting to extend access. Methodologies exist and are worth naming in a statement of work: the OWASP Web Security Testing Guide for web applications, the OWASP Mobile Application Security Testing Guide for mobile, NIST SP 800-115 for general structure, and PTES for engagement phasing. A supplier who cannot say which one they follow is improvising.
The test you can apply is to read a sample report and look for a single finding that required two steps. If every entry is a standalone issue with a CVE reference or a missing header, you are looking at scan output. If one entry reads as a narrative that starts at an unauthenticated endpoint and ends inside an internal service, a person did the work.
Why is a vulnerability scan not a penetration test?
Because a scanner can only find things that are already described in a database, and the flaws that get organisations breached usually are not. Broken access control, where changing an identifier in a request returns another customer's record, is invisible to a scanner because there is no vulnerable version to detect. The same applies to business logic abuse, insecure direct object references, password reset flows that can be replayed, and authorisation that is enforced in the interface but not in the API behind it.
Scanning is inventory matching. It reads what is installed, resolves versions and reports every known issue associated with them, which is genuinely useful and should be running continuously. It is also why scan output is long and mostly noise: the severity attached to a CVE describes the worst plausible case for any user of that component, not your configuration.
The two are complements, not competitors. Vulnerability assessment gives you breadth and repeatability at low cost. Penetration testing gives you depth and proof, and it tells you which of the scan findings are actually reachable in your environment. A programme that has one and not the other has a predictable blind spot.
Which type of assessment do you actually need?
It depends on whether you need coverage, proof, or an assessment of your detection capability. These are different products with different prices, and buying the wrong one is the most common procurement error in this area.
| Activity | What it finds | What it misses | Best use |
|---|---|---|---|
| Unauthenticated network scan | Exposed services, outdated versions, weak TLS | Anything behind a login, all logic flaws | Continuous baseline of external surface |
| Authenticated vulnerability scan | Missing patches on hosts you supply credentials for | Whether a finding is exploitable in context | Patch programme measurement |
| Container image scan | Known CVEs in packages inside the image | Runtime configuration, escape paths, secrets in use | Build pipeline gate on fixable findings |
| Web application penetration test | Access control, logic, session and injection flaws | Issues only reachable from inside the network | Anything holding customer data |
| Internal network or Kubernetes test | Privilege escalation and lateral movement paths | External exposure you did not put in scope | Proving blast radius after a foothold |
| Red team exercise | Whether your detection and response works | Comprehensive vulnerability coverage | Mature teams with a functioning SOC |
Do container and cloud scanners change the picture?
They change the breadth available to you and not the depth. A container image scanner tells you which packages in an image carry known vulnerabilities, and a cloud posture tool tells you which resources are misconfigured against a benchmark. Both are automated inventory checks, run them, and neither will tell you that a service account token mounted in a pod can reach the cluster API and create a privileged workload.
That escape path is the thing a container focused penetration test looks for. The realistic chain in a Kubernetes estate goes from an application flaw to code execution in a container, then to an over-permissioned service account or an exposed instance metadata endpoint, then to cloud credentials, then to data. Every link is a configuration decision rather than a CVE, so the scanner scores clean while the path remains open.
The practical division of labour is to gate the build on scanner findings that have fixes available, keep a runtime view of what is actually running, and use human testing to establish what an attacker could do after landing in one of those containers. Teams that only run image scanning tend to have a very large finding count and no idea of their blast radius.
Is a continuous testing platform a penetration test?
Usually not, though some are honest about it. Attack surface management and automated breach simulation products run known exploit paths continuously and are valuable for exactly that: catching regressions, new exposures and configuration drift between human tests. They operate from a library of techniques, which means they find what the library contains.
The distinction to hold onto is that automation is excellent at recurrence and poor at novelty. Your authorisation model is unique to your application, so no library covers it. If a platform is sold as replacing an annual test, ask which of your last test's findings it would have discovered, and ask specifically about the ones involving your own business rules.
Some assessors do not accept automated output where a scheme requires testing by a qualified individual, so if the test exists partly to satisfy an auditor, confirm what form of evidence they will take before you buy the subscription.
When do you not need a penetration test?
When you already know the answer and have not acted on it. If your last report is unremediated, if you have no asset inventory, if administrative access is not behind multi-factor authentication, or if you have never patched on a schedule, a test will produce a long document confirming what you could have deduced for far less money. Fix the known items first and test afterwards, when the results will tell you something you did not already know.
You also do not need one for a system with no sensitive data, no privileged network position and no route to anything that matters. A marketing microsite on isolated hosting is a low value target, and the honest advice is to spend that budget on the application handling payments.
The reverse also holds. If you handle cardholder data, health records, or hold administrative access to customer environments, a scan alone is not a defensible position regardless of how clean it looks, because the categories of flaw most likely to expose that data are the categories a scanner cannot see.
Common questions
- What is the difference between VAPT and a penetration test?
- VAPT stands for vulnerability assessment and penetration testing, and the term bundles two different activities. Vulnerability assessment is automated inventory matching that reports known issues in installed software, giving breadth cheaply and repeatably. Penetration testing is manual work towards an objective, chaining weaknesses to prove what an attacker could reach. A supplier selling VAPT may be delivering either, so ask which portion of the effort is human.
- Can a vulnerability scanner find broken access control?
- No, and this matters because broken access control is among the most commonly exploited weakness categories in web applications. A scanner detects vulnerable software versions and known signatures. Whether changing an identifier in a request returns another customer's record depends on your own authorisation logic, which no database describes. Finding it requires a human who understands what the application is meant to allow and then tests whether it enforces that.
- Is automated penetration testing good enough?
- It is good for recurrence and poor at novelty. Automated platforms run a library of known techniques continuously, which catches new exposures, configuration drift and regressions between human tests. They cannot evaluate authorisation rules or business logic specific to your application, because those are not in any library. Some auditors also decline automated output where a scheme expects testing performed by a qualified individual, so confirm what evidence is acceptable first.
- Does container image scanning cover container security?
- Only the package layer. Image scanning reports known CVEs in software inside the image and says nothing about runtime configuration, over-permissioned service accounts, exposed instance metadata endpoints or paths from a container to the node and then to cloud credentials. Those are the links in a realistic container attack chain, and each is a configuration decision rather than a known vulnerability, so a clean scan and an open escape path coexist comfortably.
- How do I tell whether a report came from a scanner?
- Look for a finding that required more than one step. Scanner output is a list of standalone issues, each with a CVE reference or a missing configuration, and each independent of the others. Manual testing produces at least one narrative finding that begins somewhere unauthenticated and ends somewhere it should not, describing the chain used. If no finding in the sample report has that shape, the engagement was largely automated.
- Should you scan or test first?
- Scan first, then fix what the scan finds, then test. A penetration test run against an environment with unpatched hosts and no multi-factor authentication on administrative access spends its budget documenting things you already knew. Clearing the automated findings first means the human effort goes towards the flaws that only a human can find, which is what you are actually paying the premium for.
