Vulnerability scanning in 2026: from CVE and CVSS 4.0 to EPSS and CISA KEV

Scanning, pentesting and auditing: three different questions

These three services are often confused, although they answer different questions and their costs differ by orders of magnitude. Vulnerability scanning answers the question of what in the environment is a known weak point. An engine does the work: it identifies software versions and configurations and matches them against a vulnerability database. It is cheap and fast, so it can run weekly or daily, but it sees only what somebody has already described, and by its nature it produces false positives.

A penetration test answers the question of what can be done with those weaknesses. It finds things a scanner will never see: business logic flaws, abuse of functions working exactly as designed, and chains in which several minor weaknesses together produce a serious outcome. It costs many times more and is therefore performed once or a few times a year (see the article on penetration testing). An audit in turn answers a question about process and compliance - whether policies exist, whether they are applied and whether that can be proven (see the article on IT security audits).

None of the three replaces the others. A scanner running daily will not tell you that permissions in an application can be bypassed; a pentest performed in March says nothing about a vulnerability published in September. Entities covered by the Polish national cybersecurity system act ^[17] or by DORA ^[6] need all three in practice, on different cycles.

How the scanning process is built

A mature process has four phases repeated on a cycle, and the scanning phase is not the hardest of them.

It starts with inventory. The scanner first has to establish what is on the network at all, and the coverage rate matters more here than the quality of the engine: a vulnerability on a device nobody knows about will not be found no matter how good the scanner is. The typical gap is assets started up without the IT department's knowledge - virtual machines in the cloud, equipment brought in by a supplier, test systems that moved into production without their status changing.

The second phase is vulnerability detection: the scanner identifies versions and configurations and matches them against a database ^[1]. Web applications call for separate tools which, instead of identifying versions, send the application requests that model the typical attack classes catalogued by OWASP ^[7].

The third phase, validation, is the one most often skipped - and it is why vulnerability management programmes lose credibility. Scanners report weaknesses that a given system does not have, for instance when a Linux distribution backported a fix without changing the version number visible from outside. If nobody filters those out, the teams responsible for the systems stop taking the reports seriously. The fourth phase is prioritisation and handover for remediation, described later in this article.

The scanning mode is a separate decision. Authenticated scanning, run from an account on the target system, sees actual package versions, configuration and policies, so it produces far fewer false positives; it does, however, require credential management, which creates a risk of its own. Unauthenticated scanning shows what an outside attacker sees - less accurate, but it reproduces the real starting point. Sensible practice is to use both: the first inside the network, the second from the internet.

CVSS 4.0: what changed

CVSS is a scale from 0 to 10 describing the severity of a vulnerability in isolation from any particular environment. Version 4.0 ^[2], published by FIRST in June 2023, introduced three changes of practical significance relative to version 3.1.

The first is splitting the former scope metric into two separate impact groups - for the vulnerable system and for the systems the vulnerability reaches beyond it. The version 3.1 construction was widely applied inconsistently, because one value had to describe two different things; separating them makes assessment easier and better captures situations where a weakness in one component opens the way to the rest of the environment.

The second is a distinct threat metric group, in which the maturity of exploit code matters most. The score therefore stops being purely theoretical - if a working tool is publicly available, the assessment is meant to reflect that. It is a step in the same direction as EPSS and KEV, though based on qualitative judgement rather than a statistical model.

The third is a group of supplemental metrics which do not affect the numeric score but convey information relevant to decisions: among others the impact on human safety, how automatable the attack is, and the effort required to remediate. That last group is particularly useful in industrial environments, where the consequence of a failure can be physical danger rather than data loss.

The practical conclusion is a cautious one: scores from the two versions should not be compared directly, because they come from different models. And CVSS in any version remains a measure of severity, not of risk - risk is settled only by where the vulnerability sits and whether anybody is trying to exploit it.

EPSS and KEV: from severity to probability

The basic problem with prioritising on CVSS alone is that there are hundreds of thousands of publicly described vulnerabilities, and only a small fraction are ever used in attacks. A team patching by severity alone spends most of its time on weaknesses nobody will ever reach for, and has none left for the handful that are being used actively.

The answer to that is EPSS ^[3] - a model that publishes, daily and for each vulnerability, an estimate of the probability that it will be exploited within the next 30 days. The score runs from zero to one and, unlike CVSS, changes over time as new observations arrive. It is a statistical forecast, though, not a statement of fact: a high score does not mean an attack will happen, and a low one does not guarantee it will not.

The complement is the KEV catalogue ^[4], in which CISA records vulnerabilities confirmed as exploited in real attacks - on 24 August 2026 it held 1,675 entries. For US federal bodies an entry triggers a duty to remediate within a set deadline; outside that circle the catalogue creates no obligation, but it is the best publicly available list of what attackers are actually doing. It has a limitation worth remembering: it covers cases confirmed by a US agency, so campaigns observed only in Europe may never appear in it. It is worth supplementing with regional sources ^{[12] [13]}.

Combining the three signals gives a policy that can be written in a few sentences. Highest priority, with a deadline measured in days, goes to vulnerabilities in the KEV catalogue - regardless of their CVSS score, because they are being used now. The next level covers weaknesses of very high severity or with a high EPSS estimate, especially on internet-facing systems. The rest goes into the ordinary review cycle. Deadlines in each of those groups should follow from an organisational decision recorded in policy, rather than being set ad hoc for each finding; the method for building such a process is described in NIST SP 800-40 Rev. 4 ^[15].

Data on initial breach vectors shows that ordering is the right one. In DBIR 2024 ^[8] exploitation of a vulnerability accounted for 14 per cent of breaches, a 180 per cent year-on-year rise. In DBIR 2026 ^[18] it was 31 per cent, and for the first time in the report's history the vector overtook credential abuse. Vulnerability management has stopped being a background task.

The most common mistakes

The commonest mistake is scanning once a year, ahead of an audit. New vulnerabilities are published daily and, since their exploitation is now the most frequent initial breach vector ^[18], a report from eleven months ago describes a different environment from the one actually running. An annual scan documents that a duty was discharged, but it does not reduce risk.

The second is unassigned responsibility. In a larger environment a scanner produces tens of thousands of observations, and without tying each to a specific team, deadline and status the list stays a list. The practical remedy is to integrate the scanner with the ticketing system, so that a high-priority item becomes a task with an owner rather than a row in a report.

The third is the absence of an exception procedure. Some fixes cannot be deployed within a reasonable time - no maintenance window, application dependencies, or a device whose vendor no longer supports it. If there is no formal path for approving an exception together with compensating controls and a re-assessment date, the fixes simply are not deployed and nobody records it.

The fourth is narrowing the scope to servers. Workstations, network devices, printers, cameras and edge equipment have vulnerabilities just the same, and edge devices - firewalls and VPN concentrators - are among the more frequently exploited targets today, because they are reachable from the internet and rarely updated.

The fifth, and most fundamental, is equating vulnerability with risk. The same weakness with the same score means one thing on a test machine holding no data and another on a file server holding personal data. Without asset classification, prioritisation rests solely on a number from a vulnerability database, and so omits precisely the information that is unique to the organisation.

The legal basis

Vulnerability scanning is rarely named outright in legislation, but several instruments require a result that cannot be reached without it. The most concrete in Poland is the national cybersecurity system act ^[17]. Its article 8(1)(3) requires essential and important entities to collect information on cyber threats and vulnerabilities in the information system used to provide the service, and point 5(b) and (d) require regular software updating taking the criticality of individual fixes into account, together with prompt action once a vulnerability is noticed. Separately, article 8(1)(2)(b) lists testing of the information system among the measures for its acquisition, development and maintenance, and (h) names policies and procedures for assessing the effectiveness of the measures adopted. That is the firmest basis this process has in Polish law; its source is article 21(2) of the NIS2 directive ^[5].

In the public sector an independent basis is the KRI regulation ^[11], whose § 19(2)(12) names, among the components of ICT system security, both care for software updates and reduction of the risks arising from published vulnerabilities, together with prompt action once an as yet undisclosed vulnerability is noticed. The requirement is expressed directly here, though without a stated frequency.

In the financial sector DORA ^[6], applicable since 17 January 2025, requires continuous identification of sources of ICT risk, including vulnerabilities. The GDPR ^[9] approaches the matter more generally: article 32(1)(d) requires regular testing, assessing and evaluating the effectiveness of technical and organisational measures, and the annual reports of the Polish supervisory authority ^[10] show that, when assessing breaches, it takes into account whether the controller verified the effectiveness of its safeguards at all. Beyond EU law the card industry sets its own precise requirements: PCI DSS version 4.0 provides for quarterly external scanning by an approved vendor.

Where this is heading

The first direction is risk-based prioritisation, combining a severity score, an exploitation forecast, confirmed cases of use and the context of the asset - its classification, its exposure to the internet and the kind of data it processes - into a single ranking. This is not a new technology, merely consistent use of signals already available; the difficulty is that the asset context has to come from the organisation itself.

The second is the software bill of materials, known as an SBOM. After incidents involving libraries used in thousands of products, it became clear that the question "do we use this component" has to have a fast answer. In the EU that direction is reinforced by the regulation on the cyber resilience of products with digital elements, which places duties on manufacturers, shifting part of the work from the user to the supplier.

The third is the move from periodic scanning to continuous exposure assessment, in which vulnerability scanning is one signal among many alongside attack surface mapping and simulation of attacker techniques. This is a change in how work is organised rather than a new category of tooling, and its value depends on whether the organisation can act on those signals - without that, it merely increases the number of tickets.

Questions to put to your own programme

The maturity of a vulnerability management programme can be tested with a handful of questions to which the answer should be known without preparation.

The first concerns scope: is there a reliable asset inventory, and what proportion of the environment is genuinely covered by scanning, broken down by network segment, cloud environment, industrial network and DMZ. The second concerns frequency and should distinguish authenticated scanning inside the network from external scanning, which for internet-facing assets makes sense daily.

The third concerns prioritisation: beyond the severity score, are the exploitation forecast and the catalogue of confirmed cases taken into account, and does asset classification enter the ranking. The fourth, deadlines: is there a remediation deadline for each category, and does every item have an owner. The fifth, enforcement: do observations reach the ticketing system, because without that there is no way to hold anyone to them. The sixth, exceptions: is there a formal path for approving situations where a fix cannot be deployed, together with a compensating control and a re-assessment date.

The last three questions concern the areas most often skipped. Are container images scanned before deployment rather than only once running? Is there a bill of materials for software supplied and deployed? And finally, is the programme measured - by mean time to remediate the highest-priority findings, by the number of overdue items and by the trend in both. Without that last point there is no way to tell whether the programme is improving or merely continuing.