7a54a2de22
Fixes #28261. ~~Of note, this logic will prefer a non-primary CVSSv3.1 score over a primary CVSSv3.0 score if 3.1 doesn't have primary but 3.0 does. I haven't seen any evidence of this in our dataset (looked at 2024 output).~~ Updated with logic that will prefer a primary CVSSv3.0 score over a secondary CVSSv3.1 score for a given vulnerability. In the test dataset (2023 vuln snapshot, ~20k vulns) there were no cases where this situation presented itself, so output was identical to the prior implementation. Validated by comparing a vulns run from GitHub Actions to a local run with the new code, and confirmed that existing v3 scores weren't replaced when they already existed (just got adds of v2 when only v3 existed, and v2/v3 adds when no scoring existed). Confirmed that all three CVEs mentioned in #28261 show up in feed data. Added spot-checks for secondary CVSS scores to the feed validator tool. # Checklist for submitter If some of the following don't apply, delete the relevant line. <!-- Note that API documentation changes are now addressed by the product design team. --> - [x] Changes file added for user-visible changes in `changes/`, `orbit/changes/` or `ee/fleetd-chrome/changes`. See [Changes files](https://github.com/fleetdm/fleet/blob/main/docs/Contributing/Committing-Changes.md#changes-files) for more information. - [x] Input data is properly validated, `SELECT *` is avoided, SQL injection is prevented (using placeholders for values in statements) - [x] Manual QA for all new/changed functionality
7.1 KiB
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
- 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
Fleet Premium includes CVSSv3 scores from NVD CVE feeds. Primary scores are preferred to Secondary scores if both are available, and v3.1 scores of the same type are preferred to v3.0.
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:
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