For #27042. Ready for review, just missing integration tests that I will be writing today. - [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/guides/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) - [ ] Added support on fleet's osquery simulator `cmd/osquery-perf` for new osquery data ingestion features. - [X] If database migrations are included, checked table schema to confirm autoupdate - For new Fleet configuration settings - [X] Verified that the setting can be managed via GitOps, or confirmed that the setting is explicitly being excluded from GitOps. If managing via Gitops: - [X] Verified that the setting is exported via `fleetctl generate-gitops` - [X] Added the setting to [the GitOps documentation](https://github.com/fleetdm/fleet/blob/main/docs/Configuration/yaml-files.md#L485) - [X] Verified that the setting is cleared on the server if it is not supplied in a YAML file (or that it is documented as being optional) - [x] Verified that any relevant UI is disabled when GitOps mode is enabled - For database migrations: - [X] Checked schema for all modified table for columns that will auto-update timestamps during migration. - [X] Confirmed that updating the timestamps is acceptable, and will not cause unwanted side effects. - [X] Ensured the correct collation is explicitly set for character columns (`COLLATE utf8mb4_unicode_ci`). - [x] Added/updated automated tests - [X] Manual QA for all new/changed functionality --------- Co-authored-by: jacobshandling <61553566+jacobshandling@users.noreply.github.com> Co-authored-by: Jacob Shandling <jacob@fleetdm.com> |
||
|---|---|---|
| .. | ||
| code | ||
| vex | ||
| README.md | ||
| status.md | ||
Security
Directory contents
- status.md: Current status of vulnerabilities reported on Fleet software components by security scanners (trivy, docker scout). This document is currently auto-generated from files in the
vex/directory. code/: Files used for vulnerability scanning on Fleet's source code.vex/: OpenVEX files to report status of vulnerabilities detected by Trivy on Fleet docker images.
Vulnerability scanning
The following Github CI actions perform daily vulnerability scanning on Fleet software components.
- trivy-scan.yml: Scan source code for vulnerabilities.
- build-and-check-fleetctl-docker-and-deps.yml: Scans for
HIGHandCRITICALvulnerabilities infleetctldocker image dependencies (fleetdm/fleetctl,fleetdm/wix, andfleetdm/bomutils). - goreleaser-snapshot-fleet.yaml: Scans for HIGH and CRITICAL vulnerabilities in
fleetdm/fleetdocker image before pushing to the Docker registry (runs daily and is triggered for every change in Fleet's source code). - check-vulnerabilities-in-released-docker-images.yml: Scans for
CRITICALvulnerabilities in the last 5 minor released versions of thefleetdm/fleetand on the latest release offleetdm/fleetctl.
Process to run when a CVE is reported
Updating status.md report
If trivy reports a HIGH or CRITICAL CVE on one of Fleet's docker images (reported by the previously mentioned Github Actions), then we need to assess the report and track it with a status of "not affected", "affected", "fixed", or "under investigation".
We use the OpenVEX format to track the status of reported vulnerabilities (vex/ folder).
Once the status is determined, we use the vexctl tool to create/update VEX files.
brew install vexctl
A. "Affected" status
We will use CVE-2025-27509 as an example. This CVE affected all versions of Fleet at the time (see the associated GitHub security advisory).
1. Creating "affected" status
First we would need to create a VEX entry with the "affected" status for all released Fleet versions (<= v4.63.1).
Currently, OpenVEX doesn't support version ranges, so we need to define all versions one by one. We have the
./tools/github-releasestooling to help list all released versions of Fleet.
all_fleet_releases=$(go run ./tools/github-releases --all-cpes --separator=,)
vexctl create --product="$all_fleet_releases" \
--vuln="CVE-2025-27509" \
--status="affected" \
--aliases="https://github.com/fleetdm/fleet/security/advisories/GHSA-52jx-g6m5-h735" \
--action-statement="Disable SAML SSO authentication." \
--author="@lucasmrod" > security/vex/fleet/CVE-2025-27509.vex.json
2. Updating "fixed" status
Once the fix was released in v4.64.2, v4.63.2, v4.62.4, v4.58.1 and v4.53.2 we would issue a new "fixed" statement on the existing VEX document:
vexctl add \
--document=./security/vex/fleet/CVE-2025-27509.vex.json \
--vuln="CVE-2025-27509" \
--status="fixed" \
--product="cpe:2.3:a:fleetdm:fleet:v4.64.2:*:*:*:*:*:*:*,cpe:2.3:a:fleetdm:fleet:v4.63.2:*:*:*:*:*:*:*,cpe:2.3:a:fleetdm:fleet:v4.62.4:*:*:*:*:*:*:*,cpe:2.3:a:fleetdm:fleet:v4.58.1:*:*:*:*:*:*:*,cpe:2.3:a:fleetdm:fleet:v4.53.2:*:*:*:*:*:*:*" \
--aliases="https://github.com/fleetdm/fleet/security/advisories/GHSA-52jx-g6m5-h735" \
--in-place
B. Not affected
Following is an example for a CVE reported by tooling which we know doesn't affect fleetdm/fleetctl:
Example for CVE-2023-32698 on package github.com/goreleaser/nfpm/v2 which we know doesn't affect fleetdm/fleetctl:
vexctl create --product="fleetctl,pkg:golang/github.com/goreleaser/nfpm/v2" \
--vuln="CVE-2023-32698" \
--status="not_affected" \
--author="@getvictor" \
--justification="vulnerable_code_cannot_be_controlled_by_adversary" \
--status-note="When packaging linux files, fleetctl does not use global permissions. It was verified that packed fleetd package files do not have group/global write permissions." > security/vex/fleetctl/CVE-2023-32698.vex.json
Similarly, for CVE-2024-8260 on package github.com/open-policy-agent/opa which we know doesn't affect fleetdm/fleet:
vexctl create --product="fleet,pkg:golang/github.com/open-policy-agent/opa" \
--vuln="CVE-2024-8260" \
--status="not_affected" \
--author="@lucasmrod" \
--justification="vulnerable_code_cannot_be_controlled_by_adversary" \
--status-note="Fleet doesn't run on Windows, so it's not affected by this vulnerability." > security/vex/fleetctl/CVE-2024-8260.vex.json
Examples of --product flag values (which accept "PURLs"):
liblzma5debian package:pkg:deb/debian/liblzma5.github.com/goreleaser/nfpm/v2golang package:pkg:golang/github.com/goreleaser/nfpm/v2.xerces/xercesImpljava package:pkg:maven/xerces/xercesImpl.
When new VEX files are generated or updated we can update the security/status.md file by running:
make vex-report
Updating software
If the detected vulnerability can be fixed by updating the base docker image or removing/changing components in the docker image then we do so and the update will be present on the next release. (It is good practice to keep software up-to-date.)
Process for "affected" CRITICAL vulnerabilities
fleetdm/fleet
Following is the process to run when a CRITICAL CVE affects any of the five last releases of fleetdm/fleet docker image (reported by check-vulnerabilities-in-released-docker-images.yml).
- We will use the information reported by the scanner and update our
status.mdto keep users/customers informed. - If the
CRITICALvulnerability (that has a fix) is on thelatestrelease, we'll file a critical/P0 bug and release a patch ASAP (within 1 business day). The previous four versions scanned won't be retroactively patched, onlylatestwill be patched.
fleetdm/fleetctl
Following is the process to run when a CRITICAL CVE affects the released fleetdm/fleetctl:latest docker image:
- After
security/status.mdis updated, notify users/customers about the CVE in thefleetdm/fleetctlimage and possible remediations. - Create a Github issue with a
P0/securitylabel to track the fix. - The fix will be released on the next release of the
fleetdm/fleetctldocker image.