feat: support sending notifications for all system-cve pairs

[jdobes]

RHINENG-24196

Secure Coding Practices Checklist GitHub Link

• https://github.com/RedHatInsights/secure-coding-checklist

Secure Coding Checklist

• Input Validation
• Output Encoding
• Authentication and Password Management
• Session Management
• Access Control
• Cryptographic Practices
• Error Handling and Logging
• Data Protection
• Communication Security
• System Configuration
• Database Security
• File Management
• Memory Management
• General Coding Practices

Summary by Sourcery

Add per-system CVE notification types and ensure they are generated, queued, and dispatched alongside existing account-level notifications.

New Features:

• Introduce per-system notification event types for CVSS, severity, rule, exploits, and all system-CVE combinations.
• Generate per-system notification events for each relevant system-CVE when the new notifications feature flag is enabled.

Enhancements:

• Update notificator queue processing to always send per-system notifications while keeping deduplication for account-level notifications.
• Extend the notification enum and schema version to support the new per-system notification types in the database.

Tests:

• Expand notificator and queue tests to cover per-system notification events, counts, and Kafka message emission for system-CVE pairs.

[github-actions]

SC Environment Impact Assessment

Overall Impact: 🟢 LOW

View full report

Summary

• Total Issues: 1
• 🟢 Low: 1

Detailed Findings

🟢 LOW Impact

Feature flag change detected

• File: notificator/notificator.py
• Category: feature_flags
• Details:
  • Found UNLEASH in notificator/notificator.py at line 165
• Recommendation: Verify feature flags are properly configured for SC Environment. Test bypass options for services not available in SC Environment.

Required Actions

• Review all findings above
• Verify SC Environment compatibility for all detected changes
• Update deployment documentation if needed
• Coordinate with ROSA Core team or deployment timeline

---

This assessment was automatically generated. Please review carefully and consult with the ROSA Core team for critical/high impact changes.

[sourcery-ai]

Reviewer's Guide

Adds support for sending per-system notifications for all system-CVE pairs, introduces corresponding notification types, updates queue processing logic to handle them without deduplication, wires the behavior behind a feature flag, and extends tests and DB schema accordingly.

Sequence diagram for processing system CVE notifications in queue

sequenceDiagram
  participant Producer as Notificator
  participant Queue as NotificatorQueue
  participant DB as NotificationStore
  participant Kafka as KafkaNotifier

  Producer->>Producer: make_events_for_cve(cve_id)
  Producer->>FeatureFlag: is_enabled(NEW_NOTIFICATIONS_FEATURE)
  alt feature_flag_enabled
    Producer->>Producer: add ALL_SYSTEM_NOTIFICATION
    Producer->>Producer: check is_high_cvss_cve(cve_id)
    Producer->>Producer: check is_critical_severity_cve(cve_id)
    Producer->>Producer: check is_rule_cve(cve_id)
    Producer->>Producer: check is_exploitable_cve(cve_id)
  end
  Producer-->>Queue: enqueue item with notif_events (may include system types)

  loop for_each_queue_item
    Queue->>Queue: _process_normal_queue()
    loop for_each_notif_event
      Queue->>Queue: is_system_notif = notif_event in SYSTEM_NOTIFICATION_TYPES
      alt is_system_notif
        Queue->>Queue: events = _create_notif_events(cve_id)
        Queue->>Kafka: _send_kafka_notif(org_id, inventory_id, display_name, notif_event.value, events, loop)
        Kafka-->>Queue: ack
      else is_account_level_notif
        Queue->>DB: _is_already_notified(rh_account_id, cve_id, notif_event)
        DB-->>Queue: already_notified_flag
        alt not_already_notified
          Queue->>Queue: events = _create_notif_events(cve_id)
          Queue->>Kafka: _send_kafka_notif(org_id, inventory_id, display_name, notif_event.value, events, loop)
          Kafka-->>Queue: ack
          Queue->>Queue: new_notified.add(notif_event)
        else already_notified
          Queue->>Queue: skip_notification
        end
      end
    end
    alt new_notified_not_empty
      Queue->>DB: _register_notified_acc(cve_id, new_notified, rh_account_id)
      DB-->>Queue: ack
    end
  end

Loading

Entity relationship diagram for notification enum and notified accounts

erDiagram
  notified_accounts {
    bigint rh_account_id
    bigint cve_id
    notification notification_type
    timestamp notified_at
  }

  notification_enum {
    text value
  }

  notification_enum ||--o{ notified_accounts : has_values

  %% logical contents of notification_enum
  notification_enum {
    text new_cve_cvss
    text new_cve_severity
    text new_cve_security_rule
    text any_cve_known_exploit
    text new_cve_all
    text new_system_cve_cvss
    text new_system_cve_severity
    text new_system_cve_security_rule
    text any_system_cve_known_exploit
    text new_system_cve_all
  }

Loading

Class diagram for updated notification types and queue processing

classDiagram
  class NotificationType {
    <<enum>>
    CVSS_NOTIFICATION
    SEVERITY_NOTIFICATION
    RULE_NOTIFICATION
    EXPLOITS_NOTIFICATION
    ALL_NOTIFICATION
    CVSS_SYSTEM_NOTIFICATION
    SEVERITY_SYSTEM_NOTIFICATION
    RULE_SYSTEM_NOTIFICATION
    EXPLOITS_SYSTEM_NOTIFICATION
    ALL_SYSTEM_NOTIFICATION
  }

  class SYSTEM_NOTIFICATION_TYPES {
    <<set>>
    +NotificationType CVSS_SYSTEM_NOTIFICATION
    +NotificationType SEVERITY_SYSTEM_NOTIFICATION
    +NotificationType RULE_SYSTEM_NOTIFICATION
    +NotificationType EXPLOITS_SYSTEM_NOTIFICATION
    +NotificationType ALL_SYSTEM_NOTIFICATION
  }

  class Notificator {
    +make_events_for_cve(cve_id)
    +is_exploitable_cve(cve_id)
    +is_high_cvss_cve(cve_id)
    +is_critical_severity_cve(cve_id)
    +is_rule_cve(cve_id)
  }

  class NotificatorQueue {
    +_process_normal_queue()
    +_is_already_notified(rh_account_id, cve_id, notif_event)
    +_create_notif_events(cve_id)
    +_send_kafka_notif(org_id, inventory_id, display_name, notif_type_value, events, loop)
    +_register_notified_acc(cve_id, new_notified, rh_account_id)
  }

  class FeatureFlagClient {
    +is_enabled(feature_name)
  }

  class NEW_NOTIFICATIONS_FEATURE {
    <<constant>>
  }

  SYSTEM_NOTIFICATION_TYPES ..> NotificationType : contains
  Notificator --> NotificationType : produces_events
  Notificator --> FeatureFlagClient : uses
  FeatureFlagClient --> NEW_NOTIFICATIONS_FEATURE : checks
  NotificatorQueue --> NotificationType : consumes_events
  NotificatorQueue --> SYSTEM_NOTIFICATION_TYPES : checks_membership
  NotificatorQueue --> Notificator : calls_create_notif_events

Loading

File-Level Changes

Change	Details	Files
Introduce per-system notification types for system-CVE pairs and integrate them into notificator logic, queue processing, tests, and database schema.	Extend NotificationType enum with new per-system notification variants and define a SYSTEM_NOTIFICATION_TYPES helper set. Update notificator condition logic to emit per-system notification events alongside existing account-level events under a feature flag. Adjust notificator queue processing to always send per-system notifications without notified-accounts deduplication while still deduplicating account-level notifications. Expand unit tests for notificator, notificator conditions, and queue to assert the new per-system events, their counts, and additional Kafka messages. Bump DB schema version and add new enum values for per-system notification types in both base schema and an upgrade script.	common/peewee_model.py notificator/notificator.py notificator/notificator_queue.py tests/notificator_tests/test_notificator.py tests/notificator_tests/test_notificator_queue.py tests/notificator_tests/test_notificator_conditions.py database/schema/ve_db_postgresql.sql database/schema/upgrade_scripts/163-notif-system-cve-types.sql

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.