Snyk for Docker and Container Images: Practical Guide

Why container security matters for every Docker user

Container images are one of the largest and most overlooked attack surfaces in modern software. A typical Node.js application image based on the default node:20 tag ships with over 800 installed OS packages, many of which carry known vulnerabilities that have nothing to do with your application code. The base image alone - before you install a single dependency - can contain dozens of high and critical CVEs.

The problem compounds as images move through the pipeline. Developers build images locally, push them to a registry, pull them in CI, deploy them to staging, and eventually run them in production. At no point in this chain does Docker itself verify that the packages inside the image are free of known security issues. That responsibility falls on the team, and without a dedicated scanning tool, most teams have no visibility into what their containers actually contain.

Snyk Container is the container security component of the Snyk developer security platform. It scans Docker images for OS-level and application-level vulnerabilities, analyzes Dockerfiles for misconfigurations, recommends less vulnerable base images, and integrates into CI/CD pipelines to catch issues before they reach production. Unlike standalone image scanners, Snyk Container connects scanning results to actionable remediation - telling you not just what is wrong but exactly how to fix it.

This guide covers everything you need to use Snyk for Docker container security in practice: scanning images from the CLI, analyzing Dockerfiles, interpreting base image recommendations, integrating with CI/CD pipelines, connecting private registries like Amazon ECR and Google Container Registry, and establishing container security best practices. If you have used Snyk for open-source dependency scanning or SAST but have not explored its container capabilities, this is where to start. For a broader overview of the platform, see our Snyk code review.

Getting started with snyk container test

The snyk container test command is the foundation of Snyk's Docker image scanning. It takes a container image reference as input, pulls the image (or uses a locally available one), analyzes every package in every layer, and reports known vulnerabilities.

Scanning a public image

To scan a public image from Docker Hub, run the command with the full image reference:

snyk container test node:20-alpine

This command pulls the node:20-alpine image if it is not already available locally, extracts the package manifests from each layer, and checks them against Snyk's vulnerability database. The output lists every vulnerability found, grouped by severity (critical, high, medium, low), with CVE identifiers, CVSS scores, and fix availability.

You can scan any public image from Docker Hub or other public registries:

snyk container test python:3.12-slim
snyk container test nginx:1.25
snyk container test ubuntu:22.04

Scanning a locally built image

For your own application images, build the image first and then scan it by its local tag:

docker build -t myapp:latest .
snyk container test myapp:latest

Snyk analyzes the final image - including your base image packages, any additional OS packages you installed via apt-get, apk, or yum, and application dependencies if manifest files are present in the image.

Filtering results by severity

In most real-world images, the total vulnerability count can be overwhelming. A standard Debian-based Node.js image might report 200+ vulnerabilities, many of which are low severity and unlikely to be exploitable. Use the --severity-threshold flag to filter the noise:

snyk container test myapp:latest --severity-threshold=high

This reports only high and critical vulnerabilities, which are the ones that require immediate attention. It is also the recommended setting for CI/CD pipeline gating - you want builds to fail on high and critical issues while allowing low and medium findings to be triaged separately.

Outputting results in different formats

Snyk supports several output formats for integration with other tools:

# JSON output for programmatic processing
snyk container test myapp:latest --json > results.json

# SARIF output for GitHub Security tab integration
snyk container test myapp:latest --sarif-file-output=snyk.sarif

# HTML output for human-readable reports
snyk container test myapp:latest --json | snyk-to-html > report.html

The JSON and SARIF formats are essential for CI/CD integrations where you need to process results programmatically or upload them to a security dashboard.

Dockerfile scanning and analysis

Scanning the image alone tells you about vulnerabilities in the packages that are already installed. Scanning the Dockerfile alongside the image tells you about how those packages got there and what you can do about it.

Adding Dockerfile context

Pass the --file flag to include Dockerfile analysis:

snyk container test myapp:latest --file=Dockerfile

This changes the output in two significant ways. First, Snyk maps each vulnerability back to the specific Dockerfile instruction that introduced it - whether it came from the base image FROM instruction or from a RUN apt-get install command you added. Second, Snyk generates base image upgrade recommendations (covered in the next section).

What Dockerfile issues does Snyk detect

Snyk's Dockerfile analysis goes beyond vulnerability scanning to check for configuration issues:

• Running as root - the Dockerfile does not include a USER instruction to switch to a non-root user before the CMD or ENTRYPOINT
• Using the latest tag - the FROM instruction uses latest or an unpinned tag instead of a specific version digest
• Missing HEALTHCHECK - the Dockerfile does not define a HEALTHCHECK instruction for container orchestration
• Unnecessary packages - apt-get install commands do not include --no-install-recommends, pulling in unnecessary packages that increase the attack surface
• ADD vs COPY - using ADD when COPY would suffice, since ADD can fetch remote URLs and auto-extract archives

These Dockerfile best-practice findings appear in a separate section of the output and help you harden your container beyond just patching vulnerable packages. For teams that want to enforce these practices in CI, combine Snyk Container with Snyk CI/CD pipeline integration to gate builds on both image vulnerabilities and Dockerfile issues.

Base image recommendations

One of Snyk Container's most useful features is its base image recommendation engine. When you scan with the --file=Dockerfile flag, Snyk does not just tell you your base image has vulnerabilities - it tells you exactly which alternative images would reduce your vulnerability count and by how much.

How recommendations work

Snyk analyzes your current base image and generates three categories of recommendations:

Minor version upgrade - same base image, newer patch version. For example, upgrading from node:20.10.0 to node:20.15.0. This is the lowest-risk change and typically resolves a meaningful number of vulnerabilities without breaking compatibility.

Major version upgrade - same base image distribution, newer major version. For example, upgrading from node:18-bullseye to node:20-bookworm. This resolves more vulnerabilities but may require application-level testing for breaking changes.

Alternative image - a different image distribution entirely. For example, switching from node:20-bullseye (Debian) to node:20-alpine (Alpine Linux). Alpine images are significantly smaller and typically contain far fewer vulnerabilities because they use musl libc and a minimal package set. However, Alpine can introduce compatibility issues with native modules that depend on glibc.

Interpreting recommendation output

When Snyk recommends a base image upgrade, the output looks something like this:

Base Image      Vulnerabilities  Severity
node:20-bullseye    187          23 critical, 45 high, 78 medium, 41 low

Recommendations:
Minor upgrades
  node:20.15.0-bullseye    152    (-35)
Major upgrades
  node:22-bookworm         98     (-89)
Alternative images
  node:20-alpine           12     (-175)

The numbers make the decision straightforward. In this example, switching to Alpine eliminates 175 vulnerabilities. The trade-off is that Alpine uses a different C library (musl instead of glibc), which can cause issues with certain native Node.js modules. If your application works on Alpine, it is almost always the right choice from a security perspective.

Acting on recommendations

To apply a base image recommendation, update the FROM instruction in your Dockerfile:

# Before
FROM node:20-bullseye

# After - switching to Alpine for significantly fewer vulnerabilities
FROM node:20-alpine

Then rebuild and rescan to verify the improvement:

docker build -t myapp:latest .
snyk container test myapp:latest --file=Dockerfile

This feedback loop - scan, review recommendations, upgrade, rescan - is the core workflow for reducing container vulnerabilities over time.

CI/CD container scanning

Scanning images locally during development catches issues early, but the real security value comes from gating your CI/CD pipeline so that vulnerable images never reach production. Snyk Container integrates with all major CI/CD platforms. For a broader guide on integrating Snyk across your entire pipeline, see Snyk CI/CD.

GitHub Actions integration

The most common CI/CD integration is GitHub Actions using the official snyk/actions/docker action:

name: Container Security Scan
on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  snyk-container:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build Docker image
        run: docker build -t myapp:${{ github.sha }} .

      - name: Run Snyk Container test
        uses: snyk/actions/docker@master
        env:
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
        with:
          image: myapp:${{ github.sha }}
          args: --file=Dockerfile --severity-threshold=high

      - name: Upload SARIF to GitHub Security
        if: always()
        uses: github/codeql-action/upload-sarif@v3
        with:
          sarif_file: snyk.sarif

This workflow builds the Docker image on every pull request, scans it with Snyk Container, and uploads the results to GitHub's Security tab. The --severity-threshold=high flag ensures the build fails only on high and critical vulnerabilities - medium and low findings are visible in the SARIF report but do not block the merge.

GitLab CI/CD integration

For GitLab, add a scanning stage to your .gitlab-ci.yml:

container-scan:
  stage: test
  image: docker:latest
  services:
    - docker:dind
  variables:
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - apk add --no-cache npm
    - npm install -g snyk
    - snyk auth $SNYK_TOKEN
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - snyk container test myapp:$CI_COMMIT_SHA --file=Dockerfile --severity-threshold=high
  allow_failure: false

Jenkins pipeline integration

For Jenkins, use the Snyk CLI directly in your pipeline script:

pipeline {
    agent any
    environment {
        SNYK_TOKEN = credentials('snyk-token')
    }
    stages {
        stage('Build') {
            steps {
                sh 'docker build -t myapp:${BUILD_NUMBER} .'
            }
        }
        stage('Container Scan') {
            steps {
                sh 'snyk container test myapp:${BUILD_NUMBER} --file=Dockerfile --severity-threshold=high'
            }
        }
    }
}

Setting the right severity threshold

Choosing the correct severity threshold for your CI/CD gate is critical. Set it too low and your pipeline breaks constantly on findings that are not exploitable. Set it too high and genuinely dangerous vulnerabilities slip through.

For most teams, --severity-threshold=high is the right starting point. This gates on high and critical vulnerabilities while allowing medium and low findings to be tracked and triaged separately. Teams with mature security programs can drop to --severity-threshold=medium once the initial backlog of findings has been addressed.

Docker Hub integration

Snyk integrates directly with Docker Hub to scan images stored in your Docker Hub repositories without requiring CLI access or CI/CD pipeline changes.

Configuring Docker Hub integration

1. Log in to the Snyk dashboard at app.snyk.io
2. Navigate to Integrations and select Docker Hub
3. Enter your Docker Hub username and an access token (generate one at hub.docker.com under Account Settings, then Security)
4. Click Save and then Add projects
5. Select the repositories you want Snyk to monitor

Once connected, Snyk scans your Docker Hub images on a recurring schedule and alerts you when new vulnerabilities are disclosed that affect packages in your images. You can also trigger on-demand scans from the dashboard.

What Docker Hub integration provides

The integration gives you continuous monitoring without any pipeline changes. Snyk scans each image tag you import and tracks it against new vulnerability disclosures. When a new CVE is published that affects a package in one of your monitored images, Snyk creates an alert with the severity, affected package, and remediation advice.

This is particularly valuable for images that are built infrequently but remain deployed for long periods. A base image that was clean when you built it three months ago may now have critical vulnerabilities that were disclosed after the build. Without continuous monitoring, you would not know until the next build - or worse, until an attacker exploits the vulnerability.

Scanning images in Amazon ECR and Google Container Registry

Production container images are rarely stored on Docker Hub. Most organizations use private registries like Amazon Elastic Container Registry (ECR), Google Container Registry (GCR), Google Artifact Registry, or Azure Container Registry (ACR). Snyk supports all of these.

Amazon ECR integration

To connect Snyk with Amazon ECR:

1. Create an IAM role in your AWS account with the AmazonEC2ContainerRegistryReadOnly managed policy
2. Add a trust relationship that allows Snyk's AWS account to assume the role
3. In the Snyk dashboard, go to Integrations, select Amazon ECR
4. Enter your AWS region and the IAM role ARN
5. Click Save and import the repositories you want to monitor

Snyk assumes the IAM role to pull images from ECR, scans them for vulnerabilities, and monitors them continuously. You can also scan ECR images from the CLI:

snyk container test <aws-account-id>.dkr.ecr.<region>.amazonaws.com/myapp:latest

This requires that your local AWS credentials have ECR pull permissions and that you have authenticated Docker with ECR using aws ecr get-login-password.

Google Container Registry and Artifact Registry

For GCR and Google Artifact Registry:

1. Create a Google service account with the Storage Object Viewer role for GCR or the Artifact Registry Reader role for Artifact Registry
2. Generate a JSON key for the service account
3. In the Snyk dashboard, go to Integrations, select Google Container Registry or Google Artifact Registry
4. Upload the service account JSON key
5. Import the repositories you want to monitor

CLI scanning works similarly:

snyk container test gcr.io/my-project/myapp:latest
snyk container test us-docker.pkg.dev/my-project/my-repo/myapp:latest

Azure Container Registry

For ACR, provide a service principal with the AcrPull role in the Snyk dashboard integration settings. CLI scanning requires authenticating Docker with ACR using az acr login.

Continuous monitoring with snyk container monitor

While snyk container test gives you a point-in-time scan, snyk container monitor provides ongoing visibility into your deployed images.

snyk container monitor myapp:latest --file=Dockerfile

This command uploads a snapshot of the image's package manifest to the Snyk dashboard. Snyk then continuously checks this snapshot against its vulnerability database and alerts you when new vulnerabilities are disclosed. This is essential for production images that may not be rebuilt for weeks or months.

Best practice is to run snyk container monitor in your deployment pipeline after a successful build and test:

# In your deployment pipeline
docker build -t myapp:$VERSION .
snyk container test myapp:$VERSION --file=Dockerfile --severity-threshold=high
# Only monitor if test passes
snyk container monitor myapp:$VERSION --file=Dockerfile --project-name=myapp-production

The --project-name flag organizes monitored images in the Snyk dashboard, making it easy to find and track specific applications.

Fixing container vulnerabilities in practice

Finding vulnerabilities is only useful if you can fix them. Snyk Container provides several remediation paths depending on the type of vulnerability.

Upgrading the base image

The single most effective action for reducing container vulnerabilities is upgrading your base image. Most vulnerabilities in container images come from outdated OS packages in the base image, not from your application code. Follow Snyk's base image recommendations to find the best upgrade path.

Updating OS packages

For vulnerabilities in OS packages that are not resolved by a base image upgrade, add explicit package updates to your Dockerfile:

FROM node:20-alpine

# Update OS packages to latest patched versions
RUN apk update && apk upgrade --no-cache

# Install your application
COPY package*.json ./
RUN npm ci --production
COPY . .

USER node
CMD ["node", "server.js"]

Using multi-stage builds

Multi-stage builds reduce the attack surface by separating build-time dependencies from runtime dependencies:

# Build stage - includes compilers, build tools, dev dependencies
FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

# Production stage - minimal runtime image
FROM node:20-alpine
WORKDIR /app
RUN apk update && apk upgrade --no-cache
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
COPY package*.json ./

USER node
CMD ["node", "dist/server.js"]

The production image only contains the compiled application and runtime dependencies. Build tools, compilers, test frameworks, and dev dependencies are left behind in the builder stage, which means fewer packages and fewer potential vulnerabilities.

Using distroless images

For the most aggressive vulnerability reduction, consider Google's distroless images. These images contain only your application and its runtime dependencies - no shell, no package manager, no other OS utilities:

FROM node:20-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci
COPY . .
RUN npm run build

FROM gcr.io/distroless/nodejs20-debian12
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
CMD ["dist/server.js"]

Distroless images typically have the fewest vulnerabilities of any base image option. The trade-off is that debugging running containers becomes harder without a shell or common utilities.

Snyk container security best practices

Based on working with Snyk Container across various projects and team sizes, here are the practices that deliver the most value.

Pin your base image versions. Never use the latest tag or an unqualified tag like node:20. Use specific digests or at minimum a full version tag like node:20.15.0-alpine3.20. This ensures reproducible builds and prevents surprise vulnerability introductions when a tag is updated.

Scan every PR, not just main. Configure your CI/CD pipeline to run snyk container test on every pull request, not just on pushes to the main branch. This catches vulnerability introductions at the point of change where they are easiest to fix.

Use Alpine or distroless base images. Debian and Ubuntu-based images carry hundreds of packages you do not need. Alpine and distroless images have a fraction of the attack surface. Switch to Alpine unless you have a specific glibc dependency that requires a Debian-based image.

Run as non-root. Always include a USER instruction in your Dockerfile before the CMD or ENTRYPOINT. Running containers as root means that any container escape vulnerability gives the attacker root access to the host.

Minimize layers and packages. Each RUN apt-get install adds packages and potential vulnerabilities. Use --no-install-recommends to avoid pulling in unnecessary dependencies. Combine related commands into a single RUN instruction to reduce layer count.

Monitor production images. Use snyk container monitor in your deployment pipeline so you get alerts when new vulnerabilities are disclosed that affect images already running in production.

Set severity thresholds in CI. Gate your pipeline on high and critical vulnerabilities. Tracking every low and medium finding in CI creates noise that leads teams to ignore all findings. Use the Snyk dashboard to triage medium and low issues on a regular cadence instead.

Rebuild images regularly. Even if your application code has not changed, rebuild images weekly or biweekly to pull in base image updates that patch newly disclosed vulnerabilities. Automate this with a scheduled CI pipeline.

Pricing considerations for container scanning

Snyk Container is included in all Snyk pricing tiers, but with different test limits:

• Free plan - 100 container tests per billing period
• Team plan - $25 per contributing developer per month with significantly higher limits
• Enterprise plan - custom pricing with unlimited or negotiated test limits

For detailed pricing information across all Snyk products, see our Snyk pricing breakdown.

The 100-test limit on the free plan can be restrictive for teams that scan images in CI/CD on every pull request. A team with five active repositories averaging five PRs per week would hit the limit in four weeks. If you are evaluating Snyk Container on the free tier, be mindful of this constraint and consider running scans only on merges to main during the evaluation period.

For teams exploring Snyk alternatives, Trivy is the most popular open-source alternative for container scanning - completely free with no test limits. See our Snyk vs Trivy comparison for a detailed breakdown of how they compare on detection accuracy, base image recommendations, and CI/CD integration.

Alternative: CodeAnt AI for infrastructure scanning

While Snyk Container focuses specifically on Docker image vulnerabilities, teams looking for broader infrastructure security may want to consider CodeAnt AI as a complementary or alternative tool. CodeAnt AI ($24-40 per user per month) provides IaC scanning capabilities that cover Terraform, Kubernetes manifests, CloudFormation templates, and Dockerfiles alongside its code review and static analysis features.

CodeAnt AI takes a different approach than Snyk by combining code quality analysis with infrastructure security scanning in a single platform. For teams that need Dockerfile best-practice enforcement and Kubernetes manifest scanning but do not require deep container image vulnerability analysis, CodeAnt AI can serve as a more cost-effective option. It integrates with GitHub, GitLab, and Bitbucket, and its IaC scanning catches many of the same misconfiguration patterns that Snyk IaC detects.

The ideal setup for teams with serious container security requirements is to use Snyk Container for image vulnerability scanning and base image recommendations alongside a tool like CodeAnt AI for broader infrastructure-as-code analysis. This gives you depth on the image security side and breadth on the infrastructure configuration side.

Wrapping up

Container security is not a one-time activity. New vulnerabilities are disclosed daily, base images are updated regularly, and your application dependencies change with every release. The teams that stay ahead of container vulnerabilities are the ones that automate scanning into their workflow and treat container security as a continuous process rather than a periodic audit.

Snyk Container makes this practical by integrating directly into the tools developers already use - the CLI, CI/CD pipelines, container registries, and the Snyk dashboard. The combination of image vulnerability scanning, Dockerfile analysis, base image recommendations, and continuous monitoring covers the full container security lifecycle from development to production.

Start with snyk container test on your most critical production image. Review the findings, apply the base image recommendations, and then integrate scanning into your CI/CD pipeline. Within a day, you can have automated container security gating that catches vulnerable images before they reach production.

For next steps, explore our guide on setting up Snyk from scratch if you have not installed the CLI yet, or dive into our Snyk CI/CD integration guide for more advanced pipeline configurations.

Further Reading

• Is Snyk Worth the Cost? Complete Pricing Breakdown for 2026
• What Is Snyk Code? Introduction to Snyk's SAST Tool in 2026
• Best AI Code Review Tools in 2026 - Expert Picks
• 13 Best Code Quality Tools in 2026 - Platforms, Linters, and Metrics
• I Reviewed 32 SAST Tools - Here Are the Ones Actually Worth Using (2026)

Frequently Asked Questions

How do I scan a Docker image with Snyk?

Run 'snyk container test ' to scan any Docker image for known vulnerabilities. For example, 'snyk container test node:20-alpine' scans the official Node.js Alpine image. You can scan images from Docker Hub, Amazon ECR, Google Container Registry, Azure Container Registry, or your local Docker daemon. If you want to include Dockerfile best-practice recommendations alongside the vulnerability scan, add the '--file=Dockerfile' flag. Snyk analyzes the OS packages in the image layers and cross-references them against its vulnerability database, returning results grouped by severity with CVE identifiers, fix availability, and suggested base image upgrades.

What is the difference between snyk container test and snyk container monitor?

The 'snyk container test' command performs a one-time scan and prints results to the terminal. It is designed for local development and CI/CD pipelines where you need immediate pass or fail output. The 'snyk container monitor' command uploads a snapshot of the image's dependency tree to the Snyk dashboard for ongoing monitoring. Snyk then continuously checks that snapshot against newly disclosed vulnerabilities and sends alerts when new issues are found that affect your image. Use 'snyk container test' for gating builds in CI and 'snyk container monitor' after successful deployments to track production images over time.

Does Snyk scan Dockerfiles for misconfigurations?

Yes. When you pass the '--file=Dockerfile' flag to 'snyk container test', Snyk analyzes the Dockerfile instructions alongside the image vulnerabilities. It checks for issues like running containers as root, using the latest tag instead of a pinned version, copying sensitive files into the image, missing HEALTHCHECK instructions, and unnecessary privilege escalation. These Dockerfile recommendations appear in a separate section of the scan output and help you follow container security best practices beyond just patching vulnerable packages.

How does Snyk recommend base image upgrades?

When you scan an image with 'snyk container test --file=Dockerfile', Snyk analyzes your current base image and suggests alternative base images that have fewer known vulnerabilities. Recommendations are grouped into three categories - minor upgrades (same major version, fewer vulnerabilities), major upgrades (newer major version, significantly fewer vulnerabilities), and alternative images (different distribution like switching from Debian to Alpine). Each recommendation shows the exact image tag, the number of vulnerabilities it would resolve, and the remaining vulnerability count, allowing you to make an informed decision about which upgrade path fits your compatibility requirements.

Can Snyk scan images in Amazon ECR or Google Container Registry?

Yes. Snyk supports scanning container images stored in Amazon ECR, Google Container Registry (GCR), Google Artifact Registry, Azure Container Registry (ACR), Docker Hub, JFrog Artifactory, Harbor, Quay, and GitHub Container Registry. For ECR, you configure the integration in the Snyk dashboard by providing an IAM role ARN with ECR read permissions. For GCR and Artifact Registry, you provide a Google service account key with the Storage Object Viewer role. Once configured, Snyk can import and continuously monitor images from these registries, scanning for new vulnerabilities as they are disclosed.

How do I integrate Snyk container scanning into GitHub Actions?

Create a workflow file that uses the 'snyk/actions/docker' action. Set your SNYK_TOKEN as a GitHub Actions secret. The action builds your Docker image and runs 'snyk container test' against it. You can configure severity thresholds to fail the build only for high or critical vulnerabilities using the '--severity-threshold=high' argument. For SARIF integration with GitHub's Security tab, add 'args: --sarif-file-output=snyk.sarif' and use the 'github/codeql-action/upload-sarif' action to upload the results. This gives you vulnerability findings directly in the GitHub Security dashboard alongside your pull request checks.

How many container tests does Snyk's free plan include?

Snyk's free plan includes 100 container tests per billing period. Each image scan counts as one test, whether you are scanning a local image, a Docker Hub image, or an image from a private registry. Tests on public open-source images do not count toward this limit. For teams running container scans in CI/CD pipelines on every pull request, 100 tests can be exhausted quickly - a team with 10 active repositories averaging 10 PRs per week would use the entire monthly allocation in one week. The Team plan at $25 per contributing developer per month raises this limit significantly.

What vulnerabilities does Snyk find in Docker images?

Snyk detects vulnerabilities in two main areas of a Docker image. First, it scans OS-level packages installed by the base image and any additional packages added via apt-get, apk, yum, or similar package managers. These include vulnerabilities in libraries like openssl, glibc, zlib, curl, and other system packages. Second, Snyk identifies application-level dependencies if application manifest files (package.json, requirements.txt, pom.xml, go.sum) are present within the image layers. Each finding includes the CVE identifier, CVSS score, severity rating, affected package version, and whether a fix is available.

How do I fix vulnerabilities found in my Docker images?

Snyk provides several remediation paths for container vulnerabilities. The most effective approach is upgrading your base image to a recommended alternative with fewer vulnerabilities - Snyk suggests these when you scan with the '--file=Dockerfile' flag. For OS-level package vulnerabilities, you can add 'RUN apt-get update && apt-get upgrade -y' (or the equivalent for your package manager) to your Dockerfile to pull in the latest patched versions. For application dependencies baked into the image, update the manifest files (package.json, requirements.txt) before building. You can also use multi-stage builds to reduce the attack surface by only including runtime dependencies in the final image.

Can Snyk scan Kubernetes manifests alongside container images?

Yes, but through a different product. Snyk Container handles image vulnerability scanning while Snyk IaC handles Kubernetes manifest scanning. You can run both in sequence: 'snyk container test myapp:latest' to scan the image, and 'snyk iac test k8s/' to scan your Kubernetes YAML files for misconfigurations. Snyk IaC checks Kubernetes manifests for issues like running containers as root, missing resource limits, using hostNetwork, exposing unnecessary ports, and missing security contexts. Together, the two products provide comprehensive container security from the image layer to the orchestration layer.

Does Snyk support scanning multi-stage Docker builds?

Yes. Snyk scans the final image produced by a multi-stage Docker build, which is the image that gets deployed. When you run 'snyk container test myapp:latest --file=Dockerfile', Snyk analyzes all layers of the final stage and identifies vulnerabilities in the packages present in the runtime image. Multi-stage builds are actually recommended as a security best practice because they allow you to separate build-time dependencies (compilers, build tools, test frameworks) from runtime dependencies, significantly reducing the attack surface and the number of vulnerabilities in your production image.

How does Snyk Docker scanning compare to Trivy?

Snyk and Trivy both scan container images for OS and application vulnerabilities, but they differ in key areas. Trivy is completely free and open source with no test limits, making it popular for teams that want unlimited scanning without cost concerns. Snyk's free plan is limited to 100 container tests per billing period. However, Snyk offers curated base image upgrade recommendations, a web dashboard for tracking vulnerabilities over time, automated fix pull requests, and registry integrations for continuous monitoring - features that Trivy does not provide. Snyk's vulnerability database is also independently curated with proprietary research, while Trivy relies on upstream advisory databases. For a detailed comparison, see our Snyk vs Trivy analysis.

---

Originally published at aicodereview.cc