Snyk Container meets Cloud Native Buildpacks: Cloud Native Application Security the right way

So you’re running microservices in containers? Congratulations! This is an important step towards meeting those business needs around delivering applications to the hands of your customers as soon as possible. But how can we mitigate any potential risks associated with faster software deployment? Simple, with Snyk.

Snyk Container in combination with a build tool creating OCI-compliant container images will help you mitigate that risk and focus on what really matters: a first-class customer experience. Let’s take a look at how it works.

The difference between Docker image and OCI-compliant images

To make sure that all container runtimes will run images produced by any build tool, the open source container community started the Open Container Initiative (OCI) to define industry standards around container image formats and runtimes. Given an OCI image, any container runtime that implements theOCI Runtime Specification can extract the image and run it in an isolated environment.

Odds are really good that you’ve heard of the company Docker and you might wonder what the difference is between OCI images and Docker images? The answer these days is “not much”. There are a few old Docker images here and there that predate the OCI specifications. Formally, those are known as Docker v1 specification formats and they are not compatible with the Docker v2 schema, which was donated to OCI and formed the basis for the OCI specs. But those v1 images date back to 2017. Today nearly every container registry, Kubernetes platform, and container runtime is built around the OCI specs. This includes the Docker engine, Docker Hub, and other Docker tools and products.

Why does any of this matter, you might wonder? Because the open specs have allowed other groups to come up with innovative ways to build containers and the fact they all end up building OCI-compliant images means you can run those images anywhere and security tools like Snyk Container can help you keep those images secure. Ultimately, you likely want development teams focusing on the core application code and not what the Dockerfile needs to look like, or spending hours on end verifying what open source libraries they should or shouldn’t be using,  or even combing through the 1000s of images tags on Docker Hub to figure out which base image to use. Let's take a look at one such method of building containers directly from source code: Cloud Native Buildpacks.

Cloud Native Buildpacks: From source code to containers in one step

Cloud Native Buildpacks (CNBs) transform your application source code into fully compliant OCI images that can run on any cloud and better yet they support all the popular programming languages. Container problem solved and all with control, compliance and maintainability!

If you’ve ever used Heroku, the Pivotal PaaS (now called VMware Tanzu Application Service) or the related open source Cloud Foundry, you’ve seen something similar to buildpacks. You simply push your code to those services, and they take care of packaging that code up in a suitable runtime object.CNBs bring that same experience to OCI images. A developer writes their code, and CNBs build all the app dependencies then packages everything needed by that app into a container image.

How Cloud Native Buildpacks work (from vmware Tanzu Developer Center)

Example

1$ pack build pasapples/pbs-demo-image:latest --builder paketobuildpacks/builder:base --publish --path ./target/springbootemployee-0.0.1-SNAPSHOT.jar

So what exactly are Cloud Native Buildpacks constructing?

Just like any image building tool, Cloud Native Buildpacks creates a set of filesystem layers that contain the runtime, your application and all of its dependencies as well as the metadata that the container engine uses to know how to start the application. Here’s the layer info for this example above by using docker image history command:

1$ docker image history pasapples/pbs-demo-image:latest
2IMAGE      CREATED    CREATED BY   SIZE  COMMENT
35d29940d2e52   41 years ago            68kB
4<missing>  41 years ago            46.3MB
5<missing>  41 years ago            10B
6<missing>  41 years ago            7.05MB
7<missing>  41 years ago            451kB
8<missing>  41 years ago            2.09MB
9<missing>  41 years ago            7.23MB
10<missing>  41 years ago            3.04MB
11<missing>  41 years ago            140MB
12<missing>  41 years ago            214B
13<missing>  41 years ago            6.69MB
14<missing>  41 years ago            2.27MB
15<missing>  41 years ago            398kB
16<missing>  41 years ago            6.51MB
17<missing>  41 years ago            7B
18<missing>  41 years ago            745B
19<missing>  41 years ago            987kB
20<missing>  41 years ago            63.2MB

If you are confused by the 41 years ago timestamp it has to do with allowing reproducible builds. Here you can find more information about the details: Time Travel with Pack

Using a tool called dive we can explore the layer contents in more detail. In the top left window of the screenshot below, we have selected the second to last layer in the image (the layers in dive are listed from bottom to top, whereas the layers in the output from the build above are in reverse). On the righthand side, we are inspecting the contents of that layer, which consists of JAR files from a Springboot application inside our OCI image. CNB handled putting all of this together for us based on our source code.

OCI container image security with Snyk Container

Snyk Container will find vulnerabilities in containers and Kubernetes workloads throughout the SDLC by scanning any compliant OCI image, including those created by Cloud Native Buildpacks or other build tools that create OCI images. But Snyk does more than just list out all the vulnerabilities present in your container: Snyk Container provides advice that helps you quickly build better, less vulnerable containers. And with our new and improved base image detection capabilities, we can provide the same level of advice that previously was only available when users included a Dockerfile!

Automated base image remediation with Snyk Container

Scale your security capabilities by enabling developers to quickly eliminate a multitude of vulnerabilities by upgrading to a more secure base image or rebuilding when the base image is outdated.

In the context of scanning those OCI images, Snyk can detect which base image your images are built upon and suggest base images that have few vulnerabilities, as shown below.

What base image could we use or have we updated recently for our OCI container?

These base image recommendations can be surfaced no matter how or where you scan your images in their lifecycle. The example above shows an image stored on Docker Hub, and below we’ve scanned an image using the Snyk CLI, which is also applicable to scanning in your CI pipelines.Snyk can suggest base images that have few vulnerabilities as shown below:

1$ snyk container test pasapples/pbs-demo-image
2
3Testing pasapples/pbs-demo-image...
4
5✗ High severity vulnerability found in openssl
6  Description: NULL Pointer Dereference
7  Info: https://snyk.io/vuln/SNYK-UBUNTU1804-OPENSSL-1089073
8  Introduced through: openssl@1.1.1-1ubuntu2.1~18.04.5, ca-certificates@20180409, openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
9  From: openssl@1.1.1-1ubuntu2.1~18.04.5
10  From: ca-certificates@20180409 > openssl@1.1.1-1ubuntu2.1~18.04.5
11  From: openssl/libssl1.1@1.1.1-1ubuntu2.1~18.04.5
12  and 1 more...
13  Fixed in: 1.1.1-1ubuntu2.1~18.04.9
14
15...
16
17Organization:  pas.apicella-41p
18Package manager:   deb
19Project name:  docker-image|pasapples/pbs-demo-image
20Docker image:  pasapples/pbs-demo-image
21Platform:      linux/amd64
22Base image:    ubuntu:bionic-20200403
23Licenses:      enabled
24
25Tested 93 dependencies for known issues, found 57 issues.
26
27Base Image          Vulnerabilities  Severity
28ubuntu:bionic-20200403  49           0 critical, 0 high, 16 medium, 33 low
29
30Recommendations for base image upgrade:
31
32Minor upgrades
33Base Image Vulnerabilities  Severity
34ubuntu:bionic  25           0 critical, 0 high, 3 medium, 22 low
35
36Major upgrades
37Base Image  Vulnerabilities  Severity
38ubuntu:rolling  17           0 critical, 0 high, 2 medium, 15 low

Application and container vulnerabilities together

You may not always have access to the original source code that runs in your containers, but vulnerabilities in your code dependencies are still important. Snyk can detect and monitor open source dependencies for popular languages as part of the container scan.

The base layer versus the open source dependencies clearly shown for a CNB OCI image.

Help developers focus on the vulnerabilities posing the highest risk

Snyk helps you easily focus attention on the highest priority issues instead of triaging hundreds of issues one-by-one. Ignore or exclude vulnerabilities from base images and use risk signals like exploit maturity and insecure workload configuration to help teams cut through the typical noise of container vulnerability reports.

Snyk Container is just one piece of the Snyk Cloud Native Application Security platform that's designed to help developers find and fix vulnerabilities in cloud native applications. Try it out today.