Fix get_project_vulnerabilities: CVE fields read from wrong response shape

[singhrohit90]

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.

[singhrohit90]

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.

[singhrohit90]

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.

[singhrohit90]

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.

[singhrohit90]

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.

[singhrohit90]

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.

[singhrohit90]

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.

[singhrohit90]

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.