Fix get_project_vulnerabilities: CVE fields read from wrong response shape - #298
Open
singhrohit90 wants to merge 2 commits into
Open
Conversation
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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
get_project_vulnerabilitiesinblackduck/mcp_server.pyalways returnsnullforvulnerabilityName,severity,remediationStatus, anddescription, even when the project genuinely has vulnerable components.Root cause
The
vulnerable-componentsresource on BlackDuck (verified against a live 2025.7.1 instance) returns CVE/BDSA details nested under avulnerabilitysub-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:
None of
vulnerabilityName,severity,remediationStatus, ordescriptionexist at the top level of this response, so they're alwaysNone.baseScore,overallScore,publishedDate, andupdatedDatedon'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 specificAcceptmedia type) that includes CVSS scores.Fix
Read from the nested
vulnerabilityobject, and expose the fields that are actually present (source,cweIds) instead of the nonexistent score/date fields.Testing
test/test_mcp_server_vulnerabilities.pywith two unit tests (mockedClient, no network) covering the nested-object mapping and the missing-object fallback.CVE-2024-39001MEDIUM,BDSA-2025-35152HIGH).pytest test/) — all 44 tests pass, no regressions.Note: the new test file guards its
fastmcpimport withpytest.importorskipsincefastmcpisn't inrequirements.lock.txt(it's the optionalmcpextra) — 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.