Rework Ticket Integration - One Ticket per Vulnerability - Path Management - Interactivity

Current situation

Currently, there are tickets opened for every path to a vulnerability. Each path is a dependency vulnerability that can be managed separately via each individual ticket. As in the screenshot below, this can be confusing for users, as it seems, there are a lot of duplicated tickets (in fact different paths).

We need to rework the current creation of tickets to improve user experience.

Proposal

• One ticket per vulnerability (CVE/ GHSA, etc.) only
• Ticket content should reflect the number of paths (There are 8 paths to this vulnerability)
• Ticket content should be updated accordingly when sets of path are handled (There are 8 paths to this vulnerability -> vex rule applied -> There are 4 paths to this vulnerability)
• A Syntax need to be defined and explained in the ticket how to handle via ticket with a vex rule (e.g. /vex-rule * -> next)
• DevGuard should provide additional feedback on ticket interactions
  • Response on false commands
  • Response on taken actions after commands
  • Response on missing permissions
  • Explain relevant updates/ like events in the UI

No files, tests, or entry points are named. Start by mapping the existing ticket integration, vulnerability path handling, and ticket-command interaction flow, then clarify the intended one-ticket model, path-count updates, VEX syntax, feedback behavior, and acceptance tests before implementation.