Skip to content

Fix get_project_vulnerabilities: CVE fields read from wrong response shape - #298

Open
singhrohit90 wants to merge 2 commits into
blackducksoftware:masterfrom
singhrohit90:fix/vulnerable-components-nested-fields
Open

Fix get_project_vulnerabilities: CVE fields read from wrong response shape#298
singhrohit90 wants to merge 2 commits into
blackducksoftware:masterfrom
singhrohit90:fix/vulnerable-components-nested-fields

Conversation

@singhrohit90

Copy link
Copy Markdown

Summary

get_project_vulnerabilities in blackduck/mcp_server.py always returns null for vulnerabilityName, severity, remediationStatus, and description, even when the project genuinely has vulnerable components.

Root cause

The vulnerable-components resource on BlackDuck (verified against a live 2025.7.1 instance) returns CVE/BDSA details nested under a vulnerability sub-object:

{
  "componentName": "ag-grid-community",
  "componentVersionName": "24.0.0",
  "vulnerability": {
    "vulnerabilityId": "CVE-2024-38996",
    "severity": "CRITICAL",
    "description": "...",
    "source": "NVD",
    "cweIds": ["CWE-1321"],
    "remediationStatus": "NEW"
  }
}

The current code reads these as flat top-level keys instead:

'vulnerabilityName': vuln.get('vulnerabilityName'),
'severity': vuln.get('severity'),
'baseScore': vuln.get('baseScore'),
'overallScore': vuln.get('overallScore'),
'remediationStatus': vuln.get('remediationStatus'),
'description': vuln.get('description', ''),
'publishedDate': vuln.get('publishedDate'),
'updatedDate': vuln.get('updatedDate')

None of vulnerabilityName, severity, remediationStatus, or description exist at the top level of this response, so they're always None. baseScore, overallScore, publishedDate, and updatedDate don't exist anywhere in this response shape at all (not nested either), so I dropped them rather than mapping them to something that doesn't exist — happy to add them back if there's a way to request a richer representation (e.g. a specific Accept media type) that includes CVSS scores.

Fix

Read from the nested vulnerability object, and expose the fields that are actually present (source, cweIds) instead of the nonexistent score/date fields.

Testing

  • Reproduced live against a real BlackDuck 2025.7.1 instance and confirmed the bug (all vuln entries came back with null fields for a project with 3,758 known vulnerable-BOM entries).
  • Added test/test_mcp_server_vulnerabilities.py with two unit tests (mocked Client, no network) covering the nested-object mapping and the missing-object fallback.
  • Verified the fix against the same live instance: real CVE IDs/severities now populate correctly (e.g. CVE-2024-39001 MEDIUM, BDSA-2025-35152 HIGH).
  • Ran the full existing suite (pytest test/) — all 44 tests pass, no regressions.

Note: the new test file guards its fastmcp import with pytest.importorskip since fastmcp isn't in requirements.lock.txt (it's the optional mcp extra) — so it skips cleanly rather than failing CI in environments without it installed, same as the existing CI config would experience today.

This is my first contribution to a public open-source project, so I'm very open to feedback on scope, style, or approach — happy to adjust.

rohising added 2 commits August 29, 2026 16:55
BlackDuck's vulnerable-components response nests CVE details under a
'vulnerability' sub-object (vulnerabilityId, severity, description,
source, cweIds, remediationStatus). The original mapping read these as
flat top-level keys plus baseScore/overallScore/publishedDate/updatedDate,
none of which exist in this response shape - every vuln entry came back
with severity/CVE fields all null.

Verified live: CVE-2024-39001 (MEDIUM), BDSA-2025-35152 (HIGH), etc. now
populate correctly for PathWave Analytics.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant