Local Linux Scans#

This document explains how to configure and use FutureVuls for scanning Linux operating systems.

How OS Package Scanning Works#

Updates for Linux packages are provided through a process called backporting. FutureVuls performs detection using Security Trackers and OVAL data provided by Linux distributors. These vulnerability databases contain the specific version numbers that have actually been backported for each OS, enabling accurate detection.

For detailed detection logic of each scan method, please refer to the open-source code.

We are sometimes asked whether vulnerabilities can be accurately detected by registering CPEs for the OS and its packages. Our answer is that using CPE scans for OS packages is not recommended due to a high number of false positives. For details, please see Registering CPEs for OS Packages.

How to Scan and Check Results on Linux#

The scanner runs automatically once a day. If you want to run a scan at any time, follow the "How to Scan" instructions below.

How to Scan#

Run /opt/vuls-saas/vuls-saas.sh with vuls-saas user privileges as follows.

When running as the vuls-saas user with sudo

root@scan01:~# sudo -H -u vuls-saas /opt/vuls-saas/vuls-saas.sh >/dev/null 2>&1

When switching to the vuls-saas user to run

root@scan01:~# su - vuls-saas
vuls-saas@scan01:~$ /opt/vuls-saas/vuls-saas.sh

How to Check Scan Results#

After the scan is complete, the results will be reflected on the web interface shortly. If the results do not appear after a few minutes or if the scan fails, check the following log files to determine the cause.

/opt/vuls-saas/scan.log
- Indicates whether the scan succeeded or failed.
- If the scan fails, the report information will not be uploaded to FutureVuls.
/opt/vuls-saas/report.log
- Contains the scan result report and any errors related to uploading to FutureVuls.
- If the upload fails, it may be due to a proxy or other network issue.

Scan Configuration Location#

The scan settings are described in /opt/vuls-saas/config.toml as shown below.

$ cat /opt/vuls-saas/config.toml

version = "v2"

[saas]
  GroupID = 0000
  Token = "xxxx-xxxxxxxx-xxxx-xxxxxx-xxxxxxxxx"
  URL = "https://xxxxxxxxxxxx"

[default]

[servers]

  [servers.server1]
    user = "vuls-saas"
    host = "localhost"
    port = "22"
    scanMode = ["fast-root"]
    [servers.server1.uuids]
      server1 = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"

Registering CPEs for OS Packages#

It is possible to register CPEs for the OS itself and for packages installed via the OS package manager.

However, this is not recommended because it causes false positives for the following reasons.

CPE scans do not access the actual machine, so they are unaware of version updates, leading to false positives.
The NVD used for CPE scans does not support backporting, resulting in false positives.

Each case is explained in detail below.

False Positives Occur Because CPE Scans Do Not Access the Live System and Are Unaware of Updates#

When you register a CPE for an OS, all vulnerabilities associated with that OS version in the NVD are detected. OS packages are continuously updated through daily operations, but CPE scans do not access the actual machine and therefore do not know when a package has been updated. As a result, vulnerabilities that have already been resolved by software updates will continue to be detected in FutureVuls.

Here is a specific example (the versions are hypothetical):

RHEL 7 was released with Apache 2.0.0-a included.
Later, CVE-2021-0001 was disclosed for Apache 2.0.0-a and registered in the NVD.
At this point, running a CPE scan on RHEL 7 detects CVE-2021-0001.
You then update Apache to 2.0.0-b.
The CPE scan, which doesn't access the live system, is unaware of the update to 2.0.0-b, so it continues to detect CVE-2021-0001.

In practice, these false positives make CPE scanning for OS packages unusable.

False Positives Occur Because the NVD Used for CPE Scans Does Not Support Backporting#

Furthermore, CPE scans for "software managed by a package manager" will also produce false positives. Major Linux distributions like RHEL, Ubuntu, and Debian provide updates via backporting (see Red Hat's Backporting Policy).

To detect vulnerabilities in software managed by a package manager, you must use a vulnerability database that supports backporting.

The vulnerability database used for CPE scans is the NVD. The NVD lists only the upstream software versions affected by a given CVE, not backported versions.

For this reason, even if you convert the versions of all packages obtained with commands like rpm -qa into CPEs and perform a CPE scan, you will get false positives.

The following uses the example of CVE-2021-3450 on RHEL to explain this in detail.

The pages above state the following:

According to the NVD, CVE-2021-3450 affects the upstream versions 1.1.1h - 1.1.1k.
According to RHEL, CVE-2021-3450 was fixed in the RHEL backport with openssl-1.1.1g-15.

In other words, the same CVE ID is registered with different fixed versions depending on the information source. For packages managed by the RHEL package manager, the RHEL version information is correct. Using the NVD version for detection will result in false positives.

Thus, even if you register and CPE scan all packages individually, false positives will still occur. For the OS and software managed by its package manager, detection via the scanner (using OVAL) is accurate, unlike CPE scanning.

However, for "software you downloaded as a tar.gz file and built yourself," you are using upstream source code directly, so CPE scanning can detect vulnerabilities accurately.