Vulnerability scan or penetration test?
Autor: Natalia Vyvial ·
They are not two levels of the same thing, with the more expensive one replacing the cheaper one. A scan compares systems against databases of known vulnerabilities and goes for breadth. A penetration test probes a specific application the way an attacker would, and also looks for flaws in your own logic.
How do the two differ?
In what they look for. A scan compares your systems, devices, applications and services against databases of known vulnerabilities, so it looks for what someone has already described. A penetration test, by contrast, is manual and automated work on a specific application that tries out what can be done with it, and it also finds flaws that are in no database because they only came into being in your own logic.
This leads to the second difference: a scan goes for breadth and is repeated, a test goes for depth and is carried out for a specific purpose. So they are not two levels of the same thing, with the more expensive one replacing the cheaper one. They answer two different questions.
What does a scan find, and what does it miss?
It finds unpatched systems, known flaws in components, and services exposed to the outside world that often nobody in the company knows about. Findings are given a CVSS (opens in a new window) score and a priority, so fixes are made according to severity rather than according to whatever happens to be to hand. The database of known vulnerabilities is CVE (opens in a new window), a typical tool is Greenbone Vulnerability Manager, and for the outside view there is Shodan, which shows what is visible from the internet.
What it misses is everything that is not a flaw in a component but a flaw in your application. That another customer’s order is displayed once a number in the address is changed, that a payment can be confirmed twice, or that an administrator function can be called directly without anyone checking the user’s role. A scanner does not see these things, because from its point of view the application is responding correctly.
What does a tester do that a scanner cannot?
They probe the application the way an attacker would, following a methodology so that nothing is overlooked: OWASP Top 10 (opens in a new window) and the OWASP Testing Guide for web applications, MASVS (opens in a new window) for mobile ones. Testing covers authentication, authorisation, input validation, application logic and data protection, including attacks such as SQL injection, XSS, CSRF, IDOR, SSRF and RCE.
The output is not a list of ports but a report that categorises the findings by risk. And because a fix may only appear to remove a vulnerability, it is followed by a retest. That is something a scan does not have to deal with: you simply run it again.
| Vulnerability scan | Penetration test | |
|---|---|---|
| What it looks for | Known vulnerabilities listed in databases (CVE) | Flaws in a specific application, including logic flaws |
| How it works | Automated, for breadth | Manual and automated, in depth |
| How often | Repeatedly: production environments monthly, external scans can be automated weekly | Targeted: after a significant change, for a new application or before rollout |
| Output | Findings with a CVSS score and a priority | A report with risk categorisation and recommendations, optional retest |
| What it cannot tell you | Whether the application can be exploited in a way nobody has described | What the environment will look like a month from now |
How often is each one done?
A scan makes sense as a regular routine, not a one-off: for production environments it is recommended monthly, external scans can be automated weekly, and ad hoc scans are run after larger changes. The reason is simple: a vulnerability can appear in your system without you doing anything. It is enough for someone to discover it in a component you use.
A penetration test, on the other hand, is tied to an event. A new application, a major change, a new integration, or a system that has started handling money or personal data. Testing the same thing every month makes no sense if nothing has changed.
What should you check in the brief for a test?
The scope, because it determines both the price and what can be found at all. A test of one public application says nothing about the internal network, and a test without login credentials says nothing about what a logged-in user can do with other people’s data. Both are legitimate briefs; they just must not be mistaken for a statement about the security of the company as a whole.
The second thing is what the report should contain: besides the findings and their severity, also the steps by which the tester reached them. Without these, developers fix the description rather than the flaw, and nobody verifies that the fix worked. That is why a retest is done after the fixes, and why it makes sense to agree on it before the test starts.
Where should you start?
With a scan, for two reasons. It is cheaper, so it can be started straight away, and above all it tells you how big the problem actually is: how many systems the company runs, how many of them nobody updates, and what is visible from the internet. Only on that basis can you decide which application deserves a test, because nobody pays to test everything.
Both are also good input for the risk management that the Czech Cyber Security Act requires of companies providing regulated services; whether it applies to you, and under which regime, is covered in a separate article. Scanning and testing are provided by Securent, which sits in the Cyber security category alongside ICT services.
Related products
- Cyber security
ICT services
We look after your infrastructure, networks and end devices so that your company runs reliably. You get ICT services and support in one place.
- Cyber security
Securent
Keep your company under control. Securent protects your data, processes and systems and trains your staff, because most attacks start with an ordinary mistake.
