Clean up timing for clearing stale false-positive vulnerabilities

[iansltx]

Goal

User story
As a user of vulnerability management,
I want to see fixed false-positive vulnerabilities cleared as soon as I finish a vulnerabilities cron run
so that I can quickly see the results of fixed false-positives.

Key result

Preventing erroneous customer bug report noise where the solution is "wait for vulnerabilities to run a few more times" and speeding up dev/QA of functionality touching vulnerabilities.

Context

• Product designer: @iansltx

Originally filed as bug #25898, to both mitigate QA overhead for vulnerability fixes and avoid customer back-and-forth e.g. #25571.

Changes

Product

• [ ] First draft of test plan added
• [ ] Other reference documentation changes: Last paragraph of this section of the vulnerabilities article
• [ ] Once shipped, requester has been notified
• [ ] Once shipped, dogfooding issue has been filed

Engineering

• [x] Test plan is finalized

ℹ️  Please read this issue carefully and understand it. Pay special attention to UI wireframes, especially "dev notes".

QA

Risk assessment

• Requires load testing: No
• Risk level: Low

Test plan

1. Introduce a false positive vulnerability (e.g. by reverting a previous false positive fix in the CPE matching rules JSON file).
2. Run vulnerability scanning.
3. Confirm that the false positive shows up.
4. Fix the false positive.
5. Run vulnerability scanning again.
6. Confirm that the false positive no longer shows up.

Testing notes

Confirmation

1. [ ] Engineer: Added comment to user story confirming successful completion of test plan.
2. [ ] QA: Added comment to user story confirming successful completion of test plan.

[lukeheath]

@iansltx Thanks for following the new engineering-initiated process. This sounds like a good value add effort, so I'm prioritizing for drafting and assigning you as the product designer to complete the draft an engineering-initiated story process.

[iansltx]

This actually looks product-complete, so pulling into User Story Review.

[iansltx]

Note that per the eng-init section of the handbook, irrelevant product checkboxes were deleted from the issue description.

[lukeheath]

@iansltx One thing I'm not clear on from this ticket is what is the current state? How long does it currently take for the false positive to clear?

[iansltx]

Current state is two hours. See

https://github.com/fleetdm/fleet/blob/33a703920378a7084319da99a5af5c52a1cff6a2/articles/vulnerability-processing.md?plain=1#L28

(I have a PR to fix the typo there)

which maps to this code:

https://github.com/fleetdm/fleet/blob/33a703920378a7084319da99a5af5c52a1cff6a2/server/vulnerabilities/nvd/cve.go#L326-L336

[lukeheath]

@iansltx Got it. And currently the Fleet cron runs hourly, so this change will take it from up to two hour to up to one hour?

[iansltx]

@lukeheath (sorry, misunderstood your comment, one moment)

[iansltx]

@lukeheath With this revision, the vulns run after a false positive is fixed would correct the issue. Via cron, that would happen every hour, but you could make it happen more quickly by triggering the job manually.

[iansltx]

Hey team! Please add your planning poker estimate with Zenhub @jahzielv @ksykulev

[noahtalerman]

@lukeheath chatted with @mostlikelee and decided to deprioritize this one. We want to get to customer requests first and we need to make some room.

[iansltx]

numberOfTimesExistingStaleVulnHandlingIncreasedFrictionOnVulnManagementWork++

For #28983.

[jahzielv]

yeah I forgot about that this morning: https://fleetdm.slack.com/archives/C086V2QK76X/p1747311488652479

[iansltx]

Ready for async User story review. Whoever signs off on this last, please move this directly to "Ready for estimate" and start Planning Poker, as this one's already spec-complete.

• [x] @mostlikelee
• [x] @jmwatts (you checked the "test plan finalized" box back on April 8, and the test plan hasn't been modified since, so...should be good here?)

[jmwatts]

@iansltx yes this one should be good

[mostlikelee]

planning poker

[iansltx]

Tested this by inserting an extra software_cve entry pointed at a combination of existing CVE and existing software (but a CVE that didn't actually apply to that software), with NVD as the source ID, then ran the cron. Existing vulns stuck around, but my manually inserted false positive didn't. Still traverses the relevant code paths, but took less time to verify.

[jmwatts]

QA Notes Restored a previous backup that exhibited a false positive vulnerability. Ran vulnerability scanning. Confirmed that the false positive still showed up in the previous version. Upgraded to the fix version. Ran vulnerability scanning again. Confirmed that the false positive no longer shows up.

[fleet-release]

Gone, false-positives, Like clouds parting after rain - Clarity restored.