## Goal | User story | |:---------------------------------------------------------------------------| | As a security engineer in the Software > Software Titles/Versions tables, | I want to filter software by vulnerability severity (CVSS v3) and known exploit (CISA) | so that I can decide which software to prioritize patching. ## Context - Product designer: @noahtalerman ## Changes ### Product - [x] UI changes: [Figma](https://www.figma.com/design/dz9FQ7H7li4p2PSJ2JybCM/%2319099-Improve-sorting-%26-matching-capabilities-of-Fleet-UI-vulnerabilities-view?node-id=0-1&t=6vRRDGjZqUpnuJZh-1) - [x] REST API changes: API design PR is [here](https://github.com/fleetdm/fleet/pull/20684). - [x] Outdated documentation changes: Update REST API docs - [x] Changes to paid features or tiers: New filters are available in Fleet Premium ### Engineering - [ ] Database schema migrations: TODO <!-- Specify what changes to the database schema are required. (This will be used to change migration scripts accordingly.) Remove this checkbox if there are no changes necessary. --> - [ ] Load testing: TODO <!-- List any required scalability testing to be conducted. Remove this checkbox if there is no scalability testing required. --> > ℹ️ Please read this issue carefully and understand it. Pay [special attention](https://fleetdm.com/handbook/company/development-groups#developing-from-wireframes) to UI wireframes, especially "dev notes". ## QA ### Risk assessment - Requires load testing: TODO <!-- User story has performance implications that require load testing. Otherwise, remove this item. --> - Risk level: Low / High TODO <!-- Choose one. Consider: Does this change come with performance risks? Any risk of accidental log spew? Any particular regressions to watch out for? Any potential compatibility issues, even if it's not technically a breaking change? --> - Risk description: TODO <!-- If the risk level is high, explain why. If low, remove. --> ### Manual testing steps <!-- Add detailed manual testing steps for all affected user roles. --> 1. Step 1 2. Step 2 3. Step 3 <!-- Consider: Do the steps above apply to all global access roles, including admin, maintainer, observer, observer+, and GitOps? Do the steps above apply to all team-level access roles? If not, write the steps used to test each variation. --> ### Testing notes <!-- Any additional testing notes relevant to this story or tools required for testing. --> ### Confirmation <!-- The engineer responsible for implementing this user story completes the test plan before moving to the "Ready for QA" column. --> 1. [ ] Engineer (@____): Added comment to user story confirming successful completion of QA. 2. [ ] QA (@____): Added comment to user story confirming successful completion of QA.
Goal
Context
Changes
Product
Engineering
QA
Risk assessment
Manual testing steps
Testing notes
Confirmation