Kubescape: Kubernetes Security Scanning for Manifests, Images, and Clusters

Your deployment applied cleanly, and kubectl get pods shows Running. But that same pod might be running as root, have no memory limit, and hold a service account token it never needed.

Kubernetes accepts it because the API server mainly checks whether your YAML is valid. Kubescape goes further, and it reads the same file, showing which security controls failed, and points out the lines that could give an attacker an advantage, even before the resource reaches the cluster.

Below, you’ll install Kubescape on Ubuntu and Rocky Linux, scan a manifest and the image it uses, understand the compliance score, let Kubescape write fixes back to your YAML, and set a threshold that fails a CI build instead of allowing a risky deployment to continue.

Tested on Ubuntu 26.04 and Rocky Linux 10 with Kubescape 4.0.9 against a Kubernetes 1.33 cluster. The commands work on any modern Linux distribution.

What Kubescape Actually Checks

Kubescape checks your Kubernetes resources using Open Policy Agent (OPA) and a library of security controls. Each control is a specific security check with an ID such as C-0016 or C-0017.

These controls are grouped into frameworks, so you can scan your workloads against NSA-CISA hardening guidance, MITRE ATT&CK techniques, or a CIS benchmark for your Kubernetes environment.

Kubescape can check your workloads at three different points. It can scan YAML files and Helm charts before you apply them, scan container images for CVEs using Grype, and scan a running Kubernetes cluster using your existing kubeconfig.

The last part is important. Kubescape connects to the Kubernetes API server using your credentials, so it can see the resources and information your account has permission to access.

1. Install Kubescape on Linux

The install script downloads the latest Kubescape binary and places it in your PATH. In most setups, you don’t need root privileges. If it can’t write to the installation directory, it may ask for sudo.

Here, sudo simply runs that installation step with administrator privileges.

On Ubuntu and Debian, you can install Kubescape from its PPA:

sudo add-apt-repository ppa:kubescape/kubescape
sudo apt update
sudo apt install kubescape

On RHEL and Rocky Linux, use the installation script:

curl -s https://raw.githubusercontent.com/kubescape/kubescape/master/install.sh | /bin/bash

The script also works on Ubuntu and is useful if you want to install a specific Kubescape release instead of the version currently available through the PPA.

After installation, check that Kubescape is available:

kubescape version

You should see output similar to:

Your current version is: v4.0.9

If you get command not found, the binary may have been installed under ~/.kubescape/bin but that directory is not yet in your PATH. Open a new shell or reload your shell profile, then run the version command again.

2. Scan a Manifest Before You Apply It

This is the scan that can save you from deploying a security problem. Point Kubescape at a directory of manifests, and it evaluates every resource inside without touching your Kubernetes cluster.

Throughout this article, anything in angle brackets like is a placeholder. Replace it with your actual path, including the brackets only when they are part of the command syntax.

kubescape scan /

Controls: 24 (Failed: 5, Passed: 17, Action Required: 2)

+----------+---------------------------------------+------------------+---------------+------------------+
| SEVERITY |             CONTROL NAME              | FAILED RESOURCES | ALL RESOURCES | COMPLIANCE SCORE |
+----------+---------------------------------------+------------------+---------------+------------------+
| High     | Resource limits                       |        1         |       1       |        0%        |
| High     | Allow privilege escalation            |        1         |       1       |        0%        |
| Medium   | Non-root containers                   |        1         |       1       |        0%        |
| Medium   | Automatic mapping of service account  |        1         |       1       |        0%        |
| Low      | Immutable container filesystem        |        1         |       1       |        0%        |
+----------+---------------------------------------+------------------+---------------+------------------+
|          |            RESOURCE SUMMARY           |        1         |       1       |      58.33%      |
+----------+---------------------------------------+------------------+---------------+------------------+

Compliance Score: 58.33%

Start with the Allow privilege escalation row. One resource failed this check, meaning a container in the manifest can gain more privileges than the process that started it. If an attacker compromises that application, this can give them a path to greater privileges on the node.

The Automatic mapping of service account failure is another one worth paying attention to. Kubernetes mounts a service account token into pods by default, so a container that never needs to talk to the Kubernetes API may still have a credential available.

The Compliance Score at the bottom is a weighted percentage across the controls, not simply the percentage of controls that passed. A score of 58.33% with five failed controls is a clear sign that the manifest needs attention before you deploy it.

Getting the Failing Line Number

The summary tells you which control failed. Add -v to see more details:

kubescape scan / --verbose

The verbose output shows the failing resource by kind and name, the relevant path inside the YAML, and the remediation guidance for that control. This is the output you can use when explaining the required fix in a pull request.

3. Scan the Image the Workload Pulls

A clean manifest that pulls an outdated base image can still leave you with a vulnerable deployment. Kubescape can scan container images directly, so you don’t need a Kubernetes cluster for this check.

kubescape scan image nginx:1.29

Image: nginx:1.29

Severity      Count
Critical        2
High           18
Medium         41
Low            96
Negligible     55

Vulnerabilities with available fixes: 63

The number to pay attention to is Vulnerabilities with available fixes: 63. These vulnerabilities already have patched package versions available, so rebuilding the image with a current base image may clear many of them without changing your application code.

The two Critical findings need more detail before you can decide what to do. Run the same command with -v, and Kubescape shows the CVE, affected package, and version that contains the fix.

4. Let Kubescape Fix the Manifest

Kubescape can write security fixes back into your YAML. It works in two steps because the fix command uses a results file instead of scanning the manifests again.

kubescape scan / --format json --output results.json
kubescape fix results.json --dry-run

Here’s what each part does:

• kubescape scan runs the same security checks as before.
• --format json saves the findings as machine-readable JSON instead of the summary table.
• --output results.json saves the results to a file that the fix command can read.
• kubescape fix applies the available remediations to the original manifest files.
• --dry-run shows the proposed changes without writing anything.

Always run the dry run first. Kubescape can edit your source YAML in place, and a fix such as adding readOnlyRootFilesystem: true could pass the security check but break a container that genuinely needs to write to the filesystem.

Once you’ve reviewed the proposed changes and the diff looks correct, run:

kubescape fix results.json

5. Scan the Running Cluster

Manifests show what you intended to deploy. The running cluster shows what’s actually there, including anything a colleague applied at 6pm on a Friday.

kubescape scan framework nsa --include-namespaces 

Scanning a specific namespace matters. A broad cluster scan can include kube-system, where control plane and system components may legitimately run with higher privileges. That can produce findings you don’t own or can’t change.

If you need a report that is easier to share with someone who doesn’t live in a terminal, use the HTML output:

kubescape scan framework nsa --format html --output cluster-report.html

6. Fail the Build When the Score Drops

The scan becomes really useful when it runs automatically, without someone having to remember to run it. Kubescape can exit with code 1 when the compliance score falls below your threshold, which is enough for a CI pipeline to stop the build.

/ --compliance-threshold 80 --format junit --output results.xml

Here’s what each part does:

• framework nsa scans against the NSA-CISA hardening controls, keeping the CI check focused and predictable.
• --compliance-threshold 80 makes the command exit with a non-zero status when the compliance score is below 80%.
• --format junit writes the results as JUnit XML, which CI systems such as Jenkins and GitLab CI can use as test reports.
• --output results.xml saves the report to the file your CI job can collect.

Start the threshold close to your current score, then raise it gradually. Setting it to 90% on day one will likely get the check disabled before the week is over.

Querying Scan Results with an AI Assistant

Kubescape 4 includes an MCP server that lets AI assistants access vulnerability and configuration scan results. Instead of searching through JSON manually, you can ask which workloads are affected by a specific CVE.

Start the MCP server with:

kubescape mcpserver

Where Kubescape Stops

Kubescape checks Kubernetes configuration and package metadata. It won’t tell you if your application is logging credentials, and it won’t catch a business logic flaw in your API.

The output format can also change between major versions. A --format json parser written for Kubescape 2 may not work with Kubescape 4. Pin the Kubescape version in CI, and check the release notes before upgrading.

Conclusion

You installed Kubescape, scanned a manifest before it reached the cluster, learned what the compliance score actually means, scanned the image your workload pulls, used kubescape fix to write corrections back into your YAML, and set a threshold that can fail a build instead of letting a security issue reach production.

Do this one thing right now: run kubescape scan / against the manifests you deployed most recently, and look at the high-severity findings first. Anything listed there may have been running in your cluster since the day you applied it.

What did your first scan return, and which control surprised you the most? Drop your compliance score in the comments and tell us which finding you fixed first.