Nine Compliance Specs Hidden in the Binary

trivy has a --compliance flag. The question that started this was simple: compliance with what, exactly? The flag takes a string, the string is a spec id, and knowing which ids exist turns out to be harder than it should be.

The probe

Feed it a value that cannot possibly be real and see what the binary says:

$ trivy image --compliance=NOPE poc/tc01:v1
FATAL Fatal error  flag error: unable to convert flags to options:
      unable to load compliance spec: unknown compliance : NOPE

The same probe against trivy k8s --compliance=NOPE --include-namespaces poc-imgsec and against trivy config --compliance=NOPE <dir> returns the identical fatal error, character for character. That is the first useful finding and it is not the headline one: all three subcommands accept --compliance, and all three validate it against the same loader. Compliance in Trivy is not a trivy k8s feature. It applies to image scans and to config scans too.

What the error does not do is enumerate the valid values. It refuses and exits. To get the list, we went to the binary itself and pulled the embedded spec ids out of it.

The nine compliance spec ids embedded in trivy 0.73.0 — cloud, host, and cluster, all shipped in the binary with no download step.

The nine

In trivy 0.73.0:

aws-cis-1.2
aws-cis-1.4
docker-cis-1.6.0
eks-cis-1.4
k8s-cis-1.23
k8s-nsa-1.0
k8s-pss-baseline-0.1
k8s-pss-restricted-0.1
rke2-cis-1.24

Read that list as three groups. Two AWS account-level CIS benchmarks and an EKS one. One Docker host CIS benchmark, docker-cis-1.6.0. And five cluster specs: Kubernetes CIS 1.23, the NSA/CISA hardening guidance at 1.0, RKE2 CIS 1.24, and both Pod Security Standards profiles — baseline and restricted — as 0.1 specs.

Why this matters more than a flag usually does

Two of those nine are k8s-pss-baseline-0.1 and k8s-pss-restricted-0.1. The Pod Security Standards are the same profiles Kubernetes enforces natively through Pod Security Admission. Which means the scanner you already run in CI can report on the exact profile the cluster can enforce for free — before you write a line of custom policy. That is the cheapest possible way to find out what a namespace would break on if you turned the label on.

The honest caveats belong here too. These are specs at the versions above, not at whatever version your auditor cites — k8s-cis-1.23 is pinned to a Kubernetes 1.23-era benchmark, and aws-cis-1.2 and 1.4 are both present precisely because the numbering matters to whoever is asking. A compliance report from a scanner is a mapping of findings onto controls, not an attestation. It tells you which controls have evidence against them today. It does not tell you that you passed an audit.

The general lesson

The reason nobody in this project knew these existed is that they are not in the obvious place. They are not a download, not a plugin, not a config file you populate — they are compiled in, and the flag that consumes them documents itself only by rejecting you.

When a tool takes an enum and the help text is vague, hand it garbage. The refusal path is documentation that nobody had to write, and it is usually more current than the documentation that somebody did.

Next: four of our six policies shouldn't be policies — where a built-in profile beats a webhook.