[Learn more](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/architecture/software/vulnerability-processing.md) about how it works for different platforms.
| Apps | ✅ | ✅ | On Linux, apps are installed as packages (there is no separate app format like `.app` on macOS). See the Packages row for coverage details. |
| Operating system (OS) | ✅ | ✅ | ✅ <p>Linux OS vulnerabilites are the kernel vulnerabilities. Currently, Ubuntu, Debian, CentOS, Fedora, and Amazon Linux are supported.</p> |
| Packages | Python, Homebrew, npm | Python, Atom, Chocolatey, npm | ✅ <p>For Ubuntu, RHEL, and CentOS: packages defined in the [OVAL definitions](https://github.com/fleetdm/nvd/blob/master/oval_sources.json), except for vulnerabilities involving configuration files</p><p>For Fedora (up to Fedora 40, released June 2024), packages defined in RHEL OVAL definitions [mapped by version](https://github.com/fleetdm/fleet/blob/main/server/vulnerabilities/oval/parsed/utils.go).</p><p><p>For Amazon Linux, packages maintained by Amazon by checking [ALAS advisories](https://alas.aws.amazon.com/).</p> |
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](https://github.com/fleetdm/fleet/blob/main/server/vulnerabilities/nvd/cpe_translations.json) 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.
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](https://formulae.brew.sh/formula/curl) with [CVE-2023-28320](https://nvd.nist.gov/vuln/detail/CVE-2023-28320) even if curl is not forced to use synchronous resolvers.
If you find that Fleet is incorrectly marking software as vulnerable (false positive) or missing a vulnerability (false negative), please file a [bug](https://github.com/fleetdm/fleet/issues/new?template=bug-report.md).
> **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.
> **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.
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.
- 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](https://fleetdm.com/docs/deploying/configuration#current-instance-checks), 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:
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.
