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 the OCI 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.
$ 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:
$ docker image history pasapples/pbs-demo-image:latest IMAGE CREATED CREATED BY SIZE COMMENT 5d29940d2e52 41 years ago 68kB <missing> 41 years ago 46.3MB <missing> 41 years ago 10B <missing> 41 years ago 7.05MB <missing> 41 years ago 451kB <missing> 41 years ago 2.09MB <missing> 41 years ago 7.23MB <missing> 41 years ago 3.04MB <missing> 41 years ago 140MB <missing> 41 years ago 214B <missing> 41 years ago 6.69MB <missing> 41 years ago 2.27MB <missing> 41 years ago 398kB <missing> 41 years ago 6.51MB <missing> 41 years ago 7B <missing> 41 years ago 745B <missing> 41 years ago 987kB <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.
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:
$ snyk container test pasapples/pbs-demo-image Testing pasapples/pbs-demo-image... ✗ High severity vulnerability found in openssl Description: NULL Pointer Dereference Info: https://snyk.io/vuln/SNYK-UBUNTU1804-OPENSSL-1089073 Introduced through: email@example.com~18.04.5, ca-certificates@20180409, firstname.lastname@example.org~18.04.5 From: email@example.com~18.04.5 From: ca-certificates@20180409 > firstname.lastname@example.org~18.04.5 From: email@example.com~18.04.5 and 1 more... Fixed in: 1.1.1-1ubuntu2.1~18.04.9 ... Organization: pas.apicella-41p Package manager: deb Project name: docker-image|pasapples/pbs-demo-image Docker image: pasapples/pbs-demo-image Platform: linux/amd64 Base image: ubuntu:bionic-20200403 Licenses: enabled Tested 93 dependencies for known issues, found 57 issues. Base Image Vulnerabilities Severity ubuntu:bionic-20200403 49 0 critical, 0 high, 16 medium, 33 low Recommendations for base image upgrade: Minor upgrades Base Image Vulnerabilities Severity ubuntu:bionic 25 0 critical, 0 high, 3 medium, 22 low Major upgrades Base Image Vulnerabilities Severity ubuntu: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.
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.
Secure your cloud native applications with Snyk
Secure your cloud native applications, including the containers and IaC they run on.