To be able to detect vulnerabilities, agents can natively collect a list of installed applications (System inventory), sending it periodically to the manager (where it is stored in local SQLite databases, one per agent). Also, the manager builds a global vulnerability database from publicly available CVE repositories, using it later to cross-correlate this information with the agent's applications inventory data.
The global vulnerability database is created automatically, currently pulling data from the following repositories:
https://canonical.com: Used to pull CVEs for Ubuntu Linux distributions.
https://www.redhat.com: Used to pull CVEs for Red Hat and CentOS Linux distributions.
https://www.debian.org: Used to pull CVEs for Debian Linux distributions.
https://security.archlinux.org: Used to pull CVEs for Arch Linux distributions.
https://nvd.nist.gov/: Used to pull CVEs from the National Vulnerability Database.
https://feed.wazuh.com/: Used to pull the MSU and ALAS feeds with CVEs and patches for Microsoft products and Amazon Linux.
This database can be configured to be updated periodically, ensuring that the solution checks for the latest CVEs.
Once the global vulnerability database (with the CVEs) is created, the detection process looks for vulnerable packages in the inventory databases (unique per agent). Alerts are generated when a CVE (Common Vulnerabilities and Exposures) affects a package that is known to be installed on one of the monitored hosts. A package is labeled as vulnerable when its version is contained within the affected range of a CVE. The results are presented as alerts and also stored in a per-agent vulnerabilities inventory. In this way, you can check the last scan alerts or query every single agent's vulnerabilities inventory.
The Vulnerability Detector module runs scans on startup when run_on_start is enabled or every certain period of time (defined by interval). In any of these cases, the packages and the operating system already scanned will not be re-scanned. Only new installed packages will be considered for scanning, and alerts will be generated if they have vulnerabilities. There is only one case in which the packages and the operating system will be re-scanned: when the database of vulnerabilities receives new CVEs information and min_full_scan_interval expires.
We have then three different types of scans:
Baseline: This scan type will be triggered the first time after Vulnerability Detector is enabled. It performs a full scan for every single package installed as well as the operating system. As a result, the CVE inventory will have the information of the vulnerabilities detected and an alert will be generated for each vulnerability.
Full scan: In this scan type, every single package installed as well as the operating system are scanned. It runs only when the configured min_full_scan_interval expires and the CVEs database is updated with new information. As a result, any update/change in the vulnerability inventory will be alerted.
Partial scan: Only new packages are scanned. As a result, any update/change in the vulnerability inventory will be alerted.
There are a few considerations that arise from this behavior:
The min_full_scan_interval setting protects the manager performance from running too often Full scans in case of receiving many updates of vulnerabilities feeds.
- Every vulnerability in the agents' vulnerabilities inventory for both packages and operating systems may be found in three different states:
VALID: Indicates that the vulnerability is still present in the system.
PENDING: A Full scan is in progress, and the vulnerability needs to be confirmed.
OBSOLETE: Indicates that the vulnerability is no longer present in the system. This state is then used to generate the removal alerts.
Detection alerts are generated when a new vulnerability is added to the vulnerabilities inventory.
Removal alerts are generated when a vulnerability has been removed from the vulnerabilities inventory.
Check Vulnerability detector settings for more configuration details.
The following example diagram is useful to understand the steps involved in a typical vulnerability detector workflow.