Skip to content

Vulnerability scanning with the Kubescape operator

The Kubescape operator includes a component which performs vulnerability scanning of all container images that are running in your cluster.

The Kubevuln component scans images which are deployed to the cluster when:

  • A new Deployment, StatefulSet, DaemonSet or naked Pod is created
  • The container image tag in an existing Deployment, StatefulSet, DaemonSet or Pod is changed

It uses the Grype engine to evaluate against a database of known vulnerabilities from a variety of publicly available vulnerability data sources. The sources include the security announcement data from all major Linux distributions, the National Vulnerability Database, and GitHub security advisories.

The results are made available in API objects exposed by the Kubescape storage engine.

Vulnerabilty summaries

For each running container, a VulnerabilityManifestSummary object will be created in the namespace. These are named for the method that the container is deployed.

Why do you need more than one object per container?

Kubescape's relevancy features consider usage of a container as part of its vulnerability profile. If code is not run during the inspection period, a component may be filtered from the vulnerabilty list. This means that the SBOM and number of relevant vulnerabilities for a container can vary depending on how it is deployed. Read more about vulnerability relevancy.

Here is an example VulnerabilityManifestSummary. You will see that the relevancy feature is not enabled, and a link to the full vulnerability manifest is provided.

kind: VulnerabilityManifestSummary
  annotations: nginx@sha256:6926dd802f40e5e7257fded83e0d8030039642e4e10c4a98a6478e9c6fe06153 "" wlid://cluster-docker-desktop/namespace-default/deployment-nginx-deployment nginx
  creationTimestamp: "2023-09-25T06:55:06Z"
  labels: non-filtered nginx-sha256-6926dd802f40e5e7257fded83e0d8030039642e4e10c4a98a6 nginx apps v1 nginx Deployment nginx-deployment default
  name: Deployment-nginx-deployment-nginx
  namespace: default
  resourceVersion: "1"
  uid: 056f6be1-ebb1-4026-89ef-a4d6d6a8bf54
      all: 0
      relevant: 0
      all: 4
      relevant: 0
      all: 4
      relevant: 0
      all: 27
      relevant: 0
      all: 72
      relevant: 0
      all: 6
      relevant: 0
      kind: vulnerabilitymanifests
      name: nginx-e06153
      namespace: default
      kind: ""
      name: ""
      namespace: ""
status: {}

Vulnerabilty manifests

The VulnerabilityManifest contains the full output of the vulnerability scanner, and lets you identify which vulnerabilities were detected in which files.

Relevancy filtering

Kubescape can examine the use of containers at runtime to suggest which vulnerabilities are most relevant. Learn about the relevancy feature.

Uploading scan results to a provider

If you have Kubescape configured to use a provider, then upon the completion of a scan, Kubevuln will send the results to that provider.


Scanning images pulled from private registries

To scan images that are pulled from private registries, you can define a Secret with credentials.


The secret must start with the name kubescape-registry-scan.

For example:

kind: Secret
apiVersion: v1
  name: kubescape-registry-scan-my-acr-secret
  namespace: kubescape
type: Opaque
  registriesAuth: |
        "registry": "",
        "username": "<username/clientID>",
        "password": "<password/secret>",
        "auth_method": "credentials"

Air-gapped installation support

It is possible to get image vulnerability results in an air-gapped mode, where you don't have access to download the Grype database.

When installing the Helm chart, add the following flag: --set grypeOfflineDB.enabled=true

Recurring image vulnerability scanning

The scanner is triggered by a CronJob called kubevuln-scheduler. By default, the scanner is triggered daily at midnight:

kubevulnScheduler.scanSchedule="0 0 * * *"` 

To customize the scan frequency, use --set kubevulnScheduler.scanSchedule when installing the Helm chart.