Differences between Scanner Types

We can distinguish vulnerability scanners into network based and device based: Network based scanners access assets based on IPs/IP-ranges and enumerate/check services exposed to the network the scanners act in. This can be further categorized into Internet based external scanners (i.e., checking all services accessible through the Internet) and internal scanners operating on a local network of an organization (results often include more services that are otherwise not exposed to the Internet).

Device-based scanners on the other hand execute code on the configured assets to enumerate installed/configured services and programs.

In all cases, collected data is then correlated with public databases of known CVEs to produce a list of issues.

Limitations of Network Based Scanners

Network based scanners often return inaccurate versions and incomplete results. This is due to software often being configured to not leak informational data such as versions to external systems and some services not always “answering” to external probes.

Thus, network scanners are limited to the (often incomplete) version information or inaccurate measurements of “typical” replies of certain software versions, as well as services which allow external systems to initiate connections.

Some vulnerabilities such as CVE-2023-38408 or CVE-2025-26465 (OpenSSH Client) cannot be (reliably) detected this way, since these vulnerabilities require the vulnerable system to initiate the connection to a malicious server. Similarly, so-called “Backports” result in external scanners assuming a certain service to be vulnerable due to its old version while the fix for said vulnerability was applied, without increasing the version number.

Device-Local/-Based Scanners

This limitation is inherent to all external scanners. One way to obtain more reliable data would be to use a scanner that runs on the servers themselves and thus can collect accurate version & configuration information of all programs installed thereon.

This approach however leads to other limitations. On the one hand, the version detection of the software used is significantly more accurate (almost 100%) and assigned CVEs are therefore less likely to be false positives. At the same time, such a scanner (ideally) detects all installed software regardless of whether the assigned service is accessible from outside or is even used. Thus we are less assessing the external attack surface rather than generally aiming to keep installed software up to date and security-in-depth. This means less work checking these findings for false positives, but often more work w.r.t. prioritization.

Example: vuls.io

One such tool (free & open-source) is https://vuls.io/. Vuls offers several modes:

  1. Local Scan Mode: Usually used as a one-off scan, ran manually on all assets and producing results as JSON. These are then evaluated on a client.
  2. Remote Scan Mode: This is initiated from a client that has SSH access to the servers and instructs them to start a scan, feeding the data directly back to said client. Of course, this only works with the appropriate access to the servers.
  3. Server Mode: In this mode, the evaluation of scan results happens on a passive server which receives the data from all assets. The assets need to be configured with an external mechanism (e.g., cron) to regularly start the scans locally and send the results to the evaluation server via its HTTP API.