AIML-390: Add criticalVulnerabilities field to list_application_libraries response

[ChrisEdwards]

Rebased onto main after #78 merged.

---

Why This Change Exists

When using list_application_libraries, users could see totalVulnerabilities and highVulnerabilities counts, but had no way to distinguish CRITICAL severity CVEs from HIGH severity CVEs. This matters because:

• CRITICAL vulnerabilities require immediate attention
• HIGH vulnerabilities are serious but less urgent
• Without criticalVulnerabilities, users had to manually count CRITICAL CVEs from the vulnerabilities array

The Problem:

{
  "filename": "tomcat-embed-core-10.1.12.jar",
  "totalVulnerabilities": 16,
  "highVulnerabilities": 9,
  // No way to know how many are CRITICAL without parsing the array
}

TeamServer's API already returns critical_vulnerabilities, but the MCP server wasn't mapping it.

Approach We Chose

Add the missing criticalVulnerabilities field to LibraryExtended with proper Gson serialization annotation. This is a simple field mapping - no logic changes needed since TeamServer already provides the data.

Outcome of this Change

Users can now immediately see CRITICAL vs HIGH severity distribution:

{
  "filename": "tomcat-embed-core-10.1.12.jar",
  "totalVulnerabilities": 16,
  "criticalVulnerabilities": 4,   // ← NEW: 4 CRITICAL CVEs
  "highVulnerabilities": 9,        // Only HIGH, not CRITICAL
}

Verified with live data:

• tomcat-embed-core-10.1.12.jar: 4 CRITICAL, 9 HIGH, 3 MEDIUM = 16 total ✓
• spring-security-crypto-6.1.3.jar: 0 CRITICAL, 1 HIGH = 1 total ✓

---

The Chain of Logic

1. Discovery: The Missing Field

Investigation of TeamServer's library API revealed it returns critical_vulnerabilities:

GET /Contrast/api/ng/{orgId}/applications/{appId}/libraries?expand=vulns

{
  "file_name": "snakeyaml-1.33.jar",
  "total_vulnerabilities": 1,
  "critical_vulnerabilities": 1,
  "high_vulnerabilities": 0
}

But LibraryExtended.java only mapped totalVulnerabilities and highVulnerabilities.

2. Scope Decision

Found 14+ unmapped fields (licenses, tags, versions_behind, etc.). Decision: Keep this PR focused on just criticalVulnerabilities - the field users need most for security prioritization.

3. Implementation: Field Addition

Added the field with @SerializedName to map from API's snake_case:

@SerializedName("critical_vulnerabilities")
private int criticalVulnerabilities;

Lombok's @Data auto-generates the getter/setter.

4. Documentation Updates

Updated tool description so AI agents know the field exists, and clarified that highVulnerabilities counts only HIGH (not CRITICAL+HIGH as might be assumed).

---

What Changed

File	Change
LibraryExtended.java	Added criticalVulnerabilities field with @SerializedName
LibraryExtendedTest.java	Added test for getter/setter
AnonymousLibraryExtendedBuilder.java	Added builder support for tests
AnonymousLibraryExtendedBuilderTest.java	New test file for builder
ListApplicationLibrariesTool.java	Updated tool description with new field
list-application-libraries-manual-test.md	Documented field and updated examples

Key code change:

// LibraryExtended.java - added after highVulnerabilities
@SerializedName("critical_vulnerabilities")
private int criticalVulnerabilities;

---

Test Coverage

Unit Tests:

• LibraryExtendedTest.criticalVulnerabilities_should_be_settable_and_gettable - verifies field works
• AnonymousLibraryExtendedBuilderTest - 2 tests for builder support

Integration Tests:

• ListApplicationLibrariesToolIT - verifies field populated from live API

Manual Tests (passed):

• Test 4: Verified criticalVulnerabilities appears in response
• Test 5: Verified CRITICAL/HIGH counts match vulnerability array severities:
  • tomcat-embed-core: 4 CRITICAL CVEs matched criticalVulnerabilities: 4
  • 9 HIGH CVEs matched highVulnerabilities: 9

All 623 unit tests pass. Integration tests pass.

[ChrisEdwards]

Code review

No issues found. Checked for bugs and CLAUDE.md compliance.

🤖 Generated with Claude Code

[jason-at-contrast]

this looks good, but question: if we are already there and have the vulns and are just counting.. wondering if we should just put medium/low counts in there as well? We do have a couple of customers that are concerned with medium as well (because of their current security posture). if you think it would slow this down tremendously, then naw.. but would it be faster than to have them prompt again for medium/low counts?

[ChrisEdwards]

this looks good, but question: if we are already there and have the vulns and are just counting.. wondering if we should just put medium/low counts in there as well? We do have a couple of customers that are concerned with medium as well (because of their current security posture). if you think it would slow this down tremendously, then naw.. but would it be faster than to have them prompt again for medium/low counts?

@jason-at-contrast The medium counts are not provided by teamserver. Only high and critical are, so we would need to manually count the results to add those other metrics. I can add that in, but i need another PR. This one is getting too big with other code review suggestions that I have already implemented. I'll create another story and add this later. I need to get this release out.

The story for this is here: https://contrast.atlassian.net/browse/AIML-391