SnykLaunch recap: Custom Base Image Recommendations

One of the exciting new features discussed at SnykLaunch today was Custom Base Image Recommendations (CBIR). In open beta since late 2022, CBIR is already being used by several organizations. We've been expanding the feature set as we approach general availability to include more flexibility and to incorporate hands-off automation capabilities, allowing users to leverage CBIR in their CI/CD pipelines. 

Custom Base Image Recommendations extends the powerful base image recommendations at the core of Snyk Container, making recommendations available to organizations and enterprises that follow more advanced DevOps workflows. Whether you've got dedicated teams to select, build, customize, and harden your curated or "golden" base images, or you're simply starting from an image that's outside the popular official images, this feature is one you'll want to take advantage of.

While there are numerous workflows that you can follow to build and ship your containerized applications, there are some common high-level milestones: base image selection, the build step (adding common libraries, components, and project files), and deployment.

The need for base image recommendations

Base image selection often starts with a "Docker Official" image based on the programming language that a project's written in. For a Python app we'd look for a Python image, and for a Java app, a Java image. 

An important step in the delivery cycle for container images is making sure to minimize the risk from vulnerabilities. Many tools can help identify vulnerable packages in your images and will suggest fixed versions of vulnerable packages. For example, the node:14.0.0 base image contains over a thousand vulnerabilities. Unfortunately, many tools only provide per-vuln guidance, as seen here.

┌────────────────┬──────────────────┬──────────┬─────────────────────┬─────────────────────┐
│     Library    │  Vulnerability   │ Severity │  Installed Version  │    Fixed Version    │
├────────────────┼──────────────────┼──────────┼─────────────────────┼─────────────────────┤
│ apt            │ CVE-2020-27350   │ MEDIUM   │ 1.4.9               │ 1.4.11              │
│                ├──────────────────┤          │                     ├─────────────────────┤
│                │ CVE-2020-3810    │          │                     │ 1.4.10              │
│                ├──────────────────┼──────────┤                     ├─────────────────────┤
│                │ CVE-2011-3374    │ LOW      │                     │                     │
├────────────────┴──────────────────┴──────────┴─────────────────────┴─────────────────────┤
│ ...                                                                                      │
├────────────────┬──────────────────┬──────────┬─────────────────────┬─────────────────────┤
│ curl           │ CVE-2020-8286    │ HIGH     │ 7.52.1-5+deb9u10    │ 7.52.1-5+deb9u13    │
├────────────────┴──────────────────┴──────────┴─────────────────────┴─────────────────────┤
│ ...                                                                                      │
└──────────────────────────────────────────────────────────────────────────────────────────┘

In this example, we see versions that would fix some of the vulnerabilities, but it's not clear what we should do. Patch one? Patch them all?

Base image recommendations help you find better images to start from. Rather than patching single vulnerabilities, one at a time, you can eliminate full swaths of them with a single click. In this case, we see that a minor upgrade to node:14.21.3 will cut our vulns down by 64%, while a move to the bullseye-slim variant eliminates all but a handful of low-severity vulnerabilities.

Advanced DevOps workflows

While the application development team owns the process of building and maintaining container images in some organizations, others follow more advanced workflows. They rely on a division of labor, where a platform team builds internal curated or "golden" base images for their developers to use. The platform team selects the base image starting points, then configures and builds internal container base images to their corporate standards — which could include common libraries, adherence to naming or tagging conventions, and hardening to mitigate vulnerabilities in the base images.

This separation of responsibilities frees the developers up to focus on the applications that they're writing, since they don't need to fix the base images.

Let's walk through how this advanced flow works with CBIR.

Custom base image lifecycle

Platform and security teams

In this split responsibility model, the platform team owns the process of selecting the starting images and building the custom base images that the developers will use. They're responsible for automating and securing a scalable supply chain for container images for their developers to build from, while providing the security team full visibility into the status of the base images so they can prioritize fixes. This visibility provides a feedback loop, which allows the teams to ship more secure images. It's important to note that the platform team can still leverage standard base image recommendation logic when building their custom base images.

Once a custom base image is created it can be imported into Snyk for monitoring, using the same methods available previously: via the CLI, CI/CDs and API, or the Snyk UI. Once an image is being monitored by Snyk Container, it can be marked as a "Custom Base Image", and optionally be used in recommendations. Snyk can automatically detect newer versions based on semantic versioning, marking date, or custom schema naming patterns.

This process can also be automated via the API. Disabling the "Use in recommendations" flag is useful in scenarios where an image has been replaced by a different version, so you no longer want it to be offered as a replacement. 

Developer

When a container is derived or FROM a custom base image, recommendations are presented based on the image family, and — if the Dockerfile that built the image is included — one-click upgrade options are also available, as shown in this example. In this case, the developer is using mybaseimage:1.0, which has 185 vulns. The most recent, version 6.0, has fewer vulns, and the developer can quickly open a pull request to upgrade. Additionally, pull requests can automatically be created for images derived from custom base images when a newer base image version is released.

Using the curated, custom base images provided by the platform team eliminates the noise that developers need to sift through, allowing them to focus on the packages they've added to the containers — either manually or via package managers — as well as their application. The key is that they don't need to worry.

Automation for your container supply chain

As mentioned above, there are new APIs available for both the marking of monitored base images as custom base images, as well as registering custom versioning schemas for your container naming. This allows you to name your images in the manner that you're accustomed to, while still allowing custom recommendations. 

These APIs allow you to incorporate custom image tagging and custom base image recommendations in your automated workflows while providing your developers the ability to focus on delivering more secure software

You can also refer to our Custom Base Image Recommendations documentation to learn more about the feature itself.

Try it today!

Snyk Container's Custom Base Image Recommendations are currently available to customers on the Enterprise Tier, but should be available to other tiers (including the free tier) in the future. Prior to GA, reach out to your account manager, or raise a support ticket to enable the feature for your organization, and take control of your container supply chain workflows.

To see the demo first hand, check out the on-demand recording from SnykLaunch.