Skip to main content

Container vulnerability management for developers

Written by:
Aner Mazur
Aner Mazur
wordpress-sync/Container-Vulnerability-Management-For-Developers-small

June 28, 2018

0 mins read

Today Snyk released a container vulnerability management solution which empowers developers to fully own the security of their Dockerized application!

Containers are becoming the standard form in which applications are packaged and executed, so the need to protect not only the application itself but the entire container against open source vulnerabilities is growing. Snyk, being committed to helping developers secure their applications from open source vulnerabilities, is extending its support to Docker containers, with its unique developer first approach. The solution will seamlessly integrate with the various dev and runtime platforms throughout the SDLC - providing deep application analysis, automated vulnerability remediation, and our leading vulnerability database.

Easily scan for open source vulnerabilities

Container images are created and managed by developers, so Snyk created a simple CLI that will enable developers to both test images locally as well as integrate image validation into their CI/CD processes. It’s part of Snyk’s regular CLI, and released to all Enterprise customers. All you need to do is upgrade to the latest CLI version:

npm install -g snyk 
snyk auth

Snyk will scan all Operating System libraries installed by DEB, APK or RPM package managers, extract their exact versions, and test them against the most up to date version of our vulnerability database. To test a local Docker image, use the docker flag and point to the image name:

docker pull ubuntu:artful-20170601 
snyk test ubuntu:artful-20170601 --docker --org=my-team

This will result in displaying all detected operating system vulnerabilities.

✗ High severity vulnerability found on glibc/libc-bin@2.24-9ubuntu2
- desc: Privilege Escalation
- info: https://snyk.io/vuln/SNYK-LINUX-GLIBC-129450
- from: ubuntu@artful-20170601 > glibc/libc-bin@2.24-9ubuntu2
- fixed in: glibc/libc-bin@2.26-0ubuntu2.1

✗ Medium severity vulnerability found on libgcrypt20@1.7.6-1
- desc: CVE-2018-0495
- info: https://snyk.io/vuln/SNYK-LINUX-LIBGCRYPT20-104368
- from: ubuntu@artful-20170601 > util-linux/bsdutils@1:2.29-1ubuntu3 > systemd/libsystemd0@233-6ubuntu3 > libgcrypt20@1.7.6-1
- fixed in: libgcrypt20@1.7.8-2ubuntu1.1

✗ High severity vulnerability found on perl/perl-base@5.24.1-2ubuntu1
- desc: Buffer Overflow
- info: https://snyk.io/vuln/SNYK-LINUX-PERL-106304
- from: ubuntu@artful-20170601 > meta-common-packages@meta > perl/perl-base@5.24.1-2ubuntu1
- fixed in: perl/perl-base@5.26.0-8ubuntu1.1

To track a project for newly disclosed vulnerabilities through the Snyk UI, use the monitor command. You can use both snyk test and snyk monitor in your CI environments to bake security into your deployment pipeline.

Remediate vulnerabilities

One of Snyk’s key differentiators is empowering developers to not just find vulnerabilities, but actually fix them. For every vulnerability which has an upgradeable version for its library, which will fix the vulnerability, we will suggest the minimal version the user should upgrade to.

Looking at the first result of the snyk test run above, we see a privilege escalation vulnerability was found in libc-bin.

Clicking the link to the vulnerability page in Snyk, we can see that with this vulnerability a local attacker could exploit it to execute arbitrary code in setuid programs and gain root privileges. On top of that, multiple exploits exist for this vulnerability and are publicly available (in metasploit, exploit db, and the like), so this one will be of critical priority to fix.

wordpress-sync/docker-vuln-1

Understand library context

Snyk considers containers to be a different way to package an application, and approaches it with the same dev first angle we had before. This is evident in the great developer experience our CLI offers, but also in the application perspective. Instead of just saying we found a vulnerable component and leaving it to the developer to figure out “how did THAT library get there?”, we track the inclusion path of every vulnerable library (as seen in the ‘from’ line in the CLI results), making it far easier to understand the vulnerability in the context of the application - which is key for assessing exploitability but even more so for remediation.

Over time, you’ll see more capabilities around our container security that will help developers easily find and fix vulnerabilities, aligned with Snyk’s commitment to developer friendliness and remediation. So stay tuned :)