CIS benchmarks are somebody else's checklist
On this page
Run a CIS benchmark against a Kubernetes cluster for the first time and you get a few hundred results, a percentage, and an uncomfortable feeling.
The percentage is the least useful number in the report, and chasing it is the most common way teams end up abandoning benchmarks entirely.
What a benchmark is
A benchmark is a checklist written by a committee, for a category of system, in the absence of any knowledge about yours. That is not a criticism but the only way a shared standard can work. The value comes precisely from it being external: a list you wrote yourself would omit the things you have not thought of, which is the entire reason to use somebody else's.
But it means a failed check has two possible meanings, and they look identical in the report.
You did not know
The benchmark just told you something useful, which is the reason to run somebody else's checklist rather than write your own.
You knew, and chose otherwise
A managed cluster whose provider owns the control plane fails control-plane checks forever. A workload that needs a hostPath mount fails that check every time. Neither is a defect, both are permanent, and both appear in every report you will ever run.
Why the percentage corrodes
Because the two categories are mixed, the score is meaningless the moment you have any deliberate exceptions, which is immediately.
What happens next is predictable. The number never reaches 100. Somebody asks why it is 78%. Somebody else explains that 15% is architectural and cannot change. The number is quietly stopped being reported, and with it goes the part that was useful: the checks that failed for the first time this month.
A benchmark is not an exam. Reading it as one guarantees you stop reading it.
The report worth having
There are only two lines in a benchmark run that anyone should act on:
What changed since last time
A check that passed last month and fails now is a regression, and it is the highest-value output of running a benchmark repeatedly. It is also invisible if you only ever look at the current score.
What nobody has decided about
The residue after you subtract the known exceptions. Not a number, a list, and usually a short one once the deliberate failures have been recorded as deliberate.
Everything else is either passing or already decided, and neither needs anyone's attention.
Deciding is the work
Getting to that report means doing the thing benchmarks are usually deployed to avoid: going through the failures once, properly, and recording a decision for each one you are not going to fix.
That record needs to survive the person who made it. A benchmark exception that says "N/A" is worthless in eighteen months; one that says which architectural fact makes it not apply, and who concluded that, is still useful when a new platform engineer asks. This is risk acceptance applied to a checklist, and it is the same discipline: an accepted item stays visible, marked, with a reason and an owner.
Do that once and the benchmark becomes a monitor rather than an audit.
Skip it and you have a percentage nobody trusts.
What is worth knowing about the tooling
Benchmark checks split into two kinds, and they have very different costs.
Answerable from the API
Is this admission controller enabled, do these pods run privileged, are there network policies. Cheap, safe, and possible from anywhere with credentials.
Only answerable on the node
File permissions on manifests, process arguments on the API server. These have to run on the control-plane node, which on managed Kubernetes you often cannot do at all. It is why so many reports carry a large could not assess section that readers take for failures.
Knowing which kind a check is tells you whether a failure is something you can fix, something your provider owns, or something the tool could not see. That distinction matters more than the score does.
Draugr's kubernetes control reads the cluster API natively by default, and can run kube-bench
for the node-level checks when you want them. Reporting a check it could not assess as an error
rather than as a pass, because "we did not look" and "it is fine" are not the same answer.
The CIS benchmarks guide covers what the benchmarks contain and how they are structured.