Skip to main content

Snyk Container registry security integrations extended to GitHub, GitLab, Nexus, DigitalOcean, and more

著者:
Danielle Inbar
Danielle Inbar

2021年9月23日

0 分で読めます

We’re excited to share that you can now use Snyk Container to scan container images stored in many more container registries. The latest additions include Github Container Registry, Nexus, DigitalOcean, GitLab Container Registry,and Google Artifact Registry. Those are in addition to the recently added Harbor and Quay, and our existing support for Docker Hub(also our exclusive first-party integration inside Docker Hub), Amazon Elastic Container Registry (ECR), Microsoft Azure Container Registry (ACR), JFrog Artifactory, and Google Cloud Registry (GCR; Google’s previous registry service).

Snyk Container helps you find and fix vulnerabilities in your container images and you can now import and monitor your container projects for vulnerabilities from a wider variety of sources in which your images may be stored.

wordpress-sync/blog-new-snyk-container-registries-tiles

Snyk monitors the projects you’ve imported from container registries for any known security vulnerabilities, including retesting at a frequency you control to catch any newly disclosed vulnerabilities that affect previously scanned images. Integration with all container registries (apart from Harbor) is available with any of our plans, including free Snyk accounts. (Note: if you have private container registries and require image scanning to occur inside your own environment, this capability requires the use of Snyk Broker, which is only available on paid plans)

wordpress-sync/blog-new-snyk-container-registries-projects

Snyk Container scan results for images stored in GitLab Container Registry, GitHub Container Registry, Harbor, and Nexus.

Use image scans from container registries to reduce vulnerabilities

Snyk Container identifies all the vulnerable packages in your container images, and to make fixing those issues more efficient, Snyk also identifies the parent image that your containers are built upon and provides alternate base images to help reduce the overall number of vulnerabilities in your container images. This capability is available throughout all of the new container registries integrations as well. Snyk Container can determine the base image you’re currently using and provide recommendations for upgrades with fewer vulnerabilities.

The following shows a Snyk Container scan result for an image that uses ruby:2.7.0 as its starting point (the FROM line in the Dockerfile). Snyk automatically detected the Ruby parent image and noted the vulnerabilities that are part of the Ruby image, then provides recommendations for newer or different Ruby images that will reduce the vulnerability count. In so doing, a developer does not have to sort through 551 individual vulnerabilities one by one, or even the 157 Critical and High severity vulnerabilities. Instead, by selecting one of the alternates — and testing to ensure compatibility — the number of vulnerabilities can be reduced by as much as 88% with just one change to the Dockerfile.

wordpress-sync/blog-new-snyk-container-registries-base-images

Snyk Container offers the different recommendations that are available based on your project, to enable you to control how you fix vulnerabilities:

  • Minor upgrades – with the general idea that smaller upgrades are faster and easier to use and less likely to break your build, these are minor upgrade recommendations, enabling you to keep the same major versions of the framework (node, in this example) and the same operating system distribution.

  • Major upgrades – require a move to a newer major version of the framework or operating system distribution.

  • Alternative upgrades – offer alternative suggestions for different images that can be used instead, but which may change both the framework and the distribution. While these alternative options may greatly reduce the number of vulnerabilities, as in the example above, they might also require more testing and consideration to ensure they don’t break your code.

Prioritizing container vulnerability fix efforts

Regardless of which container registry you use, after optimizing your base image, Snyk Container also helps in prioritizing which issues to focus your remediation efforts on. There are several lenses you can apply with Snyk:

  • If your container is running in a Kubernetes cluster, we can scan and monitor that running container and also use some of the workload configuration details to prioritize vulnerabilities that might be particularly risky due to insecure configurations. And Snyk Infrastructure as Code (Snyk IaC) will help you find and fix those insecure configurations at their source.

  • You can use Dockerfile context, which provides the ability to match vulnerabilities up to the instructions that introduce them to the container.

  • Snyk provides full dependency information to easily trace vulnerabilities back to their source package

  • Exploit maturity, social media chatter, and the presence of malicious packages are all clearly presented and used for prioritization, in addition to the standard severity and CVSS scoring.

  • Snyk provides details from Linux distribution maintainers that supersedes the more general NVD database details.

In the image below, for example, you can see Snyk’s built-in Priority Score indicating the importance of the issue while surfacing its risk elements, together with a few of the filters you can use to see only vulnerabilities you care about.

wordpress-sync/blog-new-snyk-container-registries-vulnerabilities

Get started with Snyk Container

All new container registry integrations are available today in Snyk Container. Most are available on any Snyk plan, including free plans, with the exception of privately hosted registries that require the use of Snyk Broker to connect. You can start scanning your container images by configuring the integration via API or directly from the Integrations page in your Snyk organization, and you’ll be ready to find and fix vulnerabilities in your container images.