feat(trivy_operator): add remediation, messages, category, and publishedDate mappings

[SergK]

Description

Add missing field mappings to the Trivy Operator parser.

1. Add remediation, messages, category to checks handler

The Trivy Operator Go source defines these fields on the Check struct:

type Check struct {
    ID          string   `json:"checkID"`
    Title       string   `json:"title,omitempty"`
    Description string   `json:"description,omitempty"`
    Severity    Severity `json:"severity"`
    Category    string   `json:"category,omitempty"`
    Messages    []string `json:"messages,omitempty"`
    Remediation string   `json:"remediation,omitempty"`
    Success     bool     `json:"success"`
}

The compliance_handler.py already maps remediation → Finding.mitigation, messages, and category from the same Check struct, but checks_handler.py (used by ConfigAuditReport, RbacAssessmentReport, InfraAssessmentReport) does not. This PR brings parity:

• check.remediation → Finding.mitigation
• check.messages → appended to Finding.description as **messages:**
• check.category → appended to Finding.description as **category:**

2. Add publishedDate to vulnerability handler

Trivy provides publishedDate on vulnerability findings. The existing vulnerabilityreport_extended.json test fixture already contains this field:

{
    "vulnerabilityID": "CVE-2024-0553",
    "publishedDate": "2024-01-16T12:15:45Z",
    ...
}

This maps it to Finding.publish_date (existing nullable DateField), with graceful handling of empty strings and malformed dates via contextlib.suppress(ValueError).

Test results

• Updated test_vulnerabilityreport_extended — verifies publish_date = date(2024, 1, 16) for first vuln, None for vulns with empty publishedDate
• Added test_configauditreport_with_remediation — verifies mitigation, category, and messages extraction
• All existing tests pass
• ruff check passes

Documentation

No documentation changes needed — additional field mappings for an existing parser.

Checklist

• Features/Changes should be submitted against the dev.
• Give a meaningful name to your PR, as it may end up being used in the release notes.
• Your code is flake8 compliant.
• Your code is python 3.13 compliant.
• Add applicable tests to the unit tests.
• Add the proper label to categorize your PR.

[valentijnscholten]

@SergK Thanks. Could you assess the possible impact on deduplication?

[SergK]

@valentijnscholten The Trivy Operator parser uses hash-code based deduplication. The hash is computed from title, severity, vulnerability_ids, description, and service.

For publishedDate and remediation — no dedup impact. Neither publish_date nor mitigation is part of the hash.

For messages and category appended to description — this does affect dedup, since description is part of the hash. ConfigAuditReport findings that have messages or category populated will get a richer description, which means a different hash on the next reimport. Those findings will show up as new, and the old ones will get auto-closed.

This is a one-time shift on the first reimport after upgrade. After that, the hashes stay stable. Worth noting that messages and category are already mapped the same way in compliance_handler.py — this PR just brings checks_handler.py to parity.

[Maffooch]

We are very sensitive about deduplication changes because we cannot guarantee that all users will read the release notes before upgrading. The least impacting breaking changes, the better. With that in mind, we should steer clear of updating the description when it is used in the dedupe hash codes

[mtesauro]

Approved