Ask most people what security compliance work involves and they will describe the fixing. Run the scan, read the report, close the gaps, show the auditor a green dashboard. I spent two years building the engine that produces that report, and I can tell you the fixing is the easy half.
The hard half is deciding what a finding is.
A hardening guide is prose. Someone sat down and wrote, in English, what they wanted to be true about a system. Intent does not compile. Take a rule that says a service must not run with elevated privileges — one sentence, perfectly clear to a human reader. Now put it in an engine. Which services? Discovered how? On SLES, or on the Kubernetes distribution running above it, or on the node manager, because the answer is different on each. In what state — at boot, at steady state, during an upgrade window? And what do you do about the exceptions the platform itself ships with, which are legitimate and which the guide has never heard of?
I owned about fifty of the two hundred and seventy rules in that release, across three of those component types. Not one of them was a single sentence by the time it was code.
The two directions you can be wrong
Get it wrong one way and you flood the team with false positives. This is the failure people underestimate, because every individual false positive looks survivable. They are not survivable in aggregate. The team stops reading the report, and the moment that happens the engine is decorative. You are now running a very sophisticated program that produces a file nobody opens.
Get it wrong the other way and you have declared a system safe that is not. Nobody finds out. That is the whole problem with the second kind of wrong — there is no feedback signal at all, until there is, and by then it is somebody else's incident.
Two things I would tell anyone starting
Encode the exception next to the rule. The temptation is overwhelming to write the clean check first and deal with reality later, in a suppression list living somewhere else in the tree. I have seen what that file becomes. It ends up the least-reviewed and most load-bearing thing in the codebase, and no one will touch it because no one remembers which entries are still true. If a rule has a legitimate exception, the exception belongs beside the rule, with the reason written in prose next to it.
Validate against real systems, early, and keep doing it. A check that passes in a unit test and fails on a live cluster has taught you nothing except that you can write a unit test. We ended up validating across twenty virtual clusters before the first production release, and the gap between the code being right and the check being right closed only there. It never closed on my laptop.
Why this generalises
We replaced a monolithic codebase that had become genuinely difficult to maintain and got compliance scanning and remediation about ninety-five percent automated. The engineering was satisfying. But the lesson that has stayed with me is not about compliance at all.
A detection engine is trusted exactly as much as its false-positive rate allows, and not one percent more. That is true of alerting. It is true of static analysis. It is true of test suites everybody has learned to re-run until they go green. And it is becoming true, quickly, of AI-generated review — which produces findings at a volume no previous tool could, with a confidence that is not correlated to correctness.
Coverage is what you put in the release notes. Believability is what determines whether the thing you built does any good. Build the one people can afford to believe.