fleet/articles/vulnerability-processing.md

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:

Type	macOS	Windows	Linux
Apps	✅	✅	✅ On Linux, apps are installed as "Packages".
Operating system (OS)	✅	✅	✅ Vulnerabilities in the Linux kernel. Learn more in Linux coverage.
Browser plugins	Chrome extensions, Firefox extensions	Chrome extensions, Firefox extensions	Chrome extensions, Firefox extensions
Packages	Python, Homebrew, npm	Python, Atom, Chocolatey, npm	Python, npm, deb, rpm, and pacman. Learn more in Linux coverage.
IDE extensions	VS Code, VS Code forks (i.e. Cursor), and JetBrains IDEs (i.e. IntelliJ IDEA)	VS Code, VS Code forks (i.e. Cursor), and JetBrains IDEs (i.e. IntelliJ IDEA)	VS Code, VS Code forks (i.e. Cursor), and JetBrains IDEs (i.e. IntelliJ IDEA)

If you find that Fleet is incorrectly marking software as vulnerable (false positive) or missing a vulnerability (false negative), please file a bug. 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.

Linux coverage

Linux vulnerability coverage depends on the distribution (flavor).

Type	Ubuntu	Red Hat Enterprise Linux (RHEL) and CentOS	Fedora	Amazon Linux	Debian	Arch Linux and Omarchy	openSUSE
Kernel (OS)	✅	✅	✅	✅	✅*	❌	❌
Browser plugins	✅	✅	✅	✅	✅	✅	✅
Packages	✅	✅	✅	✅	❌	✅*	✅*
Cross-platform packages (Python, npm)	✅	✅	✅	✅	✅	✅	✅
IDE extensions	✅	✅	✅	✅	✅	✅	✅

* Software is matched against the NVD by version alone, which can produce false positives because the NVD doesn't account for distribution-specific backported security fixes.

Details

• Kernel (OS) vulnerabilities are detected against any installed kernel, even if it isn't the running kernel. For Ubuntu, known kernel variants (e.g. -generic, -aws, -azure) are detected using OVAL, while custom kernels with unknown variants fall back to the NVD. For RHEL 7–9, the kernel is detected using goval-dictionary.
• Debian is not covered by an advisory feed, so its deb system packages aren't scanned. Only the Debian kernel (linux-image-*) is matched against the NVD, which may report false positives because Debian backports security fixes.
• Arch Linux and Omarchy have no kernel (OS) vulnerability detection. pacman packages are matched against the NVD by version, which can produce false positives.
• Packages for Ubuntu, RHEL, CentOS, and Fedora are detected using OVAL definitions, except for vulnerabilities involving configuration files. Fedora reports as a RHEL platform and is covered by RHEL OVAL definitions mapped by version (through Fedora 40, released June 2024).
• Amazon Linux packages are detected using Amazon's ALAS advisories via goval-dictionary instead of OVAL, because Amazon backports fixes independently of RHEL.

Sources

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

Source	macOS	Windows	Linux
National Vulnerability Database (NVD)	CVE feeds	CVE feeds	CVE feeds; fallback for custom Ubuntu kernels, Debian kernel, Arch Linux packages, and other distributions
VulnCheck	Enriched NVD CPE data	Enriched NVD CPE data	Enriched NVD CPE data
Mac Office release notes	Office for Mac vulnerabilities	N/A	N/A
Microsoft MSRC Security Bulletins	N/A	Windows OS vulnerabilities	N/A
OVAL definitions	N/A	N/A	Ubuntu, RHEL, CentOS, and Fedora packages
Amazon Linux Security Advisories (ALAS) via goval-dictionary	N/A	N/A	Amazon Linux packages and RHEL 7–9 kernel vulnerabilities

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.

Limitations

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.

Vulnerabilities that only impact software on specific operating systems may not be properly identified. Fleet does not take the hosts' operating system into account; CPEs are matched in isolation, only examining the software version.

Vulnerabilities that only impact specific software configurations are still reported. For example, Fleet will mark the curl Homebrew package with CVE-2023-28320 even if curl is not forced to use synchronous resolvers.

On macOS, Fleet reports vulnerabilities in the built-in Python. This version is managed exclusively by Apple, isn't intended for user workloads, and can't be patched, upgraded, or removed without breaking macOS system services. These vulnerabilities can be safely ignored.

Advanced

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. You can still trigger an ad-hoc vulnerability scan using fleetctl trigger --name=vulnerabilities. The dedicated vulnerability processing server will pick up the request within 60 seconds.

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

fleet vuln_processing