Two Hundred Findings and a Thursday Change Board

The 7 decommissioned-but-reachable hosts - unless any of them sits in the card data environment, in which case they are #1 for both risk and compliance.

Reasoning by (exploitability x blast radius x detectability):

• Root login on 41 hosts is highly exploitable only if an attacker is already past the MFA jump host - and that jump host is a compensating control that genuinely reduces likelihood. Still a PCI requirement breach, but a known, owned, monitored gap.
• NOPASSWD sudo for deploy matters only if the group is populated with interactive accounts and the command list is unrestricted - check before scoring it.
• Unpatched kernels in dev are low blast radius unless dev credentials reach prod - check for shared keys and trust relationships before accepting that boundary.
• The 7 hosts are the only finding that is unowned. Nobody patches them, nobody monitors them, they are outside change control and outside every scan, and they almost certainly still hold domain-joined machine accounts, SSH keys, and old application secrets. An intruder there is invisible. That is the definition of an uncontrolled risk.

First action item, not a scan finding: 'Identify owner of 7 reachable-but-decommissioned hosts; power off or rebuild within 5 business days.'

Check effective configuration, not text in a file.

• PermitRootLogin yes: sshd_config is evaluated top-down with Match blocks that override earlier directives. Run sshd -T | grep -i permitrootlogin (and sshd -T -C user=x,host=y,addr=z for match-specific cases) to get the value sshd actually applies. Also confirm AllowUsers/DenyUsers and whether root has a usable password hash at all - PermitRootLogin yes with prohibit-password semantics and a locked root account is a documentation finding, not a live exposure.
• NOPASSWD sudo for deploy: check group membership and the sudoers command list. If deploy has zero interactive logins and sudo is restricted to three restart commands, the finding is downgraded.
• World-readable /etc/shadow: verify on the host, not from the script cache - stat -c '%a %U:%G' /etc/shadow. Re-check a sample of three hosts manually before claiming all three.

Rule: anything you put in front of a change board must be reproducible with one command the server team can run themselves.

Collapse by control, then rank by risk, then attach effort. A 214-row spreadsheet gets deferred; five change packages get scheduled.

Structure:

1. One line per control theme, with count and percentage: 'SSH root login permitted - 41/60 hosts (68%) - PCI 2.2.7 - fix: config template + rolling restart - effort: 2 engineer-days - risk: low outage, restart only.'
2. Rank by risk, not by count. The 7 unowned hosts outrank 41 root-login configs even though it is one seventh the number.
3. State compensating controls explicitly in the same cell as the risk. Root login behind an MFA jump host with no internet exposure is still a finding - it is a PCI violation - but pretending it is tonight's emergency destroys your credibility on the 7 hosts that are.
4. Give each package a verification step the client can run to close the ticket.
5. Separate 'decision needed' from 'work needed.' Only two items need the board to decide anything: decommission date for the 7, and a maintenance window for the 12 kernel patches. The rest is execution.

Bring one page, five rows, and the raw 214 as an appendix.