Pentest or scan? Both, but not for the same question.
The two get sold under the same name routinely, at prices that differ by a factor of ten. The difference is not tool quality: it is a difference of kind. One compares your installation against a list of flaws already known, the other hunts for the ones that exist only in your application.
What a scanner does, and does well.
A vulnerability scanner maintains a catalogue of publicly documented flaws: this version of this library, this default setting, this missing header. It walks your installation, compares what it sees against the catalogue, and reports the matches. Fast, repeatable, and close to free to keep running.
On that ground no human competes. A scanner never tires, it runs its entire list every night, and by morning it has noticed that a dependency installed last year was published against overnight. There is no argument for going without it: it is the best permanent safety net available.
Its limit is structural and has nothing to do with quality. A scanner can only find what somebody described before it. The day it turns up a flaw that is in no database, that was luck rather than method.
What manual research does.
A penetration test starts from the other end. Instead of matching your application against a catalogue, it tries to understand what the application is meant to do, then hunts for the places where that intent was not correctly translated. Which means reading your business, not only your code.
Concretely, the question stops being "is this version vulnerable?" and becomes "what happens if I send this legitimate request with somebody else's identifier?". The request is normal, the response is a success code, and no tool on earth can know that data should not have left the building.
It is also the only approach that can chain. 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 and never connects them, because the connection exists only inside your application.
Four differences that matter.
These are not two quality tiers of one service. They are two different services.
What is being hunted
Scanning hunts known, documented flaws that everyone shares. An audit hunts flaws specific to your application, present only at your place.
Confidence in the result
A scan produces alerts to triage, a good share of which do not survive verification. An audit reports only what was exploited, with reproducible proof.
Cadence
Scanning runs continuously, nightly if you want. An audit is a long stretch, triggered at a precise moment: before a launch, after a rebuild, at a customer's request.
What you can do with it
A scan report maintains hygiene. An audit report also answers a customer, an insurer or a compliance file, because it documents human research and a defined perimeter.
What no scanner will find.
These four examples are representative of what I find most often. None of them appear in a scan report, and no tool is at fault for that.
How to combine them.
The question is not which to choose, but what role to give each.
- Run the scan continuously: it closes the obvious doors and warns you the moment a dependency turns vulnerable.
- Treat its report as a maintenance queue, not as a security diagnosis.
- Trigger manual testing at the moments that matter: before a launch, after a rebuild, when a sensitive feature ships.
- Hand over your latest scan report during scoping: it saves paying for research days on what is already known.
- Use the audit to calibrate the scan: recurring false positives can be dismissed once and for all.
- Repeat an audit when the product changes in nature, not on a fixed date: an annual audit on a frozen application delivers less than one triggered by a rebuild.
Common questions.
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 comparing your installation against a database of known flaws. An audit includes human research into what is specific to you. An audit quote with no days of manual research is a formatted scan.
Can a scanner find a business logic flaw?
No, never, and that is not a quality defect but a limit of kind. To know that a user should not be able to approve their own refund, you have to know the business. That information is in no signature database because it exists only inside your company.
How many false positives should I expect from a scanner?
Many, and that is the hidden cost of the tool. A significant share of what a raw scan reports does not survive verification: misdetected version, flaw unreachable in your configuration, compensating control already in place. Triage takes time, and it takes somebody who knows how.
Is scanning still worth doing?
Very much. It is the best tool for continuous coverage: it runs every night, it never tires, and it spots a library that became vulnerable yesterday. It is an excellent permanent safety net, it just is not a pentest.
Which should I start with on a small budget?
Scanning, without hesitation, because it costs little and closes the obvious doors. But know that once those doors are shut it stops progressing: the following months will produce the same report. That is the point where manual testing starts earning its price.
Already have a scan report?
Send it over during scoping. It tells me what is already covered, so where not to spend time, and the quote reflects that. First conversation with no commitment, full confidentiality.