One panic shouldn't kill the scan: isolating rules with catch_unwind

Both good points.

The guard is in the app; it just wasn't in the article. Worth saying why it has to be a compile-time check rather than a test: Cargo builds test and bench targets with unwinding no matter what the profile says, because libtest needs to catch the panic to report the failure. So a test that asserts the scan survives a panicking rule passes even in a tree where a profile sets panic = "abort" and every guard is inert. The build is the only place that mistake is visible.

The visibility point is the one I would push further than you did. It isn't really a logging decision; it's about what the customer can conclude from the report. They're looking at a cost report to decide what to turn off. If rule 57 died on one EBS volume and all they see is no EBS finding, they conclude that volume is fine and move on. The report has quietly told them something false. A line naming the check and the resource turns that into a known gap they can act on, and for an air-gapped customer who can't just ask us, it's the difference between an incomplete answer and a wrong one.

The report can make that gap hard to miss by putting the denominator at the top: 91 of 92 rules completed. A clean-looking page with one rule missing then never reads as a full scan. If anyone consumes the output in a script or a pipeline, I'd also give a partial scan its own exit status rather than the clean one, so automation that only checks the exit code can't record it as nothing found.