Skip to content

Conversation

@ChrisEdwards
Copy link
Collaborator

@ChrisEdwards ChrisEdwards commented Nov 12, 2025

Rebased onto main after #31 (AIML-226) merged.


Summary

This PR adds application identification fields (appID and appName) to vulnerability responses, eliminating the need for users to perform additional API calls to determine which application owns a vulnerability.

Why

Problem: When listing vulnerabilities across an organization or filtering by various criteria, users received vulnerability data without any indication of which application each vulnerability belonged to. This forced users to either:

  1. Query vulnerabilities app-by-app to maintain context
  2. Make additional API calls to correlate vulnerability IDs back to applications
  3. Manually cross-reference vulnerability data with application lists

Impact: This created unnecessary complexity for AI agents and users trying to understand their security posture, especially when working with vulnerabilities across multiple applications.

What

Added two new fields to the VulnLight record:

  • appID: Application UUID that owns the vulnerability
  • appName: Human-readable application display name

These fields are now populated in all vulnerability listing tool responses:

  • list_all_vulnerabilities - Org-wide vulnerability queries
  • list_vulnerabilities - App-specific vulnerability queries
  • list_vulns_by_app_and_metadata - Session metadata filtered queries
  • list_vulns_by_app_latest_session - Latest session filtered queries

How

Technical Approach:

  1. Extended the VulnLight record (VulnLight.java:24-25) with appID and appName fields, including comprehensive JavaDoc
  2. Modified VulnerabilityMapper (VulnerabilityMapper.java:51-55) to safely extract application data from Trace objects, with null-safe handling
  3. Updated all vulnerability queries to request APPLICATION expansion via the Contrast SDK's TraceExpandValue.APPLICATION enum:
    • AssessService.java:201 - listVulnsByAppId()
    • AssessService.java:281 - listVulnsInAppByNameAndSessionMetadata()
    • AssessService.java:499 - getAllVulnerabilities()

Design Decision: Used the SDK's native expansion mechanism rather than performing separate lookups, ensuring efficient single-request retrieval of application context.

Code Walkthrough

1. VulnLight Record Enhancement (VulnLight.java)

public record VulnLight(
    String title,
    String type,
    String vulnID,
    String severity,
    String appID,        // NEW: Application UUID
    String appName,      // NEW: Application display name
    List<SessionMetadata> sessionMetadata,
    ...
)

Added comprehensive JavaDoc explaining all fields, making the record self-documenting for API consumers.

2. VulnerabilityMapper Changes (VulnerabilityMapper.java:49-66)

// Extract application info safely, handling null cases
String appId = null;
String appName = null;
if (trace.getApplication() != null) {
    appId = trace.getApplication().getId();
    appName = trace.getApplication().getName();
}

Null-safe extraction ensures backward compatibility if APPLICATION expansion is missing from a query.

3. Service Layer Updates (AssessService.java)

Added TraceExpandValue.APPLICATION to all three vulnerability query methods:

  • Line 201: listVulnsByAppId() - Already had SESSION_METADATA and SERVER_ENVIRONMENTS expand
  • Line 281: listVulnsInAppByNameAndSessionMetadata() - Added APPLICATION to SESSION_METADATA expand
  • Line 499: getAllVulnerabilities() - Added APPLICATION to existing SERVER_ENVIRONMENTS and SESSION_METADATA expand

This ensures the SDK includes application objects in the trace responses.

Testing

Unit Tests (VulnerabilityMapperTest.java):

  • toVulnLight_BasicTrace_TransformsCorrectly - Updated to verify appID and appName extraction (lines 64-66, 90-91)
  • toVulnLight_TraceWithNullApplication_HandlesGracefully - NEW test verifying null safety (lines 411-438)
  • toVulnLight_TraceWithApplication_ExtractsAppData - NEW test verifying correct extraction (lines 440-475)

Integration Tests (AssessServiceIntegrationTest.java):

  • ✅ Updated testListAllVulnerabilities() to assert appID and appName are non-null and non-empty (lines 202-206)
  • ✅ Enhanced output to display application context: "App: My App (app-123)" (line 207)

Test Results:

  • All 250 tests pass (unit + integration)
  • Build: ✅ SUCCESS
  • No regressions introduced

Manual Verification: Tested against live Contrast instance, confirmed appID and appName appear correctly in all vulnerability listing responses.

Benefits

  1. Improved User Experience: Users immediately see which application owns each vulnerability
  2. Reduced API Calls: No need for separate application lookup queries
  3. Better AI Agent Performance: AI can make informed decisions about vulnerabilities without additional context gathering
  4. Simplified Debugging: Developers can quickly identify app context when troubleshooting
  5. Backwards Compatible: Only adds new fields, no breaking changes to existing API contracts

Documentation Updates

Also includes comprehensive updates to CLAUDE.md:

  • Added stacked PR workflow documentation
  • Added coding standards (prefer var, use isEmpty())
  • Added detailed AI development workflow guidance
  • Added promotion workflow for stacked PRs to ready-for-review

These documentation changes improve the development process for all contributors working with AI assistance.


Related:

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds appID and appName fields to the VulnLight record, enabling direct correlation of vulnerabilities to their owning applications without requiring additional API calls. This enhancement improves usability for AI agents and users working with application-specific vulnerability tools.

Key Changes:

  • Added appID and appName fields to VulnLight record with comprehensive JavaDoc
  • Updated VulnerabilityMapper to safely extract application data from trace objects
  • Added APPLICATION expand parameter to all vulnerability query operations in AssessService

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
VulnLight.java Added appID and appName fields with detailed JavaDoc documentation
VulnerabilityMapper.java Added null-safe extraction of application ID and name from traces
AssessService.java Added APPLICATION expand to vulnerability queries
VulnerabilityMapperTest.java Added comprehensive unit tests for null and populated application cases
AssessServiceIntegrationTest.java Enhanced integration tests to verify application fields
CLAUDE.md Documentation updates for coding standards and AI workflow improvements

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@ChrisEdwards ChrisEdwards force-pushed the AIML-226-fix-tool-names-64-char-limit branch from fd0b642 to 8c62632 Compare November 14, 2025 04:35
ChrisEdwards and others added 5 commits November 13, 2025 23:55
Enables correlation of vulnerabilities to their owning applications by
including application identifiers in VulnLight objects returned by all
vulnerability listing tools.

Changes:
- Add appID and appName fields to VulnLight record with JavaDoc
- Update VulnerabilityMapper to extract application data from Trace
- Add APPLICATION expand to all vulnerability query operations
- Add unit tests for application field mapping (null and populated cases)
- Add integration test assertions verifying appID/appName presence
- All tests pass (250/250 unit + integration tests)

Benefits:
- Users can immediately identify which app owns each vulnerability
- Eliminates need to query all apps to find vulnerability ownership
- Simplifies testing and debugging of app-specific vulnerability tools
- Backwards compatible (new fields only, none removed)

Tools affected:
- list_all_vulnerabilities
- list_vulnerabilities
- list_vulns_by_app_and_metadata
- list_vulns_by_app_latest_session

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
Documents the process for creating draft PRs that depend on unmerged PRs
(stacked branches), including:
- Identifying the base PR
- Creating draft PR with proper configuration
- Required warning message format
- Verification steps
- Example command

Triggered by phrases like "ready for stacked PR" or "ready for draft review".

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
Documents Java coding conventions for the project:
- Prefer var for local variables when type is obvious
- Use isEmpty() instead of size() comparisons for collections

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
Document the complete workflow for promoting a draft stacked PR to ready-for-review
after its base PR has been merged to main.

Includes:
- Prerequisites and validation steps
- 10-step detailed workflow (verify, rebase, push, update, test)
- Full example commands from AIML-224 experience
- Common issues and troubleshooting guidance
- User experience phrases: 'move stacked PR to ready', 'promote stacked PR', etc.

This codifies the process used successfully for PR #25 (AIML-224).
Enhanced the workflow documentation to clarify stacked branch handling
and ensure consistent high-quality PR descriptions:

- Added Workflow Overview with decision tree and label definitions
- Clarified stacked-branch label usage for branches based on PR branches
- Created shared "Creating High-Quality PR Descriptions" section
- Updated "Moving to Review" for standard PRs (pr-created + in-review labels)
- Updated "Stacked PRs" workflow (pr-created label only, draft status)
- Enhanced "Promoting Stacked PR" to add in-review label on promotion
- Emphasized human review as bottleneck requiring effortless reviews

Key improvements:
- Consistent PR description quality across both workflows
- Clear label lifecycle (pr-created vs in-review timing)
- Stacked beads must depend on parent bead
- Both workflows reference shared description format

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>
@ChrisEdwards ChrisEdwards force-pushed the AIML-228-add-appid-appname-to-vulnlight branch from d8dc3e3 to 62909a8 Compare November 14, 2025 04:57
@ChrisEdwards ChrisEdwards changed the base branch from AIML-226-fix-tool-names-64-char-limit to main November 14, 2025 04:58
@ChrisEdwards ChrisEdwards marked this pull request as ready for review November 14, 2025 04:58
Copy link

@seschis seschis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm

@ChrisEdwards ChrisEdwards merged commit 4d33882 into main Nov 14, 2025
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.

4 participants