4,812 Findings and a 72-Hour Audit Window

Ranking logic: exposure × exploitability × business impact, with CVSS as an input, not the answer.

1. Citrix gateway (CVSS 8.1). Internet-facing, public exploit, exploited in the wild. Highest real risk in the estate despite a lower score than the OpenSSL item. Patch and hunt for indicators of compromise - patching a box that has already been popped only hides the intrusion.
2. The 40 percent of unauthenticated Linux hosts. This is not a vulnerability but it invalidates the audit's evidence base. Fix the scan account (dedicated sudo-limited account or a scan agent) and rescan. Presenting banner-only data to an auditor invites a qualification on the whole report.
3. The OpenSSH 9.8 backport finding. It is probably not real, but it is on 200 servers and it is critical on paper, so it will dominate the audit meeting unless it is closed out with evidence.
4. Remaining criticals that are reachable from user or partner segments - these are the ones an attacker can chain.
5. OpenSSL 9.8 on the isolated lab VLAN. Lowest real priority. No route, no data, no path from the internet. Fix it on the normal patch cycle and record the isolation as the compensating control.

Say this out loud in the report: CVSS 9.8 on an unreachable host is a lower operational risk than CVSS 8.1 with a working exploit on the perimeter. Auditors accept that if you show the reasoning.

Both are evidence problems, and evidence beats argument.

Backport finding: banner-based scanners match version strings, and RHEL-family vendors ship a patched fix under an unchanged upstream version number. Resolution path:

• Check the vendor advisory for the CVE and identify the fixed package build (the release suffix, not the upstream version).
• Query the installed package with the package manager on a sample of hosts and compare build strings.
• Where available, use the vendor's own OVAL/vulnerability content in the scanner so it evaluates backports correctly.
• Record the result as a documented false positive with the package evidence attached, and note it in the scanner's exception list with an expiry date so it is re-evaluated next quarter.

The 40 percent: do not simply assert the hosts are fine.

• Create a least-privilege scan account with the specific sudo commands the checks require, or deploy an agent on hosts where sudo is politically impossible.
• Where neither is possible in 72 hours, label those hosts "assessment incomplete - banner-only" in the report, list them by name, and give a dated remediation plan.
• An auditor will accept a named, dated gap far more readily than an authenticated-scan claim you cannot substantiate.

Give a conditional answer with named dependencies - never a pass/fail prediction.

What you can say:

• "Of 61 criticals, N are genuine, exploitable, and reachable. Those are the ones that decide the outcome."
• "One high-severity internet-facing issue is under active exploitation and must be closed first, with compromise assessment."
• "Two categories of finding are documentation problems, not security problems: the backport false positive and the unauthenticated hosts. Both are closable within the window if we proceed today."

What you refuse to say:

• "You will pass." Auditors form their own view; promising an outcome you do not control is a credibility trap.
• "The 200 OpenSSH findings are false positives" before the package evidence is in hand. "Probably" is not a finding state.
• Any statement implying the unauthenticated hosts are clean. Absence of evidence from a banner scan is not evidence of absence.

The deliverable is a one-page risk statement: what is genuinely dangerous, what is closable before the window shuts, what will remain as a documented gap, and who owns each item. That answers the real question behind "will we pass" without manufacturing certainty.