Kubescape vs Kube-bench vs KubeLinter in 2026: Kubernetes CI Hardening Scanners Compared
Kubescape, Kube-bench, and KubeLinter each cover a different slice of Kubernetes hardening. Here's what each catches, where they overlap, false-positive mutes, and the layered SARIF pipeline I'm running in production in 2026.
Kubescape, Kube-bench, and KubeLinter are the three open-source Kubernetes hardening scanners most teams reach for in 2026, and they solve different problems: Kube-bench audits the cluster control plane against the CIS Kubernetes Benchmark, Kubescape scans manifests and the running cluster against the NSA/CISA hardening guide plus CIS and MITRE ATT&CK, and KubeLinter is a static YAML linter that runs entirely at build time. In practice you want at least two of them wired into CI. Below I break down what each one catches, where they overlap, the false-positive traps, and the exact GitHub Actions and GitLab CI snippets I'm using in production this year.
Kube-bench tests the running cluster (nodes, kubelet, API server flags) against the CIS Kubernetes Benchmark 1.10 (June 2025). It runs as a DaemonSet or a one-shot Job.
Kubescape 3.x scans YAML, Helm charts, and live clusters against NSA/CISA, CIS, MITRE ATT&CK, and SOC 2 controls; it emits SARIF and posts inline PR comments.
KubeLinter is a static analyzer for Kubernetes YAML and Helm charts, no cluster required. It's the fastest of the three in CI (typically under 5 seconds) and catches Pod Security Standards violations before merge.
The three scanners overlap on Pod Security Standards but diverge on control plane checks (Kube-bench only), runtime posture (Kubescape only), and shift-left YAML linting (KubeLinter's strength).
Run KubeLinter on PRs, Kubescape on main, and Kube-bench in a nightly scheduled Job. This layered approach catches ~90% of common hardening drift without alert fatigue.
All three scanners produce SARIF output in 2026, so GitHub code scanning, GitLab Security Dashboard, or Sonarqube can dedupe findings across them.
Quick comparison table
Before we get into the details, here's the tl;dr matrix I keep taped to my monitor. It captures the dimensions that actually matter when you're picking a scanner (or combination) for a Linux-based Kubernetes environment in 2026.
Dimension
Kubescape 3.x
Kube-bench 0.10
KubeLinter 0.7
Maintainer
ARMO (CNCF Sandbox)
Aqua Security
Red Hat / StackRox
Frameworks covered
NSA/CISA, CIS, MITRE ATT&CK, SOC 2, PCI DSS
CIS Kubernetes Benchmark (1.10 as of 2026)
Pod Security Standards, custom rules via Rego-like YAML
Scans YAML/Helm at build time
Yes
No
Yes (primary use)
Scans running cluster
Yes (in-cluster or via kubeconfig)
Yes (DaemonSet or Job on each node)
No
Control plane / node checks
Partial (via kube-proxy config)
Full (kubelet, apiserver, etcd binaries)
None
Typical CI runtime
15–60 s (manifest scan)
N/A (nightly Job)
2–8 s
Output formats
JSON, SARIF, JUnit, PDF
JSON, JUnit, ASFF
JSON, SARIF, plain
License
Apache 2.0
Apache 2.0
Apache 2.0
# A single make target that runs all three in the right order:
.PHONY: k8s-scan
k8s-scan:
kube-linter lint deploy/ # 5 s, fast fail on manifests
kubescape scan framework nsa deploy/ --format sarif --output kubescape.sarif
# Kube-bench runs in-cluster via cronjob, not in local make
What is Kubescape and what does it catch?
Kubescape is a CNCF Sandbox project (originally from ARMO, promoted to Sandbox in 2022 and still maturing toward Incubating in 2026) that scans both YAML manifests and running clusters against multiple compliance frameworks. Where Kube-bench only cares about the CIS Benchmark and only against the control plane, Kubescape reads your deployments, statefulsets, and network policies and flags posture drift, things like runAsUser: 0, missing securityContext.readOnlyRootFilesystem, unrestricted network policies, or workloads that mount the host /proc. In my experience it's the single tool that gives you the widest coverage per invocation.
The killer feature for a DevSecOps engineer is the framework switch. You point it at the same manifests and get four different reports without re-writing rules:
# Scan against NSA/CISA Kubernetes Hardening Guidance (the default I recommend)
kubescape scan framework nsa deploy/ --format sarif --output nsa.sarif
# Same manifests, MITRE ATT&CK for Containers coverage
kubescape scan framework mitre deploy/ --format sarif --output mitre.sarif
# Compliance-focused: SOC 2
kubescape scan framework soc2 deploy/ --format json --output soc2.json
# All frameworks in one shot (useful for a security dashboard)
kubescape scan deploy/ --format json --output all.json --submit=false
Kubescape 3.0 (released late 2024) dropped the dependency on OPA/Rego and moved to a native Go rule engine, which cut scan times roughly in half. Version 3.5, current as of 2026, added attack-chains, a graph view that correlates findings into likely exploit paths (privileged container + hostPath mount + no network policy = "cluster takeover chain 4"). It also emits SARIF 2.1.0 that GitHub code scanning accepts natively, which is how I get inline PR annotations. If you're new to shift-left Kubernetes hardening, pair this with our container security on Linux guide for the runtime side.
# CI snippet: Kubescape as a GitHub Actions step with SARIF upload
- name: Kubescape (NSA framework)
uses: kubescape/[email protected]
with:
frameworks: nsa,mitre
files: "deploy/"
format: sarif
outputFile: kubescape.sarif
failThreshold: 7 # fail only on high/critical
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: kubescape.sarif
What is Kube-bench and is it still maintained?
Kube-bench is Aqua Security's CIS Kubernetes Benchmark auditor and it is very much still maintained. Release 0.10.7 shipped in August 2026 with support for the CIS Kubernetes Benchmark 1.10, and the project remains the reference implementation cited by CIS itself. Where Kubescape reads YAML, Kube-bench reads binaries and config files on the actual nodes: it inspects kube-apiserver flags, kubelet configuration, etcd file permissions (chmod 600 or tighter), and CNI plugin manifests. This is the layer that manifest-only scanners simply can't reach.
You have three deployment options, and the choice matters:
One-shot Job: Runs on one node, writes to stdout. Good for CI, useless for cluster-wide coverage.
DaemonSet: Runs on every node. This is what I use for continuous monitoring: pipe results into a nightly ConfigMap or ship to a SIEM.
Host binary: Download the tarball, run against the local node. Fastest for ad-hoc audits during incident response.
The output format matters if you're already piping SARIF everywhere else. Kube-bench emits JSON, JUnit, and AWS Security Finding Format (ASFF), but not SARIF natively. In 2026 the community kube-bench-sarif converter (a 40-line Python wrapper) is the accepted workaround; some teams have moved to running Kubescape's cluster framework instead, which duplicates about 70% of CIS control plane checks. I still prefer Kube-bench for the control plane. It's the gold-standard reference and CIS updates land there first.
KubeLinter, maintained by Red Hat's StackRox team, is a static analyzer that lints Kubernetes YAML and Helm charts without ever touching a cluster. That's its superpower and its limit. It has ~40 built-in checks (Pod Security Standards restricted profile, missing resource limits, host mount usage, non-root user enforcement, missing liveness probes), and it runs in 2–8 seconds on a typical repo. I use it as the pre-commit gate, hand-in-hand with our Linux CI/CD pipeline hardening guide.
Where KubeLinter shines over Kubescape's manifest scan is speed and rule authoring. Custom checks are declared in a single YAML file, so security teams can add "no image tag latest", "must use image digest", or "must reference our approved base image" without learning Rego:
# .kube-linter.yaml: enforce image digest pinning and non-root
customChecks:
- name: require-image-digest
description: Container images must use an sha256 digest, not a tag
remediation: Pin to sha256:... instead of :latest
scope: {objectKinds: [DeploymentLike]}
template: forbidden-annotation
params:
key: "spec.template.spec.containers[*].image"
pattern: ".*@sha256:.*"
checks:
addAllBuiltIn: true
exclude:
- "minimum-three-replicas" # ok for staging
- "unset-cpu-requirements" # we use LimitRange instead
KubeLinter's blind spot: it doesn't know what's actually deployed. If someone patches a Deployment out-of-band with kubectl edit, KubeLinter will happily green-light the manifest in git while the real cluster is compromised. That's exactly why you also need Kubescape scanning the live cluster and Kube-bench auditing nodes.
# CI snippet: KubeLinter as a pre-merge check with SARIF output
- name: KubeLinter
run: |
curl -sSfL https://github.com/stackrox/kube-linter/releases/download/0.7.4/kube-linter-linux.tar.gz \
| tar -xz -C /usr/local/bin
kube-linter lint deploy/ --format sarif > kubelinter.sarif || true
- uses: github/codeql-action/upload-sarif@v3
with:
sarif_file: kubelinter.sarif
category: kubelinter
Where the three scanners overlap
You will absolutely see the same finding reported by two or three of these tools. That's expected, and honestly the overlap is a feature, not a bug: a violation reported by two independent scanners is one you can trust and fix without second-guessing. But you also need a dedup strategy or your Jira board will look like a Christmas tree.
The overlap zones I've mapped after two years of running all three:
Pod Security Standards baseline and restricted: KubeLinter, Kubescape, and (partially) Kube-bench all check these. This is where deduplication matters most.
Container running as root: All three flag it. Use SARIF ruleId mapping to keep only one finding per manifest.
hostPath and hostNetwork usage: KubeLinter and Kubescape both catch it; Kube-bench doesn't touch workload manifests.
Missing NetworkPolicy: Kubescape checks for it; KubeLinter has an optional check. Neither replaces enforcement, so pair scanners with our Cilium network policies guide for the actual policy layer.
Kubelet flags: Kube-bench only.
etcd file permissions and TLS: Kube-bench only.
# Merge SARIF from three scanners into one dashboard view with GitHub CLI
gh api /repos/$REPO/code-scanning/alerts \
--paginate --jq '.[] | select(.rule.tags[]?=="security") | \
{tool: .tool.name, rule: .rule.id, path: .most_recent_instance.location.path}' \
| jq -s 'group_by(.path + .rule) | map({path: .[0].path, rule: .[0].rule, tools: [.[].tool]}) | \
.[] | select(.tools | length > 1)'
False positives and how I mute them
Every scanner cries wolf. My rule: mute at the config level, never in the scanner's CLI flags, so the exception is reviewable in git. Also add a comment explaining why. Future-you (or the person on-call at 3am) will thank you.
Common false-positive patterns and my playbook for each:
Kube-bench "manual" checks: A big chunk of CIS controls (e.g., 3.2.6 "Ensure that the --event-qps argument is set to 0 or a level which ensures appropriate event capture") require human judgment. Skip them in CI, review them quarterly against the NSA Kubernetes Hardening Guidance baseline.
Kubescape "workload has no network policy": If you enforce NetworkPolicy cluster-wide with a default-deny, this is a per-namespace decision. Add exceptions in kubescape/exceptions.json.
KubeLinter "unset-cpu-requirements": If you use LimitRange to set defaults, you don't need per-workload CPU requests. Add to the exclude: list with a comment.
Managed K8s API server flags: On EKS/GKE/AKS you cannot fix flags the provider hides. Use the platform-specific benchmark profile (mentioned in the Kube-bench section) or the finding is permanent noise.
Here's the pattern I've been running on ~40 clusters for the past year. It's built around the principle that fast checks happen before merge, slow checks happen after, and each stage produces SARIF so the security dashboard has a single view.
Pre-commit / PR: KubeLinter on changed YAML files. Fails the check in under 10 seconds.
Merge to main: Kubescape with NSA + MITRE frameworks against all manifests + Helm charts. Emits SARIF to GitHub Advanced Security.
Nightly: Kube-bench CronJob on every control-plane and worker node. Results shipped to a central bucket.
Weekly: Kubescape against the running cluster (posture drift check); catches out-of-band kubectl edit changes.
The most important thing I did was set a failThreshold that lets low/medium findings pass while blocking critical ones. Scanners that fail every PR because someone forgot a resource limit train engineers to click "override" on everything, which is worse than not scanning at all. For a broader look at pipeline hardening beyond scanning, see the Linux CI/CD pipeline hardening playbook.
Whichever combination you land on, the goal is the same: every misconfiguration has to fail a machine before it fails an auditor or an attacker. Wire the pipeline first, tune the exceptions second, and treat every ignored finding as a decision you'll defend at the next post-incident review.
Frequently Asked Questions
What is the difference between Kubescape and Kube-bench?
Kube-bench audits the actual cluster binaries and configs (kubelet, apiserver, etcd) against the CIS Kubernetes Benchmark. Kubescape scans YAML manifests and running workloads against NSA/CISA, CIS, MITRE ATT&CK, and other frameworks. They're complementary: Kube-bench for the control plane, Kubescape for workloads and posture.
Is kube-bench still maintained in 2026?
Yes. Aqua Security shipped Kube-bench 0.10.7 in August 2026 with support for CIS Kubernetes Benchmark 1.10 and updated EKS, GKE, and AKS profiles. It remains the reference implementation for CIS Kubernetes audits.
Does Kubescape replace Kyverno or Gatekeeper?
No. Kubescape is a scanner: it reports findings but doesn't block admission. Kyverno and Gatekeeper are admission controllers that enforce policy at deploy time. Use scanners to catch drift and inform policy; use admission controllers to enforce it.
Can KubeLinter scan Helm charts directly?
Yes. KubeLinter renders Helm charts internally before linting, so kube-linter lint charts/my-app/ works out of the box. For charts with required values.yaml overrides, pass them with --values values-prod.yaml.
Which scanner is best for EKS and GKE?
On managed Kubernetes, prefer Kubescape and KubeLinter. They focus on workloads, which is what you actually control. Run Kube-bench with the platform-specific benchmark profile (--benchmark eks-1.5.0 or gke-1.7.0) so it skips the control plane checks the cloud provider owns.
Netbird vs Tailscale vs Headscale for a self-hosted WireGuard mesh on Linux in 2026: ACLs, SSO, posture checks, hardening, and a no-downtime migration path.
Compare sudo-rs and run0 in 2026: install steps, polkit rules, the sudoers features sudo-rs drops, Ubuntu 25.10 defaults, and a CI-ready migration playbook.
