Prioritizing vulnerabilities in Kubernetes deployments

Snyk has recently introduced a Priority Score to help prioritize vulnerabilities we detect, helping you identify the most important issues that need your attention.

Prioritization and Snyk Container

The new Priority Score is fully supported in Snyk Container. All of your container images will be scored based on the severity of the vulnerability, data we have about available exploits and whether those issues have known fixes. This new capability makes it even easier for you to fix the most important issues across your teams.

Container images priority score in Snyk container

Extra information from Kubernetes

When it comes to Kubernetes, we have even more information available to us to help prioritize vulnerabilities. For Snyk customers who have been using our Kubernetes integration for a while, you are probably aware of the information we surface regarding how well the Kubernetes workloads (deployments, cronjobs, replicationcontrollers, etc.) are configured.

Snyk container identify your Kubernetes vulnerabilities

Kubernetes configuration is complicated, and a number of the options can lead to potential security issues.

We also have lots of data about the vulnerabilities themselves. The CVSS system has a vector (like AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:L) which encodes lots of information about the vulnerability and what is needed to exploit it. And CWE lists types of vulnerabilities in a structured manner.

Change the context, change the priority

In the Snyk Container Kubernetes integration we take this configuration information, and detailed vulnerability data, into account when calculating the Priority Score. A vulnerability present in a workload that is poorly configured scores higher than one in a well-configured one. A vulnerability that relies on elevated permissions will score lower compared to a well-configured workload that locks down capabilities and isn’t able to run as root. The changes can be small, but when considered across all of your workloads it can help make it easier to decide what to do first based on a simple risk calculation.

A vulnerability present in a workload that is poorly configured scores higher than one in a well-configured one.

The above score (of 639) relates to a vulnerability in a poorly-configured Kubernetes deployment. The vulnerability in question in this case can result in a denial of service attack. CPU and memory limits might not protect the individual container, but they can help mitigate the risk to the node and other related services. Let’s improve the configuration of our deployment:

spec:
  containers:
    - name: snykit
      image: garethr/snykit
      imagePullPolicy: IfNotPresent
      resources:
        limits:
          memory: 512Mi
          cpu: "1"

After we update our Kubernetes workload, Snyk will automatically detect the updated configuration. Here we can see both CPU and memory limits are now set.

Snyk container identify Kubernetes vulnerabilities

Because that marginally reduces the risk associated with this vulnerability we reduce the priority score.

Container images dynamic priority score in Snyk container

Container images dynamic priority score in Snyk container

The benefits of contextual prioritization

In Snyk, priority is relative. It’s less about an absolute value that’s meaningful for an individual vulnerability and more about helping you know what to do next with all of your vulnerabilities. CVSS in comparison is an absolute measure, it’s not changing based on your specific context. Both are useful for different purposes. When you are confronted by lots of vulnerabilities, and where you have lots of information about where those vulnerabilities reside in your systems, you can use the Snyk Priority Score to help determine the most important issues to address first.