Fleet logo
Menu An icon indicating that interacting with this button will open the navigation menu.
Fleet logo An 'X' icon indicating that this can be interacted with to close the navigation menu.
Multi platform
Device management   (+ MDM) Orchestration   (+ monitoring) Software management   (+ CVEs) Integrations

Docs
Stories
What people are saying News Ask around Meetups COMPANY
Origins   (Fleet & osquery) The handbook Logos & artwork Why open source?

Pricing Take a tour
Multi platform
Device management + MDM Orchestration + monitoring Software management + CVEs, usage, app library Integrations
Docs
Stories
What people are saying News Ask around Take a tour Meetups COMPANY Origins   (Fleet & osquery) The handbook Logos/artwork Why open source?
Pricing Try it yourself
{{categoryFriendlyName}}/
{{thisPage.meta.articleTitle}}
search

Vulnerability processing

{{articleSubtitle}}

| The author's GitHub profile picture

Noah Talerman

Share this article on Hacker News Share this article on LinkedIn Share this article on Twitter

On this page

{{topic.title}}
Docs Docs REST API REST API Guides Guides Talk to an engineer Talk to an engineer
Suggest an editSuggest an edit

Try it out

See what Fleet can do

Start now
macOS Windows Linux

Vulnerability processing

{{articleSubtitle}}

| The author's GitHub profile picture

Noah Talerman

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 ✅ ✅ ❌
Browser plugins Chrome extensions, Firefox extensions Chrome extensions, Firefox extensions ❌
Packages Python, Homebrew Python, Atom, Chocolatey

For Ubuntu, Debian, RHEL (including CentOS), and Fedora: packages defined in the OVAL definitions, except for vulnerabilities involving configuration files.

For Amazon Linux, packages maintained by Amazon by checking ALAS advisories.

IDE extensions VS Code extensions VS Code extensions VS Code extensions

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. When false positives are fixed, it may take two hours for the false positive to disappear after upgrading Fleet.

Sources

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

  • National Vulnerability Database CVE feeds and CVSS scores from primary sources (available on Fleet Premium).
  • 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

Advanced configuration

Fleet runs vulnerability downloading and processing via internal scheduled cron job. This internal mechanism is very useful for frictionless deployments and is well suited for most use cases. However, in larger deployments, 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, by setting disable_schedule to true but still run 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 which 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

which will disable the internal scheduling mechanism for vulnerability processing.

And then externally run with the same environment variables/configuration files passed to the server command.

fleet vuln_processing
Fleet logo
Multi platform Device management Orchestration Software management Integrations Pricing
Documentation Support Docs API Release notes Get your license
Company About News Jobs Logos/artwork Why open source?
ISO 27001 coming soon a small checkmarkSOC2 Type 2 Creative Commons Licence CC BY-SA 4.0
© 2025 Fleet Inc. Privacy
Slack logo GitHub logo LinkedIn logo X (Twitter) logo Youtube logo Mastadon logo
Tried Fleet yet?

Get started with Fleet

Start
continue
×