fix: ignore withdrawn vulnerabilies

[ruromero]

User description

Fix #564

---

PR Type

Bug fix

---

Description

• Filter out vulnerabilities with withdrawn field

• Add test case for withdrawn vulnerability handling

• Prevent processing of withdrawn CVE records

---

Diagram Walkthrough

flowchart LR
  A["Trustify Response"] --> B["Check for withdrawn field"]
  B -->|withdrawn exists| C["Skip vulnerability"]
  B -->|no withdrawn field| D["Process normally"]
  D --> E["Return Issues"]
  C --> E

Loading

File Walkthrough

	Relevant files
Bug fix	TrustifyResponseHandler.java Skip withdrawn vulnerabilities in response processing        src/main/java/io/github/guacsec/trustifyda/integration/providers/trustify/TrustifyResponseHandler.java Added check to skip vulnerabilities with non-null withdrawn field Early return prevents processing of withdrawn CVE records Maintains existing status validation logic +3/-0
Tests	TrustifyResponseHandlerTest.java Add test case for withdrawn vulnerability filtering            src/test/java/io/github/guacsec/trustifyda/integration/providers/trustify/TrustifyResponseHandlerTest.java Added comprehensive test case with withdrawn vulnerability response Includes withdrawn CVE-2022-41948 with timestamp Tests alongside valid vulnerabilities CVE-2022-41946 and CVE-2024-1597 Validates that withdrawn vulnerabilities are properly filtered +134/-1

---

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
🟢	🎫 #564 🟢 Exclude vulnerabilities that are marked as withdrawn (i.e., have a withdrawn date/field) from the generated report/output.
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	✅ Filter withdrawn vulnerabilities within status Suggestion Impact: Added a check within the iteration over status.affected to skip entries that have a withdrawn field, preventing withdrawn affected items from being processed. code diff: affected.forEach( data -> { + if (data.hasNonNull("withdrawn")) { + return; + } var source = getSource(data); Filter out entries in the status.affected array that have a withdrawn field. This ensures that withdrawn vulnerability statuses are not processed, in addition to top-level withdrawn vulnerabilities. src/main/java/io/github/guacsec/trustifyda/integration/providers/trustify/TrustifyResponseHandler.java [107-139] details.forEach( vuln -> { if (vuln.hasNonNull("withdrawn")) { return; } var status = (ObjectNode) vuln.get("status"); if (status == null || !status.hasNonNull("affected")) { return; } var affected = (ArrayNode) status.get("affected"); if (affected.isEmpty()) { return; } + + ArrayNode nonWithdrawnAffected = new ObjectMapper().createArrayNode(); + affected.forEach( + a -> { + if (!a.hasNonNull("withdrawn")) { + nonWithdrawnAffected.add(a); + } + }); + + if (nonWithdrawnAffected.isEmpty()) { + return; + } + var cveId = vuln.get("identifier").asText(); var title = vuln.get("title").asText(); var description = vuln.get("description").asText(); var cwes = getCwes(vuln); var remediations = getRemediations(vuln); - var severities = getSeverities(affected); + var severities = getSeverities(nonWithdrawnAffected); issues.add( new Issue( getProviderName(exchange), cveId, title, description, severities, cwes, remediations)); }); [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 8 __ Why: This suggestion correctly identifies a potential issue where withdrawn entries within the status.affected array are not being filtered. While the PR handles top-level withdrawn vulnerabilities, this change makes the logic more robust by handling nested withdrawn statuses, which is a significant improvement to correctness.	Medium
General	Add debug logging for skips Add a debug log statement before skipping a withdrawn vulnerability. This will record the identifier of the ignored vulnerability, improving traceability. src/main/java/io/github/guacsec/trustifyda/integration/providers/trustify/TrustifyResponseHandler.java [109-111] if (vuln.hasNonNull("withdrawn")) { + logger.debug("Skipping withdrawn vulnerability: {}", vuln.path("identifier").asText()); return; } Apply / Chat Suggestion importance[1-10]: 4 __ Why: This suggestion improves maintainability by adding logging for skipped withdrawn vulnerabilities. This is good practice for traceability and debugging, but it is not a critical change.	Low
	Use for-loop with continue Replace the forEach loop with a traditional for loop. Use continue instead of return within the loop to skip withdrawn vulnerabilities, which can improve code clarity. src/main/java/io/github/guacsec/trustifyda/integration/providers/trustify/TrustifyResponseHandler.java [107-111] -details.forEach( - vuln -> { - if (vuln.hasNonNull("withdrawn")) { - return; - } +for (JsonNode vuln : details) { + if (vuln.hasNonNull("withdrawn")) { + continue; + } [To ensure code accuracy, apply this suggestion manually] Suggestion importance[1-10]: 2 __ Why: This is a stylistic suggestion that proposes replacing a forEach with a for loop for clarity. While valid, it's a matter of coding preference and offers only a minor improvement in readability with no functional change.	Low
Update