sfa-cve-analysis

name	sfa-cve-analysis
description	Monitor and analyze CVE (security) issues for Server Foundation team. Groups by CVE, creates one tracking task per CVE (consolidates all affected repositories), and performs deep impact analysis across all branches.
allowed-tools	["Skill","Bash","Read","Write","WebSearch","Glob","Grep"]

CVE Analysis Skill

Automated monitoring and analysis of CVE (Common Vulnerabilities and Exposures) issues for the Server Foundation team.

Tools

This skill includes a formatting script to ensure consistent task descriptions:

• Script: .claude/skills/sfa-cve-analysis/format-cve-tracking-task.py
• Purpose: Parse JIRA issues, group by repository, and generate properly sorted tracking task descriptions
• Usage: See Step 3.2 below for detailed instructions

IMPORTANT: Always use the script to generate task descriptions. Manual formatting is error-prone and may produce incorrect repository mappings or table ordering.

Reference Loading

Before executing, load relevant references and skills as needed:

• For JIRA API queries: Use Bash + curl directly (custom JQL required)
• For adding JIRA comments: Use sfa-jira-comment skill (Step 4)
• For CVE details: Use WebSearch to fetch from NVD, Go vulnerability database
• For JIRA formatting: Read docs/jira/formatting.md (ADF format for comments)

Purpose

Systematically track, group, and manage security vulnerabilities (CVEs) across repositories by:

1. Checking if tracking task already exists
2. Using automation script to fetch, parse, group, and format CVE data
3. Creating consolidated tracking task per CVE (includes all affected repositories)

Triggers: Use this skill when the user mentions:

• "CVE analysis" or "Analyze CVE issues"
• "Analyze CVE-YYYY-NNNNN" (for specific CVE)
• "CVE report" or "Security issues analysis"
• "Track CVEs"

Workflow:

• Step 1: Check for existing tracking task
• Step 2: Generate task description using script (fetch issues → parse → group → format)
• Step 3: Create tracking task with generated description
• Step 4: Ask user if they want deep impact analysis (optional)

Parameters:

• CVE Number (optional): e.g., CVE-2025-9230
  • If provided: Analyzes all issues for that specific CVE (including Closed/Done)
  • If not provided: Analyzes all active CVE issues (NOT Closed/Done)

Instructions

Step 1: Check for Existing Tracking Task

Before creating a new tracking task, check if one already exists for this CVE.

Search Query:

project = ACM AND
issuetype = Task AND
component = "Server Foundation" AND
summary ~ "CVE-{cve_id}"

Implementation:

# Check if tracking task exists
jira issue list \
  --jql 'project = ACM AND issuetype = Task AND component = "Server Foundation" AND summary ~ "CVE-2025-9230"' \
  --columns key,summary,status \
  --plain

Logic:

• If tracking task found → Skip to Step 4 (optionally add comment with updates)
• If NOT found → Proceed to Step 2

Example:

• Query: summary ~ "CVE-2025-9230"
• Found: ACM-31793 "CVE-2025-9230 (8 issues, 4 repos)" → STOP, task exists
• Not found → Continue to Step 2

Step 2: Generate Task Description Using Script

Use the format-cve-tracking-task.py script to parse JIRA issues, group by repository, and generate formatted description.

Input Parameter: CVE number

• If provided: Query all issues for that specific CVE (including Closed/Done)
• If not provided: Query all active CVE issues (NOT Closed/Done)

Implementation:

# Step 2.1: Fetch JIRA issues as JSON
cve_id="CVE-2025-9230"  # Replace with actual CVE ID

# Build JQL based on parameters
if [ -n "$cve_id" ]; then
  jql="project = ACM AND issuetype = Vulnerability AND component = \"Server Foundation\" AND labels = Security AND summary ~ \"$cve_id\""
else
  jql="project = ACM AND issuetype = Vulnerability AND component = \"Server Foundation\" AND labels = Security AND status NOT IN (Closed, Done)"
fi

# Fetch issues via REST API v3
curl -s -X POST \
  -u "$JIRA_EMAIL:$JIRA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "{
    \"jql\": \"$jql\",
    \"fields\": [\"key\", \"summary\", \"labels\", \"versions\", \"status\", \"priority\", \"created\"],
    \"maxResults\": 100
  }" \
  "https://redhat.atlassian.net/rest/api/3/search/jql" \
  > /tmp/cve-$cve_id-issues.json

# Step 2.2: Run formatting script
python3 .claude/skills/sfa-cve-analysis/format-cve-tracking-task.py \
  /tmp/cve-$cve_id-issues.json \
  $cve_id \
  > /tmp/cve-$cve_id-description.txt

# Step 2.3: Review generated description
cat /tmp/cve-$cve_id-description.txt

What the script does:

• Parses JIRA issue JSON
• Extracts CVE ID, component, and version from each issue
• Maps components to repositories (handles multicluster-engine-* → stolostron/ocm)
• Groups issues by repository
• Sorts table by Repository → Component → Version
• Generates Markdown description with proper formatting

Script Output:

• Grouped repositories section with affected versions and issue counts
• Properly sorted issues table
• JQL query URL for finding all related issues
• Summary statistics (total repos, total issues)

Step 3: Create Tracking Task

Create the JIRA tracking task using the script-generated description.

Task Specifications:

• Type: Task
• Project: ACM
• Component: Server Foundation
• Summary: CVE-{cve_id} ({issue_count} issues, {repo_count} repos)
• Assignee: Qing Hao (712020:55a41a77-bca5-45b1-81b6-81aeddf851e1)
• Description: From script output (Step 2)
• Activity Type: Security & Compliance (must be set manually in JIRA UI after creation)

Implementation:

# Get counts from script output
issue_count=$(grep "Total Related Issues:" /tmp/cve-$cve_id-description.txt | awk '{print $5}')
repo_count=$(grep "Total Affected Repositories:" /tmp/cve-$cve_id-description.txt | awk '{print $5}')

# Create JIRA task
jira issue create \
  --project ACM \
  --type Task \
  --component "Server Foundation" \
  --summary "$cve_id ($issue_count issues, $repo_count repos)" \
  --assignee "712020:55a41a77-bca5-45b1-81b6-81aeddf851e1" \
  --body "$(cat /tmp/cve-$cve_id-description.txt)" \
  --no-input

Post-creation:

• Note the created task key (e.g., ACM-31793)
• Manually set "Activity Type" to "Security & Compliance" in JIRA UI

For existing tasks:

• Do NOT create duplicate tracking task
• Optionally add comment with newly discovered issues

---

How the Script Works (Reference)

The format-cve-tracking-task.py script performs the following analysis:

Data Extraction:

1. CVE ID: From issue summary (pattern: CVE-YYYY-NNNNN)
2. Component: From pscomponent: label or summary
3. Version: Priority order:
   • Affects Versions field (versions)
   • Summary brackets [version]
   • "Unknown - needs investigation"

Repository Mapping:

Explicit image-ref mappings (COMPONENT_TO_REPO_MAP; -rhel8/-rhel9 stripped):

• multicluster-engine/work → stolostron/ocm
• multicluster-engine/registration-operator → stolostron/ocm
• multicluster-engine/placement → stolostron/ocm
• multicluster-engine/addon-manager → stolostron/ocm
• multicluster-engine/registration → stolostron/ocm
• multicluster-engine/multicloud-manager → stolostron/multicloud-operators-foundation
• rhacm2/acm-cluster-permission → stolostron/cluster-permission
• rhacm2/klusterlet-addon-controller → stolostron/klusterlet-addon-controller

Prefix mappings (hyphenated component names):

• multicluster-engine-work-* → stolostron/ocm
• multicluster-engine-placement-* → stolostron/ocm
• multicluster-engine-addon-* → stolostron/ocm
• multicluster-engine-registration-* → stolostron/ocm
• acm-cluster-manager-addon-manager-* → stolostron/ocm

Direct mappings:

• clusterlifecycle-state-metrics-* → stolostron/clusterlifecycle-state-metrics
• klusterlet-addon-controller-* → stolostron/klusterlet-addon-controller
• multicloud-operators-foundation → stolostron/multicloud-operators-foundation

Grouping and Sorting:

• Group issues by repository
• Sort table rows by: Repository (alphabetical) → Component (alphabetical) → Version (alphabetical)

Output Format (Markdown):

CVE Tracking: {cve_id}

This task tracks the {cve_id} vulnerability across all affected Server Foundation repositories.

CVE Information

• CVE ID: {cve_id}
• Total Affected Repositories: {repo_count}
• Total Related Issues: {issue_count}
• Priority: {highest_priority}
• CVSS Score: {cvss_score} (if available)
• Discovery Date: {earliest_created_date}

Query All Related Issues

View all {cve_id} issues in JIRA

Affected Repositories

Repository: {repository_name_1}

• Affected Versions: {versions_for_repo_1}
• Related Issues: {issue_count_for_repo_1} ({comma_separated_issue_keys})

Repository: {repository_name_2}

• Affected Versions: {versions_for_repo_2}
• Related Issues: {issue_count_for_repo_2} ({comma_separated_issue_keys})

... (repeat for each affected repository)

All Related JIRA Issues

{table_of_all_related_issues}

Table Format (ordered by Repository, then Component, then Affects Version):

Issue Key	Repository	Component	Affects Version
ACM-28272	stolostron/cluster-permission	rhacm2/acm-cluster-permission-rhel9	ACM 2.14.0
ACM-28057	stolostron/cluster-proxy	multicluster-engine/cluster-proxy-addon-rhel8	MCE 2.9.0
ACM-28058	stolostron/cluster-proxy	multicluster-engine/cluster-proxy-addon-rhel9	MCE 2.9.0
ACM-28059	stolostron/cluster-proxy	multicluster-engine/cluster-proxy-rhel8	MCE 2.9.0
ACM-28060	stolostron/cluster-proxy	multicluster-engine/cluster-proxy-rhel9	MCE 2.9.0
ACM-28035	stolostron/ocm	multicluster-engine/addon-manager-rhel8	MCE 2.9.0
ACM-28036	stolostron/ocm	multicluster-engine/addon-manager-rhel9	MCE 2.9.0
...	...	...	...

Vulnerability Details

{brief_description_from_cve_database}

---

🤖 Generated with Claude Code

Step 4: Deep Impact Analysis

After Step 3 completes (tracking task created or found), ALWAYS ASK the user:

✅ Tracking task created/updated: [ACM-XXXXX](link)

Would you like me to perform deep impact analysis to check all main and z-stream branches?
This will:
- Clone affected repositories
- Check Go/package versions across all branches (main + z-streams)
- Analyze actual code usage and impact
- Generate comprehensive impact report

Proceed with deep analysis? (yes/no)

Only proceed to deep analysis if user confirms "yes" or equivalent.

When user confirms, perform deep analysis across all main and z-stream branches to determine the actual CVE impact beyond what's reported in JIRA.

Repository and Branch List:

Repository	Branches to Check
stolostron/ocm	main, backplane-2.17, backplane-2.11, backplane-2.10, backplane-2.9, backplane-2.8
stolostron/clusterlifecycle-state-metrics	main, backplane-2.17, backplane-2.11, backplane-2.10, backplane-2.9, backplane-2.8
stolostron/multicloud-operators-foundation	main, backplane-2.17, backplane-2.11, backplane-2.10, backplane-2.9, backplane-2.8
stolostron/managed-serviceaccount	main, backplane-2.17, backplane-2.11, backplane-2.10, backplane-2.9, backplane-2.8
stolostron/cluster-proxy-addon	main, backplane-2.17, backplane-2.11, backplane-2.10, backplane-2.9, backplane-2.8
stolostron/cluster-proxy	main, backplane-2.17, backplane-2.11, backplane-2.10, backplane-2.9, backplane-2.8
stolostron/managedcluster-import-controller	main, backplane-2.17, backplane-2.11, backplane-2.10, backplane-2.9, backplane-2.8
stolostron/klusterlet-addon-controller	main, release-2.17, release-2.16, release-2.15, release-2.14, release-2.13
stolostron/cluster-permission	main, release-2.17, release-2.16, release-2.15, release-2.14, release-2.13

Analysis Steps:

1. Get CVE Details

   • Query CVE database or JIRA issues to understand:
     • What is affected (Go version, specific package, code pattern)
     • Affected versions (e.g., Go < 1.23.5, package < v1.2.3)
     • Impact description

2. Clone Repositories

   • Clone repositories to /tmp/cve-analysis-{cve_id}/
   • Fetch all required branches

   mkdir -p /tmp/cve-analysis-CVE-2025-61729
   cd /tmp/cve-analysis-CVE-2025-61729
   git clone https://github.com/stolostron/{repo}.git
   cd {repo}
   git fetch origin backplane-2.17:backplane-2.17
   git fetch origin backplane-2.11:backplane-2.11
   # ... fetch other branches
   

3. Analyze Each Branch

   For each repository and branch:

   If CVE affects Go version:

   git checkout {branch}
   # Check go.mod for Go version
   grep "^go " go.mod
   

   If CVE affects a specific package:

   git checkout {branch}
   # Check if package is used
   go mod graph | grep {affected-package}
   # Analyze dependency chain
   go mod why {affected-package}
   

4. Code Impact Analysis

   • Read relevant code files
   • Check if the vulnerable code path is actually used
   • Determine if the CVE scenario applies to this codebase
   • Note: Some dependencies may be indirect and not actually trigger the vulnerability

5. Generate Impact Report

   Create a comprehensive table showing actual impact:

   CVE Impact Analysis Report

   Repository	Branch	Go Version	Affected Package Version	Dependency Chain	Impact Assessment
   stolostron/ocm	main	1.23.4	crypto/x509 (stdlib)	Direct: crypto/tls → crypto/x509	❌ Vulnerable
   stolostron/ocm	backplane-2.17	1.23.3	crypto/x509 (stdlib)	Direct: crypto/tls → crypto/x509	❌ Vulnerable
   stolostron/ocm	backplane-2.11	1.22.8	crypto/x509 (stdlib)	Direct: crypto/tls → crypto/x509	❌ Vulnerable
   stolostron/ocm	backplane-2.10	1.22.5	crypto/x509 (stdlib)	Direct: crypto/tls → crypto/x509	❌ Vulnerable
   stolostron/ocm	backplane-2.9	1.22.4	crypto/x509 (stdlib)	Direct: crypto/tls → crypto/x509	❌ Vulnerable
   stolostron/ocm	backplane-2.8	1.21.13	crypto/x509 (stdlib)	Direct: crypto/tls → crypto/x509	❌ Vulnerable
   stolostron/cluster-proxy	main	1.23.4	crypto/x509 (stdlib)	Direct: net/http → crypto/tls → crypto/x509	❌ Vulnerable
   stolostron/cluster-proxy	backplane-2.17	1.23.3	crypto/x509 (stdlib)	Direct: net/http → crypto/tls → crypto/x509	❌ Vulnerable
   ...	...	...	...	...	...

   Impact Assessment Legend:

   • ❌ Vulnerable: Package version is affected AND code uses the vulnerable functionality
   • ⚠️ Potentially Vulnerable: Package version is affected but usage needs verification
   • ✅ Not Vulnerable: Package version is not affected OR code doesn't use vulnerable code path
   • ➖ Not Applicable: Package not used in this branch

Report Format:

Deep CVE Impact Analysis: {cve_id}

CVE Summary

• CVE ID: {cve_id}
• Affected Component: {component_name}
• Vulnerable Versions: {version_range}
• Description: {cve_description}

Analysis Scope

• Repositories Analyzed: {count}
• Branches per Repository: main + z-streams
• Total Branches Checked: {total_count}

Impact Summary

• Confirmed Vulnerable: {count} branches across {repo_count} repositories
• Potentially Vulnerable: {count} branches (needs code review)
• Not Vulnerable: {count} branches
• Not Applicable: {count} branches

Detailed Findings

{impact_table}

Recommendations

1. Immediate Action Required:

   • Upgrade Go to 1.23.5+ on all vulnerable branches
   • Priority: main, backplane-2.17, backplane-2.11

2. Verification Needed:

   • Review "Potentially Vulnerable" branches
   • Confirm code usage patterns

3. Z-Stream Updates:

   • Create PRs for each affected z-stream
   • Follow backport process

Related JIRA Issues

• Original vulnerability reports (from Step 1-3)

---

🤖 Deep analysis generated with Claude Code

After Deep Analysis Completes:

Save the analysis report to /tmp/cve-analysis-{cve_id}-deep-analysis.md and ALWAYS ASK the user:

✅ Deep impact analysis complete!

Analysis report saved to: /tmp/cve-analysis-{cve_id}-deep-analysis.md

Would you like me to add this analysis as a comment to the JIRA tracking task [{ISSUE-KEY}](link)?
(yes/no)

If user confirms "yes":

• Read the report file (/tmp/cve-analysis-{cve_id}-deep-analysis.md)
• Convert Markdown report to JIRA ADF (Atlassian Document Format) for structured formatting
• Use sfa-jira-comment skill to add the analysis as a comment:

  Skill("sfa-jira-comment", args="--issue-key {ISSUE-KEY} --comment {report_content}")
  

• Alternatively, use Bash + curl to post ADF-formatted comment directly to JIRA REST API v3
• Include the full report or a summary with link to the saved file

Important Notes:

• This analysis is time-consuming (cloning repos, checking branches)
• Only perform when user confirms after Step 3
• Cache results to avoid re-analyzing same CVE
• Focus on repositories actually mentioned in the JIRA issues first
• Expand to other repos if CVE impact is broader
• Always save report to /tmp/cve-analysis-{cve_id}-deep-analysis.md

Repository List (Server Foundation)

Common repositories to monitor:

• stolostron/ocm
• stolostron/clusterlifecycle-state-metrics
• stolostron/multicloud-operators-foundation
• stolostron/klusterlet-addon-controller
• stolostron/managed-serviceaccount
• stolostron/cluster-proxy-addon
• stolostron/cluster-proxy
• stolostron/managedcluster-import-controller
• stolostron/cluster-permission

When NOT to Use This Skill

This skill is for CVE monitoring and tracking only. Use other tools for:

• General security scanning → Use security tools
• Code vulnerability analysis → Use static analysis tools
• Dependency updates → Use Dependabot or similar
• Incident response → Use incident management processes