fleet/docs/Using Fleet/Vulnerability-Processing.md

# 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">