Pentest or vulnerability scan? Each has its job.
The two are regularly sold under the same name, at very different prices. The difference is not about how good the tool is: it is a difference in kind. One compares your setup to a list of flaws already known. The other also looks for the ones specific to your application.
At a glance
- The scanAutomated, fast, repeatable. Limited to the catalog of flaws already known.
- The auditTooled, but led by a person. It also finds what is specific to your application.
- What separates themUnderstanding your application. A scanner does not know what it is supposed to forbid.
- What we recommendThe scan continuously, the audit at the moments that matter.
A scanner has memory, not imagination.
A scanner looks for what it already knows. A flaw that comes from your own code is one it has never seen.
A vulnerability scanner keeps a catalog of publicly documented flaws: this version of that library, this default setting, that missing header. It walks through your setup, compares what it sees to its catalog, and flags the matches. It is fast, reproducible, and costs almost nothing to run.
On that ground, no person does better. A scanner never tires, runs its whole list every night, and notices the next morning that a dependency installed last year has just been the subject of a disclosure. Going without it would be absurd: it is the best permanent safety net there is.
Its limit is structural and has nothing to do with its quality: it does not understand what your application is supposed to do.
What the scanner sees
A known version gets flagged. The checkout has no signature: the scanner moves on.
What the audit finds
The order gets confirmed without going through payment. No signature database knows that rule: it exists only in your system.
The same site, two readings. Turn the card to see what the audit finds.
What hands-on research does.
A penetration test starts from the other end: instead of comparing your application to a catalog, it tries to understand what it is supposed to do.
It then looks for the places where that intent was not translated correctly. That takes reading your business, not just your code.
In practice, the question is no longer "is this version vulnerable?" but "what happens if this legitimate request goes out with someone else's identifier?". The request is normal, the response is a success code, and nothing in the response tells a tool that this data should never have come out.
It is also what makes chaining possible. Three minor defects, each rated low by a tool, can together form a path to the administrator account. A scanner lists them on three separate lines without making the link.
Three lows, one critical. The tool scores each defect on its own, the audit sees that together they lead to the account.
Four differences that matter.
These are not two quality levels of the same service. They are two different services.
| Vulnerability scanAutomated, fast, repeatable | Penetration testIn-house tools and hands-on research | |
|---|---|---|
| What it looks for | Known, documented flaws, present everywhere. | Known flaws, and also the ones specific to your application. |
| Trust in the result | Alerts to sort through, a good share of which do not survive checking. | Only what was exploited, with reproducible proof. |
| Rhythm | Runs continuously, every night if needed. | A longer piece of work, started at a precise moment: before go-live, after a redesign, when an insurer, an auditor or a customer asks. |
| What you can do with it | Keep up your hygiene. | Also answer a customer, an insurer or a compliance file, because it documents human research and a scope. |
What scanners miss.
These four examples come up often in our reports. A scan report usually misses them, and that is not the tool's fault.
- Critical
Access control
A perfectly legitimate request, with another account's identifier. The server answers with a success code, and the tool concludes all is well.
- Critical
Business logic
A sequence of actions each allowed on its own, but forbidden in that order. No signature database knows your rules.
- High
Chaining
Three minor defects that, put end to end, give administrator access. Listed separately and rated low by a tool.
- High
Custom feature
A module written specifically for you, which exists nowhere else, so in no vulnerability catalog.
How to combine them.
The right question is not which one to pick, but what role to give each.
Run the scan continuously
It closes the obvious doors and warns you as soon as a dependency becomes vulnerable.
Treat its report as maintenance
A queue of upkeep tasks, not a security diagnosis.
Trigger a test at the moments that matter
Before going live, after a redesign, when a sensitive feature arrives.
Hand over the last scan report at scoping
It saves you paying research days on what is already known.
Use the audit to calibrate the scan
Recurring false positives can be set aside once and for all.
Repeat the audit when the product changes
Not on a fixed date: a yearly audit on a frozen application brings less than one triggered by a redesign.
Two rhythms. The scan keeps watch continuously, and the audit steps in when the product changes in nature.
Is a vulnerability scan a security audit?
No, and the confusion is common because some providers sell the first under the name of the second. A scan is an automated pass that compares your setup to a database of known flaws. An audit includes human research on what is specific to you. An audit quote with no days of hands-on research is a formatted scan.
Can a scanner find a business logic flaw?
Usually not, and it is not a quality issue but a limit in kind. To know that a user should not be able to approve their own refund request, you have to know your business. That information exists in no signature database because it exists only in your system.
How many false positives should I expect from a scanner?
Many, and that is the tool's hidden cost. A good share of the alerts raised by a raw scan do not survive checking: a misdetected version, a flaw unreachable in your configuration, a compensating control already in place. Sorting them takes time, and someone who knows how.
Is the scan still useful?
Very. It is the best tool for continuous coverage: it runs every night, never tires, and spots a vulnerable library published yesterday straight away. It is an excellent permanent safety net, just not a penetration test.
Which should I start with on a tight budget?
The scan, without hesitation, because it costs little and closes the obvious doors. But once those doors are shut, it goes no further: the following reports will only flag newly published flaws. That is when a hands-on test starts to be worth its price.
Read further.
The hands-on part, its method, its deliverable and its price.
Web penetration testing
The service that matches the hands-on part: an application tested the way a real attacker would.
See the pageOur methodology
Where the tooling stops and the research begins, at every phase.
See the pageSample report
What hands-on research produces, compared with a tool export.
See the pageWhat a pentest costs
Why an audit costs more than a scan: our pricing.
See the pageAlready have a scan report?
Send it at scoping. It tells us what is already covered, so where not to spend time, and the quote reflects that. The first call commits you to nothing.