Pentest vs vulnerability scan, explained for founders

If you have ever asked "should we get a security scan or a pentest?" and received two confident, opposite answers, you have met the industry's favourite confusion. The two words describe genuinely different things. Vendors blur them because each side wants to sell you theirs. Here is the difference, without a sales pitch attached.

A vulnerability scan looks for what is known

A vulnerability scanner is a program that checks your systems against a catalogue. It looks at the versions of software you run, the ports that answer, the configuration it can see, and it compares all of that to a list of things known to be wrong: this version of this library has a published flaw, this header is missing, this service should not be public.

Its strengths are real. It is fast, it is cheap, it runs on a schedule, and it is thorough about the things on its list. If you have never run one, the first run will find something, and the something will be worth fixing.

Its limits are just as real, and they are structural rather than a matter of quality:

• It only knows what is on the list. A flaw in your own code, in how you check who owns what, in a workflow that can be skipped, is not on any list. Scanners do not find business logic problems because there is no signature for them.
• It reports possibility, not proof. "Version X has a known vulnerability" does not mean the vulnerability is reachable in your setup. A scanner cannot tell, so it reports it anyway. That is where the long lists come from.
• It does not chain. A real intrusion is rarely one flaw. It is a low-severity information leak that reveals a hostname, which has a weak login, which gives access to a token, which opens the database. A scanner sees four low-severity items and rates each one low.

A pentest tries to get in

A penetration test is an attempt to break into your product the way an attacker would, by someone (or increasingly something) that reasons about what it sees. It uses scanners as a starting point, then does the part scanners cannot: it reads your API and asks what happens if a request is sent out of order, it tries to be one user while acting on another user's data, it follows the small leak to the bigger door.

The output is different in kind. Not "this might be vulnerable" but "we did this, and got that". A finding from a pentest comes with a reproduction: here is the request, here is the response, here is what it means. When it says critical, it is because someone got somewhere critical.

The classic limits of the pentest are about how it is delivered, not what it is. Done by a firm, it is scoped, scheduled, and expensive, with public prices in Europe running from a few thousand euros for a small web app to several tens of thousands for a broad scope. It reflects the product as it was during the test window, and the report ages from the day it lands.

Why the distinction matters more for a small team

A company with a security team can afford the scanner's long list, because someone is paid to go through it and decide what matters. A team of four cannot. For them, a scan output is a to-do list of two hundred items with no owner, and the honest outcome is that it gets ignored after the first week. The problem is not the tool; it is that the tool's output assumes a reader who does not exist.

What a small team needs is the opposite shape: few findings, each one proven, each one with the fix. That is what a pentest produces. The reason small teams historically did not get one is cost and cadence, not relevance.

What changed

The thing that has shifted in the last two years is that the reasoning part of a pentest, the part that reads an API and tries the thing the scanner would never think of, can now run continuously and at a cost closer to a scanner than to a consulting engagement. The industry calls this continuous pentesting, and every vendor in the space is converging on the same promise: pentest-grade findings, scanner-grade cadence.

Which means the old question, scan or pentest, is becoming the wrong question. The useful questions for a small team are:

1. Does it try to get in, or only match versions? If the answer is only versions, it is a scanner, whatever the marketing says.
2. Is every finding reproduced before it reaches me? If not, you will be the one deciding what is real, and you do not have time.
3. Does it run when I ship, or when I remember? A test on a date is a snapshot. A test on change is coverage.
4. Can I act on a finding without a security background? Read one sample finding. If it needs a translator, it is not for you.

Orja is built around those four answers: it tests from the outside the way an attacker would, verifies every finding, runs on every merge, and writes the fix in plain language. If you want to see what that looks like on your own product rather than in a definition, put in your domain. The first report is free.