Automated fix version sync for CVEs from GitHub release labels to Jira

[abstractj]

Summary

Enable keycloak-github-bot to automatically update Jira issue fix versions based on release labels applied to CVE issues in keycloak-private, eliminating manual cross-referencing and giving the Continuous Delivery team visibility into upcoming fixes.

Problem statement

There's a disconnect between where CVE work happens (GitHub/keycloak-private) and where release planning for RHBK happens (Jira):

1. Secalert creates Jira issue trackers for CVEs
2. Engineers fix CVEs in keycloak-private and apply release labels (e.g., 26.0.x, 24.0.x) versions that will include the fix
3. Someone from the security team has to manually find each CVE in keycloak-private, check its release labels, then update the corresponding Jira issue with the correct fix version(s)
4. Until that manual step happens, the Continuous Delivery team has no visibility into which fixes are coming in their release backlog

This manual matching is error-prone and is creating delays. The CD team ends up flying blind, and the security team wastes time on it instead of real security work.

Proposed solution

Automate the label-to-fix-version sync:

1. Jira issue trackers are created by secalert — no change here
2. Bot monitors keycloak-private for release labels — when a CVE issue gets a release label (e.g., 26.0.5), the bot detects it
3. Bot updates the corresponding Jira issue — sets the fix version field to match the release label(s)
4. Continuous updates — if labels are added or removed on GitHub, the bot syncs those changes to Jira

The bot already knows about CVE IDs from the existing flow, so it has the linkage needed to match GitHub issues to Jira issues.

Current

flowchart LR
    subgraph Current["Current workflow"]
        direction TB
        A1[Secalert creates Jira issue] --> B1[Human checks keycloak-private for CVE]
        B1 --> C1[Human reads release labels]
        C1 --> D1[Human updates Jira fix version]
        D1 --> E1[CD team finally sees the fix in backlog]
    end

Loading

Proposal

flowchart LR
    subgraph Proposed["Proposed workflow"]
        direction TB
        A2[Secalert creates Jira issue] --> B2[Bot detects release labels on keycloak-private]
        B2 --> C2[Bot updates Jira fix version]
        C2 --> D2[CD team sees fix in backlog immediately]
    end

Loading

Value & benefits

Benefit	Who benefits from it	Impact
Real-time release visibility	Continuous Delivery team	Fixes appear in their backlog as soon as labels are applied, not days later
Eliminated manual toil	Security team	No more cross-referencing GitHub and Jira to update fix versions
Reduced errors	Everyone	No more missed or incorrect fix versions from human error
Faster release cycles	CD team, product	No delays waiting for someone tell which CVEs must go into the RHBK releases

User stories / scenarios

Scenario: Fix labeled for multiple releases

An engineer fixes CVE-2025-98765 in keycloak-private and applies labels 26.0.5 and 24.0.12 (backport). Within minutes, the bot updates the Jira issue tracker to show fix versions 26.0.5 and 24.0.12. The CD team planning the 26.0.5 release immediately sees this CVE in their backlog without anyone pinging them or manually updating Jira.

Scenario: Label removed after backport decision changes

A backport to 24.0.x is initially planned, but later the team decides not to backport. The engineer removes the 24.0.12 label from the GitHub issue. The bot detects the removal and updates Jira, removing 24.0.12 from the fix versions. The CD team's backlog reflects reality without manual intervention.

Acceptance criteria

• When a release label is added to a CVE issue in keycloak-private, the bot updates the corresponding Jira issue's fix version within minutes
• When a release label is removed, the bot removes that fix version from Jira
• Multiple release labels result in multiple fix versions on distinct Jira issues
• The bot handles label additions/removals on existing issues, not just newly labeled ones
• The bot logs all fix version updates for auditability
• If no corresponding Jira issue exists yet, the bot checks again on the next time

Out of scope

• Creating Jira issues (secalert handles that)
• Syncing fix versions from Jira back to GitHub labels
• Modifying the release labeling in keycloak-private
• Any other Jira fields beyond fix version

Discussion

No response

Motivation

No response

Details

No response

[stianst]

We shouldn't have two places that sync GH issues to JIRA, and we have a few different things right now that needs to be consolidated; there's some workflow that sync GH issues with JIRA already as well as some script that is used to import bugs fixed from GH issues to JIRA.

We should discuss this one for @PavelVlha to come up with a single solution for this.

[abstractj]

@stianst I am strictly speaking about CVEs in Jira. Today, these are manually maintained by me, which means going one by one through Jira to ensure that fix versions match keycloak-private. I really don't want to use any other tooling when it comes to CVEs, considering that they contain sensitive information.