mirror of
https://github.com/fleetdm/fleet
synced 2026-05-09 10:11:03 +00:00
106 lines
5.1 KiB
Markdown
106 lines
5.1 KiB
Markdown
# Vulnerability processing
|
|
|
|
## Introduction
|
|
|
|
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).
|
|
|
|
[Learn more](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Vulnerability-processing.md) about how it works for different platforms.
|
|
|
|
<div purpose="embedded-content">
|
|
<iframe src="https://www.youtube.com/embed/amJFecMWyvI" allowfullscreen></iframe>
|
|
</div>
|
|
|
|
## 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 | Adhere to whatever is defined in the [OVAL definitions](https://github.com/fleetdm/nvd/blob/master/oval_sources.json), except for kernel vulnerabilities and vulnerabilities involving configuration files. Supported distributions: <ul><li>Ubuntu</li><li>RHEL based distros (Red Hat, CentOS, Fedora, and Amazon Linux)</li></ul> |
|
|
| IDE extensions | VS Code extensions | VS Code extensions | VS Code extensions |
|
|
|
|
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.
|
|
|
|
## Configuration
|
|
|
|
When upgrading to Fleet 4.7.0 or later, vulnerability processing is automatically enabled if
|
|
vulnerability processing and software inventory are not explicitly disabled.
|
|
|
|
If you explicitly disabled vulnerability processing, and now would like to enable this feature, first enable the software inventory feature by setting the following app config:
|
|
|
|
```yaml
|
|
---
|
|
apiVersion: v1
|
|
kind: config
|
|
spec:
|
|
features:
|
|
enable_software_inventory: true
|
|
```
|
|
|
|
Then, enable vulnerability processing by specifying a path where Fleet will download the different
|
|
data feeds. This can be done by setting the following app config:
|
|
|
|
```yaml
|
|
---
|
|
apiVersion: v1
|
|
kind: config
|
|
spec:
|
|
vulnerabilities:
|
|
databases_path: /some/path
|
|
```
|
|
|
|
Or through environment variables:
|
|
|
|
```text
|
|
FLEET_VULNERABILITIES_DATABASES_PATH=/some/path
|
|
```
|
|
|
|
The path specified needs to exist and Fleet needs to be able to read and write to and from it. This is the only mandatory
|
|
configuration needed for vulnerability processing to work. Additional options, like vulnerability check frequency, can be
|
|
found in the [configuration documentation](https://fleetdm.com/docs/deploying/configuration#vulnerabilities).
|
|
|
|
You'll need to restart the Fleet instances after changing these settings.
|
|
|
|
### 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](https://fleetdm.com/docs/deploying/configuration#current-instance-checks), 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](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
|
|
|
|
```bash
|
|
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.
|
|
|
|
```text
|
|
fleet vuln_processing
|
|
```
|
|
|
|
<meta name="pageOrderInSection" value="1300">
|
|
<meta name="description" value="Find out how Fleet detects vulnerabilities and what software it covers.">
|
|
<meta name="navSection" value="Vuln management">
|