Skip to content

Move getCVEMatchingRules to github repo as artifact #42988

@ksykulev

Description

@ksykulev

Goal

User story
As an engineer,
I want to use a custom_cve_rules.json as a release artifact
so that I can fix false positives and negatives more quickly.

Background

During vulnerability scanning we use a method named getCVEMatchingRules in server/vulnerabilities/customcve/matching_rules.go. It's purpose is to add missing CVEs to software. It runs after all other vulnerability matching has occurred and can be used to manually assign CVEs that don't match via a CPE.
The rules currently reside on a file in the fleet server code and thus can only be updated with a new release.

Changes

Move this code to a json file named custom_cve_rules.json. This can then be packaged with a release similar to cpe_translations.json. These releases are generated every 30 minutes on https://github.com/fleetdm/nvd. This file can then be downloaded when the vulnerability scanning runs on the fleet server. And therefore making changes to this file can be sent to clients faster than the typical 3 week cycle.

Engineering

  • Test plan is finalized
  • Contributor API changes: TODO
  • Feature guide changes: TODO
  • Database schema migrations: TODO
  • Load testing: TODO
  • Pre-QA load test: TODO
  • Load testing/osquery-perf improvements: TODO
  • This is a premium only feature: Yes / No

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

Risk assessment

  • Requires testing in a hosted environment: TODO
  • Requires load testing: TODO
  • Risk level: Low / High TODO
  • Risk description: TODO

Test plan

Make sure to go through the list and consider all events that might be related to this story, so we catch edge cases earlier.

Core flow

  • TODO
  • TODO
  • TODO

UI

  • Verify that all UI changes specified in the Figma wireframes are correctly implemented
  • Verify expected UI states (loading, empty, error states if applicable)

API

  • Test all API endpoints added or modified in the API changes section of this issue
  • Verify error handling for invalid inputs where applicable

GitOps (generate + run)

  • Configure the feature through the UI and run fleetctl generate-gitops
  • Confirm the generated .yml includes the expected fields (compare with YAML changes in the Product section)
  • Modify the generated .yml and run fleetctl gitops
  • Confirm the configuration updates correctly in Fleet
  • Enable GitOps mode and verify the feature behaves correctly

Permissions

  • Verify role restrictions are applied correctly for global roles
  • Verify role restrictions are applied correctly for fleet-level roles

Edge cases

  • TODO
  • TODO
  • TODO

Supplemental testing

Testing notes

Confirmation

  1. Engineer: Added comment to user story confirming successful completion of test plan (include any special setup, test data, or configuration used during development/testing if applicable).
  2. QA: Added comment to user story confirming successful completion of test plan.

Metadata

Metadata

Assignees

Labels

storyA user story defining an entire feature~engineering-initiatedEngineering-initiated story, such as a bug, refactor, or contributor experience improvement.

Type

No type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions