[Learn more](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/guides/vulnerability-processing.md) about how it works for different platforms.
Linux OS vulnerabilites are the kernel vulnerabilities. Currently, Ubuntu, Debian, and Amazon Linux are supported. CentOS and Fedora [coming soon](https://github.com/fleetdm/fleet/issues/31495).
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.
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). When false positives are fixed, it may take two hours for the false positive to disappear after upgrading Fleet.
where there can be dozens of Fleet server replicas sitting behind a load balancer, it is desirable to manage vulnerability processing externally.
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 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
for this single host 24/7. The Fleet binary has a command which handles the same vulnerability processing, but will exit (successfully with 0) on completion. Using this sub-command we can delegate vulnerability processing