Scanner critical versus backported patch: triage under deadline

I would neither report a 9.8 on the scanner's version match alone nor dismiss it because my exploit failed. JBoss version strings often remain unchanged after backported patches, and a failed exploit can mean the payload, the endpoint or a WAF is wrong - not that the vulnerable class is absent. So I would gather behavioural evidence: request the specific vulnerable servlet path and inspect the response for the deserialization error signature; ask the sysadmin for the actual jar and class versions; confirm that the change ticket references the CVE and the affected class rather than a generic bundle; and, if permitted, test against a non-production clone. Until that evidence exists I would rate it 'unconfirmed - potentially critical' with a clearly stated verification gap. The ticket is good evidence but a ticket is a claim, not proof. Residual risk matters here because the host sits on the payment VLAN and may be reachable from internet-facing components. My recommendation would be to move to a supported version regardless of the backport, and to re-test after the next change window. Reporting it as confirmed critical would damage credibility when their team checks; silently dropping it would be a false negative.

Individually, default Tomcat manager credentials are often rated Medium. In this context that rating is wrong. The finding is not the credentials; it is that an authenticated deployment interface on the payment VLAN yields a service account that can read settlement database credentials. That is a path to the settlement system, and the environmental score should reflect confidentiality and integrity impact on that system plus the low complexity once the VLAN is reached. I would validate safely: log in, confirm the deployment role, read the config file only far enough to prove the exposure, and not connect to the database or extract records. Capture the manager page, the account name, and a redacted excerpt of the config. Then rate as Critical or High depending on whether the settlement database is reachable and whether the credentials are live - verify liveness in a controlled way with the client's consent, or state clearly that it was not verified. The chain is the finding: report it as one narrative with the Tomcat entry point, not two disconnected items. That changes remediation priority to disabling the manager, rotating the database credentials and reviewing the VLAN segmentation.

In the report: the JBoss item as 'unconfirmed, verification pending', with the evidence, the change ticket and the specific test needed to close it; the Tomcat-to-database chain as the top finding with a chain diagram, the entry point, the account, the credential exposure and the recommended actions; and the remaining 310 findings in a triaged table with status - confirmed, false positive, accepted risk, not tested. I would tell the client that the raw count of 312 is not a risk measure. Deduplication, confirmation and business context are what make the list actionable, and a scanner cannot do any of those. I would offer a walkthrough of the top 15 and deliver the rest as an appendix with a clear statement of which items were manually validated. I would also explain why the previous report 'found nothing real': version-based scanning produces both noise and blind spots, and a failed exploit is not evidence of absence. The deliverable states what I know, what I do not know, and what evidence would close the gap.