A vulnerability scanner will happily tell you that your web server is running an outdated TLS library. It will not tell you that any logged-in user can read any other customer's invoice by changing a number in the URL. The first is a known defect in someone else's code. The second is a flaw in your application's logic — and no signature database contains it, because it exists only in your product.
That gap is the whole argument. Buyers routinely ask for "a VAPT" and are sold an automated scan, or ask for "a scan" when what their enterprise customer actually demanded was a manual penetration test. The two produce different documents, cost different amounts, and answer different questions. Getting the purchase wrong means either paying consultant rates for something a tool does better, or handing a compliance reviewer a scanner PDF when they wanted evidence that a human tried to break in.
What the terms actually mean
Vulnerability assessment is the systematic identification and enumeration of known weaknesses across a defined estate — hosts, services, containers, cloud configuration, dependencies. It is broad, repeatable, and largely automated. Its output is a prioritised inventory.
Penetration testing is a goal-directed attempt to compromise a target using the techniques an attacker would use, including chaining several individually minor issues into one serious outcome. It is deep, human-led, and narrower in scope by necessity. Its output is a narrative of what an attacker could achieve and how.
VAPT is the umbrella term for buying both together — the assessment establishes the surface, the penetration test proves what an adversary does with it. In practice the term is used loosely enough that you must always confirm what is inside the scope of work rather than trusting the acronym. The most common commercial disappointment we see is a "VAPT" engagement that was, on inspection, an authenticated scan with the findings retyped into a template.
What a scanner is genuinely good at
Scanners get an unfair reputation because people judge them on the things they were never designed to do. On their own ground they outperform any human:
- Breadth. A scanner will check ten thousand hosts as cheerfully as ten. No human tester enumerates an entire cloud estate by hand, and none should.
- Known CVEs and outdated components. Version detection against a continuously updated vulnerability database is exactly the sort of tedious, memory-intensive matching that machines win at. Most real-world compromises begin with something already public and already patched elsewhere.
- Configuration drift. Comparing live infrastructure against a baseline — CIS Benchmarks, a hardening standard, your own golden image — and flagging what has drifted since last month.
- Continuity. A scan runs nightly. A penetration test happens once or twice a year. Between tests, the scanner is the only thing watching, and most of your risk arrives during that interval as new code, new hosts, and newly disclosed CVEs.
- Regression. Once you have fixed something, automation is what stops it coming back.
If your estate has never been systematically scanned, that is almost certainly the higher-value first purchase. Paying a senior tester to discover that you have an unpatched service exposed to the internet is an expensive way to learn something a tool would have told you in an afternoon.
What a scanner structurally cannot do
The limitation is not maturity of tooling — it is a category problem. A scanner compares observations against a database of things known to be wrong. It has no model of what your application is for, so anything whose wrongness depends on intent is invisible to it.
That excludes, permanently:
- Business logic flaws. Applying a discount twice. Advancing an order to "shipped" without payment. Cancelling someone else's booking. Each individual request is well-formed and returns a normal response. There is nothing to signature-match.
- Access control between roles. Whether a support agent should see salary data is a question about your business, not your HTTP stack.
- Chained exploitation. An information leak rated informational, plus a weak password reset, plus a permissive CORS policy, can be a full account takeover. Scanners score findings individually; attackers do not.
- Anything requiring a real workflow. Multi-step flows behind authentication — onboarding, checkout, approvals — are where the money is, and where automated crawlers most reliably get lost or log themselves out.
The worked example: broken object-level authorisation
This is the canonical case, and it is worth walking through precisely because it shows why the tool cannot help rather than merely asserting that it cannot.
Your application exposes an endpoint for invoices. A logged-in user requests their own:
GET /api/v2/invoices/10041 HTTP/1.1
Host: app.example.com
Authorization: Bearer eyJhbGciOi...
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 10041, "account": 552, "total": 4200.00, "status": "paid" }
Correct. Now the tester changes one digit:
GET /api/v2/invoices/10042 HTTP/1.1
Host: app.example.com
Authorization: Bearer eyJhbGciOi...
HTTP/1.1 200 OK
Content-Type: application/json
{ "id": 10042, "account": 861, "total": 18750.00, "status": "unpaid" }
Invoice 10042 belongs to account 861. The requester is account 552. The server authenticated the token — it verified who you are — and then never asked whether that identity was entitled to this object. The vulnerable code usually looks as innocent as this:
@app.get("/api/v2/invoices/<invoice_id>")
@require_auth # confirms the token is valid
def get_invoice(invoice_id):
invoice = db.invoices.find_one({"id": invoice_id})
return jsonify(invoice) # never checks invoice.account == user.account
Now consider what the scanner saw. It sent a request. It received 200 OK with
well-formed JSON and no error, no stack trace, no SQL fragment, no timing
anomaly. By every signal available to it, the application behaved correctly —
because syntactically it did. The only way to know this response is a breach is
to know that account 552 should not be able to see account 861's data, which
requires understanding the ownership model of the application. That knowledge
lives in your product, not in a CVE feed.
OWASP ranks this class — Broken Object Level Authorization — at the top of the API Security Top 10, and in our testing it remains the single most common serious finding in modern applications. It is also cheap to exploit at scale: once a tester confirms one instance, iterating through an ID range extracts the whole table.
The comparison, honestly
| | Automated scanning | Manual penetration testing | | ----------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Finds | Known CVEs, missing patches, weak TLS, misconfiguration, exposed services | Logic flaws, authorisation gaps, chained attacks, abuse of intended features | | Coverage | Very broad — whole estate | Deliberately narrow — agreed scope | | Cadence | Continuous or nightly | Point-in-time, typically annual or per major release | | False positives | Common; needs triage | Rare; each finding is validated and usually reproduced | | Cost model | Licence or subscription | Day rate × tester days | | Evidence value | Shows hygiene and coverage | Shows adversarial assurance; what auditors and enterprise buyers ask for | | Regression checking | Excellent | Only via retest |
The row that decides most purchases is the last-but-one. If a customer's procurement team, a cyber insurer, or an ISO 27001 auditor has asked for evidence, they generally want a report describing what a skilled human attempted and what happened — with methodology, scope, findings, exploitation evidence, and remediation advice. A scanner export does not answer that question, however long it is.
When to buy which
Buy scanning first if you have never had systematic coverage, your estate has grown faster than your inventory, you are patching reactively, or you cannot currently answer "are any of our internet-facing services running something known-vulnerable?" in under an hour.
Buy a penetration test first if the application handles money, personal data, or multi-tenant separation; you have distinct user roles and permissions; a customer or auditor has explicitly asked for a report; or you are about to ship something whose failure would be existential. Anything where users can see each other's data if you get it wrong deserves human eyes.
Buy both, on different cadences, once the programme matures — which is what a real VAPT arrangement is. The pattern that works:
- Continuous automated scanning of infrastructure and dependencies, with findings routed into normal engineering triage rather than an emailed PDF.
- Manual application penetration testing at a fixed cadence, plus ad hoc before any significant change to authentication, authorisation, payments, or tenancy boundaries.
- A retest after remediation, so fixes are proven rather than asserted.
One warning about scope: a penetration test priced by the day is bounded by the days you buy. Ten user roles, three integrations, and a mobile client cannot be meaningfully covered in the same window as a single-role web app. If a proposal quotes a fixed low price without asking how many roles exist, how many authenticated flows there are, and whether the environment is production or staging, you are being sold a scan.
Where this lands
Most organisations we speak to need less than they fear on the automated side — that part is largely a tooling and process decision — and more than they expect on the manual side, because the authorisation and logic issues that matter most sit exactly where automation is blind. If you are trying to work out whether your next spend should be continuous scanning coverage or a scoped penetration test against a specific application, that is the kind of scoping conversation we have all the time, and it usually takes one call rather than a proposal.