Snyk’s approach to container security research and relative importance

Container vulnerabilities are tricky things to deal with, requiring an understanding of both Linux security and container image architecture. Setting aside vulnerabilities that might occur in your code, most of the vulnerabilities that you deal with in containers relate to Linux operating system packages and their dependencies. And yet, containers are typically handled by developers, who generally are not experts in the art of operating system maintenance, and these packages don’t get patched the way you might patch a full operating system running on servers. We’re pleased to announce a new feature that helps take some of the mystery out prioritizing and fixing container vulnerabilities: relative importance.

Relative importance and data completeness in container security

Relative importance is a method by which our security team assesses the severity of vulnerabilities in container packages and if you have scanned any Debian or Ubuntu-based container images with Snyk Container you can already see these details today, and we’ll add this data for more distros soon. In short, relative importance takes the guidance of each distros maintainers and security researchers, and incorporates into the Snyk Container vulnerability assessment. This is important because Linux packages usually get a vulnerability rating from NVD but because each distro builds and maintains their releases in slightly different ways, an vulnerable package might have a different risk assessment from these maintainers. This is what we call the relative importance.

In the example below, you can see a container vulnerability where the original NVD rating for this vulnerability is HIGH severity; but the container in question uses Debian packages and because of the way Debian handles this package, the bash shell, in their distribution, the Debian maintainers classify the vulnerability as UNIMPORTANT, or low severity in Snyk’s ratings, which is reflected in our severity rating (top left) and also is used in calculating the priority score (321) shown to the right.

There is nothing you need to do to enable this new feature, it’s available in both the Snyk UI and CLI right now and Snyk Container automatically uses the most appropriate rating for the vulnerability. A trimmed version of the CLI JSON output is below, with severity, nvdSeverity, and relativeImportance all shown. 

If you’re interested in how these 3 fields work:

• relativeImportance – This is the severity rating assigned by the distro maintainers, assuming they have triaged it and assigned a rating. Snyk considers the distros to be the most accurate, so this is the severity you will see when it is available. However, distros vary in the number and types of vulnerabilities they triage, so if this data is not available we use nvdSeverity.
• nvdSeverity – This is the original NVD severity assigned to the vulnerability. This is the least accurate field, if a distro has triaged the vulnerability, and it’s generally useful only for organizations with very strict SLAs specifically based on NVD, or organizations where the CVSS score and severity must match. We display this data in the vulnerability report so that you know the context behind our displayed severity rating, and if there is no distro-specific rating this is the severity you will see.
• severity – This is the actual severity Snyk displays. If the vulnerability has been triaged by the distro and there is a relativeImportance rating, that’s what we will give you and severity will be equivalent to the relativeImportance. If the distro has not triaged the vulnerability, Snyk uses the nvdSeverity so you won’t miss on high and critical severity issues just because the distro hasn’t published their own data.

Mostly, we recommend sticking with the default severity field if you are using our APIs or the JSON output, because we do the work that allows us to provide the most accurate severity for your container image. The added fields allow you to have additional context to know why a particular severity and score differ. But we have definitely seen other customers with other needs that used those fields differently.

{
      "title": "Improper Check for Dropped Privileges",
      "credit": [
        ""
      ],
      "packageName": "bash",
      "language": "linux",
      "packageManager": "debian:9",
.
.
.
      "severity": "low",
      "cvssScore": 7.8,
      "CVSSv3": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:F",
      "nvdSeverity": "high",
      "relativeImportance": "unimportant",
      "from": [
        "docker-image|purpledobie/blog@demo",
        "[email protected]"
      ],
      "name": "bash",
      "version": "4.4-5"
}

A deeper look at Snyk’s research process for container vulnerabilities

This new relativeImportance data is an example of the hard work the Snyk security research team does, so that you don’t have to. When it comes to vulnerability research and making the security information useful to our customers, we evaluate ourselves on four factors:

• Completeness: going beyond a single source of vulnerability data and instead collating data from multiple sources and augmenting it with our own primary research
• Timeliness: quickly assembling all relevant data and making it available to our end users
• Accuracy: Low false positives and false positives are critical to avoid wasting time or missing important risk factors
• Actionability: Snyk is a solution used by both security teams and developers, but usually developers are ultimately the people responsible for fixing the issues we find. This is something we always take into account when we consider how we present our findings.

Dealing with container vulnerabilities involves understanding all the ins and out of the world of Linux and containers, bubbling up the information that is relevant to end users (usually developers), and making that information usable in the container build and maintenance process. At Snyk, our security research team handles this hard work so that you don’t have to. Because this topic comes up with our customers quite often as we discuss the process side of container security, we wanted to share what we think “good” looks like in the area of container security and how our security team tackles container research and we’re proud to release our new whitepaper on the topic.