Vulnerability processing

Vulnerability processing in Fleet detects vulnerabilities (CVEs) for the software installed on your hosts.

To see what software is covered, check out the Coverage section.

Learn more about how it works for different platforms.

Coverage

Fleet detects vulnerabilities for these software types:

Linux OS vulnerabilities are kernel vulnerabilities. Currently, Ubuntu, Debian, and Amazon Linux are supported. CentOS and Fedora coming soon.

Linux kernel vulnerabilities with known variants (ie. -generic or kernel) are detected using OVAL. Custom kernels (unknown variants) are detected using NVD.

Currently, only software names with all ASCII characters are supported. Vulnerabilities won't be detected for software with names featuring non-ASCII characters, such as Cyrillic, or software that has been renamed from its default name (e.g. "Chrome 2" instead of "Google Chrome"). For some software, Fleet uses custom rules to mitigate these issues on an app-by-app basis.

For Ubuntu Linux, kernel vulnerabilities with known variants (ie. -generic) are detected using OVAL. Custom kernels (unknown variants) are detected using NVD.

If you find that Fleet is incorrectly marking software as vulnerable (false positive) or missing a vulnerability (false negative), please file a bug.

Note: When false positives are fixed, it may take two hours for the false positives to disappear after upgrading Fleet. You can speed up this cleanup by running the vulnerabilities job manually.

Sources

Fleet combines multiple sources to get accurate and up-to-date CVE information:

• National Vulnerability Database CVE feeds
• VulnCheck Enriched NVD CPE data
• Mac Office release notes Office for Mac vulnerabilities
• Microsoft MSRC Security Bulletins for Windows OS vulnerabilities
• OVAL definitions for Linux software

Note: Fleet Premium includes CVSSv3 scores from NVD CVE feeds. Primary scores are preferred to Secondary scores if both are available, and v3.1 scores of the same type are preferred to v3.0.

Advanced configuration

Fleet runs vulnerability downloading and processing via an internal scheduled cron job. This internal mechanism is useful for frictionless deployments and is well-suited for most use cases. However, it is desirable to manage vulnerability processing externally in larger deployments where there can be dozens of Fleet server replicas sitting behind a load balancer.

The reasons for this are as follows:

• Lower resource requirements across the entire Fleet server deployment (as vulnerability processing requires considerably more resources than just running the Fleet server alone)
• More control over scheduling constraints (only process during windows of low utilization, etc.)

It is possible to limit vulnerability processing to a single dedicated host, by setting disable_schedule to true, but still running one Fleet server as false, but the drawback here is still having to dedicate resources for this single host 24/7. The Fleet binary has a command that handles the same vulnerability processing, but will exit (successfully with 0) on completion. Using this sub-command, we can delegate vulnerability processing to external systems such as:

• ECS
• K8S
• GCP
• Plain old cron

To opt into this functionality, be sure to configure your Fleet server deployment with

FLEET_VULNERABILITIES_DISABLE_SCHEDULE=true

This will disable the internal scheduling mechanism for vulnerability processing (and the ability to trigger vulnerability processing via the API with fleetctl trigger --name=vulnerabilities).

Then externally run vulnerability processing with the same environment variables/configuration files passed to the server command:

fleet vuln_processing