fleet/security
Lucas Manuel Rodriguez 1c5700a8c4
Microsoft Compliance Partner backend changes (#29540)
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>
2025-06-11 14:22:46 -03:00
..
code Add scanning to released images and process to track vulnerabilities (#28087) 2025-04-16 11:50:10 -03:00
vex Skip CVE-2025-48734 for real (#29743) 2025-06-04 01:29:21 -03:00
README.md Clean up "click here" and "here" link anchors - part 1 (#29731) 2025-06-04 13:54:34 -06:00
status.md Microsoft Compliance Partner backend changes (#29540) 2025-06-11 14:22:46 -03:00

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.

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-releases tooling 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"):

  • liblzma5 debian package: pkg:deb/debian/liblzma5.
  • github.com/goreleaser/nfpm/v2 golang package: pkg:golang/github.com/goreleaser/nfpm/v2.
  • xerces/xercesImpl java 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).

  1. We will use the information reported by the scanner and update our status.md to keep users/customers informed.
  2. If the CRITICAL vulnerability (that has a fix) is on the latest release, 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, only latest will be patched.

fleetdm/fleetctl

Following is the process to run when a CRITICAL CVE affects the released fleetdm/fleetctl:latest docker image:

  1. After security/status.md is updated, notify users/customers about the CVE in the fleetdm/fleetctl image and possible remediations.
  2. Create a Github issue with a P0/security label to track the fix.
  3. The fix will be released on the next release of the fleetdm/fleetctl docker image.