resolve-cve

resolve-cve

The user provides a Jira key (e.g., OLS-789) or a Jira URL. If no specific issue is given, find CVEs to triage by searching the current sprint in the OpenShift Lightspeed Service (OLS) project:

project = OLS AND type = Vulnerability AND sprint in openSprints()
  AND summary ~ "openshift-lightspeed/lightspeed-service-api-rhel9"
  AND statusCategory = "To Do"
  ORDER BY priority DESC

Only process issues whose summary contains openshift-lightspeed/lightspeed-service-api-rhel9 — these are the service CVEs. Skip issues targeting other components (e.g., operator, console plugin).

The summary format is: CVE-YYYY-NNNNN openshift-lightspeed/lightspeed-service-api-rhel9: {Package}: {Title} [ols-N]

If using Jira MCP and the cloudId is unknown, call getAccessibleAtlassianResources to discover it, or ask the user.

Step 1: Read the CVE Issue

Fetch the issue via getJiraIssue with responseContentFormat: "markdown". The issue type is Vulnerability, not a regular story.

Parse the data from these locations:

• CVE ID — embedded in the summary field, e.g., CVE-2026-33231 openshift-lightspeed/...: NLTK: ...
• Affected package — mentioned in the description's Flaw: section (the description starts with boilerplate — "Security Tracking Issue", "Do not make this issue public" — skip to the flaw text after the --- separator)
• Vulnerable version range — in the flaw prose
• Fix reference — upstream commit or PR link, if mentioned in the flaw text

Then look up severity externally:

• CVSS score — use WebSearch for the CVE ID on NVD (e.g., CVE-2026-33231 NVD) to get the severity rating

If the issue is missing a CVE ID or the affected package is unclear from the flaw text, ask the user to clarify.

Step 2: Assess Impact

Determine whether this project is affected:

1. Check if the package is a dependency — search pyproject.toml and uv.lock for the package name. Match case-insensitively (Jira may say NLTK, lock file has nltk). If not present at all, the project is not affected.
2. Check the installed version — find the exact version in uv.lock. Compare against the vulnerable version range from the advisory.
3. Check if the vulnerable code path is reachable — if the CVE targets a specific feature or module of the package, search the codebase for imports and usage of that feature. If the project never calls the affected API, it may be not affected even if the version is in range.
4. Check transitive dependencies — if the package isn't a direct dependency, check whether it appears as a transitive dependency in uv.lock. Trace which direct dependency pulls it in.

Step 3: Present Assessment

Present the finding to the user clearly:

CVE Assessment: {CVE-ID}

Package: {package name}
Vulnerable versions: {range}
Installed version: {version from uv.lock}
Direct dependency: {yes/no — if no, pulled in by {parent}}

GATE — do not proceed without user acknowledgment. The user may have context that changes the verdict (e.g., the package is used indirectly, or the feature is enabled in production but not in tests). Present the assessment and stop. Only continue after explicit "go".

Step 4: Resolve

Based on the verdict and user acknowledgment:

Path A: Not Affected

1. Add a comment to the Jira issue via addCommentToJiraIssue with contentFormat: "markdown":

   **Assessment: Not Affected**
    
   {CVE-ID} targets {package} versions {range}.
    
   {Reason — one of:}
   - Package is not in the dependency tree.
   - Installed version ({version}) is outside the
     vulnerable range.
   - The vulnerable code path ({specific API/module}) is
     not used by this project.
    
   No action required.

2. Transition the issue to Done / Closed with resolution "Won't Do". Call getTransitionsForJiraIssue to find the transition ID for "Done" or "Closed", then transitionJiraIssue with that ID and resolution: { name: "Won't Do" } in the fields.

Path B: Dependency Bump

Follow the deps-update skill with the specific package name. It will bump only that package, run all verification gates, and raise a PR.

After the bump, verify the new version in uv.lock is outside the vulnerable range. If the latest release is still vulnerable, stop and tell the user — no fix is available upstream yet.

Then add a Jira comment:

**Resolution: Dependency bumped**
 
{CVE-ID} targets {package} versions {range}.
Bumped {package} from {old version} to {new version}.
 
Lint/types/tests: passing.

Ask user about Jira transition (same as Path A step 2).

Path C: Code Change (Rare)

1. Explain to the user what code change is needed and why. This is unusual — confirm the approach before implementing.
2. Make the targeted fix, write or update tests, and run make verify && make check-types && make test-unit.
3. Add a Jira comment summarizing the code change.
4. Ask user about Jira transition.

Step 5: Report

CVE {CVE-ID} resolved for {story_id}.
 
Verdict: {Not Affected / Bumped {package} to {version} / Code fix applied}
Jira: {commented / commented + transitioned to {status}}
 
{If files changed:}
Files changed:
  - {list files}
 
Ready to commit.
{End if}

If the user wants a commit (Path B or C), use message:

fix: resolve {CVE-ID} — bump {package} to {version}

or for code changes:

fix: resolve {CVE-ID} — {brief description}

Constraints

• User acknowledgment required — never act on the verdict without the user confirming the assessment. They may know things the codebase analysis cannot reveal.
• Jira transitions — Path A (Not Affected) transitions automatically to Done/Closed with resolution "Won't Do". For Paths B and C, ask the user which transition to use.
• Minimal changes — bump only the affected package, not all dependencies. Use --upgrade-package, not --upgrade.
• Verify after every change — lint, types, and unit tests must pass before declaring done.
• Do not downplay severity — if the project is affected, say so clearly. Do not stretch "not affected" reasoning to avoid work.