2021-12-30 22:50:27 +00:00
# Vulnerability processing
2023-09-14 16:38:36 +00:00
2024-01-10 14:18:36 +00:00
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 ](#coverage ).
2021-08-11 16:42:16 +00:00
2023-12-15 21:54:10 +00:00
[Learn more ](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Vulnerability-processing.md ) about how it works for different platforms.
2021-08-23 23:37:00 +00:00
2022-08-29 17:57:09 +00:00
< div purpose = "embedded-content" >
< iframe src = "https://www.youtube.com/embed/amJFecMWyvI" allowfullscreen > < / iframe >
< / div >
2022-05-23 20:22:46 +00:00
## Coverage
2023-12-15 21:54:10 +00:00
Fleet detects vulnerabilities for these software types:
2023-09-14 16:38:36 +00:00
2024-08-27 02:38:03 +00:00
| Type | macOS | Windows | Linux |
| ------------------- | ------------------------------------------ | ------------------------------------------------ |--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Apps | ✅ | ✅ | ❌ |
| Browser plugins | Chrome extensions, Firefox extensions | Chrome extensions, Firefox extensions | ❌ |
| Packages | Python, Homebrew | Python, Atom, Chocolatey | < p > For Ubuntu, Debian, RHEL (including CentOS), and Fedora: 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 Amazon Linux, packages maintained by Amazon by checking [ALAS advisories ](https://alas.aws.amazon.com/ ).</ p > |
| IDE extensions | VS Code extensions | VS Code extensions | VS Code extensions |
2022-05-23 20:22:46 +00:00
2023-12-15 21:54:10 +00:00
As of right now, only app names with all ASCII characters are supported. Apps with names featuring non-ASCII characters, such as Cyrillic, will not generate matches.
2022-05-23 20:22:46 +00:00
2024-07-11 15:40:44 +00:00
For Ubuntu Linux, kernel vulnerabilities with known variants (ie. `-generic` ) are detected using OVAL. Custom kernels (unknown variants) are detected using NVD.
2024-08-14 17:55:25 +00:00
## Sources
Fleet combines multiple sources to get accurate and up-to-date CVE information:
2024-10-30 16:30:58 +00:00
- [National Vulnerability Database ](https://nvd.nist.gov/developers/vulnerabilities ) CVE feeds and CVSS scores from primary sources (available on Fleet Premium).
- [VulnCheck ](https://vulncheck.com/ ) Enriched NVD CPE data
- [Mac Office release notes ](https://learn.microsoft.com/en-us/officeupdates/release-notes-office-for-mac ) Office for Mac vulnerabilities
2024-08-14 17:55:25 +00:00
- [Microsoft MSRC Security Bulletins ](https://msrc.microsoft.com/update-guide ) for Windows OS vulnerabilities
- [OVAL definitions ](https://github.com/fleetdm/nvd/blob/master/oval_sources.json ) for Linux software
## Advanced configuration
2023-02-17 15:00:57 +00:00
Fleet runs vulnerability downloading and processing via internal scheduled cron job. This internal mechanism is very useful
2023-09-14 16:38:36 +00:00
for frictionless deployments and is well suited for most use cases. However, in larger deployments,
2023-02-17 15:00:57 +00:00
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
2024-04-15 15:25:04 +00:00
`disable_schedule` to `true` but still run one Fleet server as `false` , but the drawback here is still having to dedicate resources
2023-02-17 15:00:57 +00:00
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 ](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/scheduling_tasks.html )
- [K8S ](https://kubernetes.io/docs/tasks/job/automated-tasks-with-cron-jobs/ )
- [GCP ](https://cloud.google.com/run/docs/triggering/using-scheduler#create_job )
- [Plain old cron ](https://en.wikipedia.org/wiki/Cron )
To opt into this functionality, be sure to configure your Fleet server deployment with
2023-09-14 16:38:36 +00:00
```bash
2023-02-17 15:00:57 +00:00
FLEET_VULNERABILITIES_DISABLE_SCHEDULE=true
```
2023-09-14 16:38:36 +00:00
2023-02-17 15:00:57 +00:00
which will **disable** the internal scheduling mechanism for vulnerability processing.
2023-09-14 16:38:36 +00:00
And then externally run with the same environment variables/configuration files passed to the server
command.
```text
2023-02-17 15:00:57 +00:00
fleet vuln_processing
```
2024-08-16 20:30:31 +00:00
< meta name = "category" value = "guides" >
< meta name = "authorGitHubUsername" value = "noahtalerman" >
< meta name = "authorFullName" value = "Noah Talerman" >
< meta name = "publishedOn" value = "2024-07-12" >
< meta name = "articleTitle" value = "Vulnerability processing" >
2023-07-13 16:57:17 +00:00
< meta name = "description" value = "Find out how Fleet detects vulnerabilities and what software it covers." >
