Adds the risk scoring rubric and mitigation/approval requirements to
Fleet's risk management policy in the handbook.
## What changed
Two new sections in `handbook/it/security.md`, between the risk
management policy and the existing risk corrective action timelines:
**Risk scoring rubric** — documents how risks in the risk register are
scored:
- Likelihood scale (1 Very unlikely → 5 Very likely)
- Impact scale (1 Very low impact → 5 Very high impact)
- Risk score = `likelihood × impact`, with level bands Low (1–6), Medium
(7–19), High (20–25)
- The full 5×5 matrix of every likelihood/impact combination
The matrix is built as a native markdown table rather than an embedded
screenshot, and each cell states its risk level in text ("20 (High)")
instead of relying on color alone, so it renders on fleetdm.com, stays
diffable, and is readable without color.
**Risk mitigation and approval** — documents when a risk requires
mitigation and who must approve accepting it instead:
- Low and Medium: mitigation not required (best effort, within the
corrective action timeline), no approval needed to accept
- High: mitigation required via a documented treatment plan, and
accepting it instead requires Head of Security and CIO approval
- Accepting a high risk needs a business justification, compensating
controls, and an expiration date no longer than one year, reviewed on or
before expiry
- Missing the corrective action timeline is treated as an accepted risk
and needs the same approval
- Rescoring a risk down requires the same approval as accepting it at
its original level
## Why
The rubric was previously only documented in our risk register tool, and
the policy didn't say what triggers mitigation or whose approval is
needed to accept a risk. Both are now in the handbook alongside the
corrective action timelines they interact with.
## Notes for reviewers
- The level bands are derived from the existing rubric's color
boundaries: Low tops out at 6, Medium covers 8–16, High starts at 20.
The band ranges are written as 1–6 / 7–19 / 20–25 to cover the gaps that
`likelihood × impact` can't produce.
- Only high risks gate on approval. Medium risks are treated the same as
low ones: mitigate on a best-effort basis within the existing 120-day
corrective action timeline, no approval required to accept. Approval
authorities follow the pattern already used elsewhere in this handbook
page (policy exceptions require Head of Security and CEO approval), with
the CIO as the second approver for high risks.
- The pre-existing "Acceptable Risk Levels" section is left as-is. It
says risks that are either low impact or low probability are generally
acceptable, which the rubric mostly agrees with, with the exception of
very high impact × unlikely (score 10, Medium). Happy to fold that
section into the rubric in a follow-up if reviewers prefer one source of
truth.
# Checklist for submitter
- [x] Handbook-only change. No code, tests, migrations, configuration
settings, or fleetd changes.
Add comprehensive documentation of secure configuration baselines for
Fleet's AWS cloud infrastructure, including organization-level controls,
identity and access management, customer environment baseline
(encryption, networking, database, compute), and known deviations.
Covers infrastructure-as-code approach via Terraform with alignment to
AWS FSBP, CIS AWS Foundations Benchmark, and NIST 800-53 standards.
**Related issue:** N/A (documentation-only improvement)
# Checklist for submitter
- ~Changes file added~ (documentation-only change, no changes file
needed)
## Testing
- [x] QA'd all new/changed functionality manually
Verified the markdown renders correctly and table alignment is
consistent.
## Summary
Adds three items to the IT security handbook page
(`handbook/it/security.md`):
- Trivy row in the SAST scanning table for container image and build
artifact scanning
- Paragraph noting weekly AI-assisted security scans
- Paragraph in the Disclosure section documenting the private bug bounty
program
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add a macOS Disk management declaration profile that sets
ExternalStorage to ReadOnly, and create a manual label "Macs excluded
from external storage restrictions" for opt-outs. Register the new label
in default.yml and reference the new Disk management settings.json in
the workstations fleet controls, excluding hosts in the manual label so
they retain read-write external storage.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
## Release Notes
**New Features**
- Enforces external storage devices as read-only on macOS, Windows, and
Linux systems
- Introduces new host labels allowing administrators to selectively
exempt specific devices from external storage restrictions
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
@allenhouchins Documenting our VDP
## Summary
- Adds a pointer to Fleet's public Bugbop Vulnerability Disclosure
Program from `SECURITY.md` and `handbook/it/security.md`.
- Documents the program's in-scope, out-of-scope, and
typically-not-eligible categories so researchers can self-triage before
submitting.
- Keeps `security@fleetdm.com` as the channel for coordinated,
non-public disclosure.
Motivation: two recent informal disclosures (missing CAA, missing
MTA-STS) revealed that our published policy made no mention of the VDP
or its scope, which left the boundary ambiguous when declining
out-of-scope submissions.
## Test plan
- [ ] Verify rendered `SECURITY.md` on the repo's Security tab links to
the Bugbop program.
- [ ] Verify the handbook page renders the new VDP paragraph in the
"Disclosure" section without breaking surrounding structure.
- [ ] Confirm no internal/private program details are referenced.
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
## Summary
- Remove the entire "Hardware security keys" section from
`handbook/it/security.md`, including the "Are they YubiKeys or security
keys?" subsection and all related FAQ entries (7 items covering YubiKey
usage, setup, and recovery).
- Update the 2FA comparison table to reference **Okta Verify with
FastPass** instead of YubiKeys as the most secure authentication method.
## Context
Fleet is transitioning from hardware security keys (YubiKeys) to Okta
Verify with FastPass for phishing-resistant authentication. This PR
removes the now-outdated YubiKey documentation. A replacement section
with Okta Verify + FastPass setup instructions will land in a separate
PR.
## Changes
- **Removed**: `### Hardware security keys` section and all subsections
(setup instructions, goals, FAQ)
- **Updated**: 2FA table row from "Hardware security keys / YubiKeys" →
"Okta Verify with FastPass"
---
Built for [Andrea
Pepper](https://fleetdm.slack.com/archives/D0AENPQMD2S/p1778188035759309?thread_ts=1776965257.297969&cid=D0AENPQMD2S)
by [Kilo for Slack](https://kilo.ai/slack)
Co-authored-by: kiloconnect[bot] <240665456+kiloconnect[bot]@users.noreply.github.com>
Add macOS and Windows screen-lock configuration profiles and manual
exclusion labels, and wire them into fleet manifests and policies.
- Add macOS mobileconfig (screen-lock-inactivity) to start screensaver
after 900s and require a password with a 60s delay.
- Add Windows configuration (Screen lock timeout.xml) to set
InteractiveLogon_MachineInactivityLimit to 900s (15 minutes).
- Create manual labels: "macOS screen lock exclusions" and "Windows
screen lock exclusions" (empty host lists).
- Register the new labels in it-and-security/default.yml and include the
new profiles in workstations.yml with labels_exclude_any pointing to the
appropriate exclusion label.
- Update macOS and Windows policy YAMLs to exclude hosts in the
corresponding exclusion labels.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added macOS and Windows "screen lock exclusions" labels to allow
manual exemption of devices.
* Introduced a macOS configuration profile that enforces a 15-minute
inactivity screen lock and requires a password on resume.
* Introduced a Windows configuration profile setting an equivalent
15-minute inactivity timeout.
* Screen-lock policies now support label-based exclusions so exempted
devices are not affected.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## Summary
- Adds a new "Requesting pull request deletion" subsection to the
**GitHub security** section of the IT security handbook page
(`handbook/it/security.md`).
- Documents the step-by-step process for requesting GitHub Support to
permanently delete a pull request, including prerequisites, required
information, and important caveats.
## Changes
The new `### Requesting pull request deletion` section is added after
`### Automation` and before `## Google Workspace security`, as the last
subsection under `## GitHub security`. It covers:
1. Confirming the PR is closed
2. Signing in to GitHub Support with admin access
3. Opening a support ticket
4. Providing the required details (PR URL, reason for deletion)
5. Waiting for confirmation
An important note callout highlights that admin access is required,
deletion is permanent, and merged PRs generally cannot be deleted.
---
Built for [Luke
Heath](https://fleetdm.slack.com/archives/D0AMSD87DJL/p1773689381389609)
by [Kilo for Slack](https://kilo.ai/features/slack-integration)
Co-authored-by: kiloconnect[bot] <240665456+kiloconnect[bot]@users.noreply.github.com>
## Summary
- Updated the security incident identification and triage process (Phase
I) in the IT security handbook to clarify how Fleet members should
report suspected security incidents.
- Reports should now be sent to the **#g-security** Slack channel with
`@mention` for **@Allen Houchins** and **@Pepper (Andrea Pepper)**.
- For serious incidents or if there isn't a timely response, members
should also follow up with a direct message (DM) to both Allen Houchins
and Pepper (Andrea Pepper).
## Changes
This replaces the previous generic list of reporting methods (direct
report, email, phone, Slack) with specific, actionable guidance
directing team members to the #g-security Slack channel with the
appropriate contacts.
---
Built for [Allen
Houchins](https://fleetdm.slack.com/archives/D0AFASNBZMW/p1773202350274859)
by [Kilo for Slack](https://kilo.ai/features/slack-integration)
---------
Co-authored-by: kiloconnect[bot] <240665456+kiloconnect[bot]@users.noreply.github.com>
Co-authored-by: Allen Houchins <32207388+allenhouchins@users.noreply.github.com>
Co-authored-by: Magnus Jensen <magnus@fleetdm.com>
Allen Houchins