skills/snyk/studio-recipes/container-security

container-security

Installation
SKILL.md

Container Security Scanner

Guide for comprehensive container image security analysis, covering OS vulnerabilities, application dependencies, and Dockerfile best practices.

Core Principle: Secure containers from the base up - secure base image, minimal packages, no vulnerabilities.


Quick Start

1. Identify image to scan (local, registry, or archive)
2. Run snyk_container_scan with image name
3. Analyze results: OS packages + application deps
4. Provide remediation guidance
5. Optionally fix Dockerfile issues

Phase 1: Image Identification

Step 1.1: Parse User Input

Extract the image reference from the user's request (e.g., myapp:latest, nginx:1.25, gcr.io/project/app:v1, sha256:abc123..., or ./image.tar).

Step 1.2: Determine Scan Scope

Ask or infer:

  • App vulns: Include application dependencies? (default: yes for v1.1090.0+)
  • Base image: Separate base image vulns? (useful for understanding what you control)
  • Platform: For multi-arch images, which platform? (linux/amd64, linux/arm64)

Phase 2: Execute Scan

Step 2.1: Basic Scan

Invoke mcp_snyk_snyk_container_scan with:

  • image: the image name or path

Step 2.2: Advanced Scan Options

For more comprehensive analysis, invoke mcp_snyk_snyk_container_scan with:

  • image: the image name
  • file: path to Dockerfile (enables better remediation advice)
  • app_vulns: true (scan app dependencies)
  • severity_threshold: "high" (filter to high/critical only)

Step 2.3: Base Image Analysis

To isolate inherited vs. added vulnerabilities:

  1. Invoke mcp_snyk_snyk_container_scan with image and exclude_base_image_vulns: true — shows only vulnerabilities your layers added.
  2. Invoke again without that flag — shows the full picture including base OS.

Phase 3: Analyze Results

Step 3.1: Categorize Findings

Source Description Your Control
Base OS packages Installed by base image Change base image
Additional OS packages Installed via apt/yum Update or remove
App dependencies Node modules, Python packages Update versions
Dockerfile issues Misconfigurations Direct fix

Step 3.2: Generate Summary

## Container Scan Results: [image:tag]

### Overview
| Category | Critical | High | Medium | Low |
|----------|----------|------|--------|-----|
| OS Packages | X | Y | Z | W |
| App Dependencies | A | B | C | D |
| **Total** | X+A | Y+B | Z+C | W+D |

### Base Image Analysis
- **Base**: [base image detected]
- **Vulnerabilities from base**: [count]
- **Vulnerabilities you added**: [count]

### Top Priority Issues

| Severity | Package | Vulnerability | Fix Available |
|----------|---------|---------------|---------------|
| Critical | openssl | CVE-2024-XXXX | Yes - 3.0.12 |
| High | libcurl | CVE-2024-YYYY | Yes - 8.5.0 |

Step 3.3: Identify Fix Strategies

OS Packages: Update package in Dockerfile, upgrade base image, or use distroless/minimal base.

App Dependencies: Update in source manifest and rebuild image with updated dependencies.

No Fix Available: Document accepted risk, consider alternative package, or wait for upstream fix.


Phase 4: Remediation Guidance

Step 4.1: Base Image Upgrades

If base image has vulnerabilities:

## Base Image Recommendation

**Current**: node:16-alpine
**Vulnerabilities**: 15 (3 Critical, 5 High)

**Recommended**: node:20-alpine
**Vulnerabilities**: 2 (0 Critical, 1 High)

### Dockerfile Change
```dockerfile
# Before
FROM node:16-alpine

# After
FROM node:20-alpine

Migration Notes

  • Node 20 has breaking changes in [list]
  • Test thoroughly before deploying

### Step 4.2: Package Updates

For individual package vulnerabilities:

Package Fix: openssl

Current: 3.0.8 Vulnerable to: CVE-2024-XXXX (Critical) Fix Version: 3.0.12

Dockerfile Addition

# Add before your application layer
RUN apk update && apk upgrade openssl

### Step 4.3: Application Dependency Fixes

Application Dependency Fix

Package: lodash (via npm) Current: 4.17.15 Fix Version: 4.17.21

Steps

  1. Update package.json: "lodash": "^4.17.21"
  2. Rebuild image: docker build -t myapp:fixed .
  3. Verify fix: snyk container test myapp:fixed

### Step 4.4: Dockerfile Best Practices

Key improvements to recommend:

```dockerfile
# 1. Pin specific tags (not latest)
FROM node:20.10.0-alpine3.19

# 2. Run as non-root
RUN addgroup -g 1001 appgroup && \
    adduser -u 1001 -G appgroup -D appuser
USER appuser

# 3. Multi-stage builds (smaller image, fewer vulns)
FROM node:20 AS builder
WORKDIR /app
COPY . .
RUN npm ci && npm run build

FROM node:20-alpine
COPY --from=builder /app/dist /app
CMD ["node", "/app/index.js"]

# 4. Minimize packages
RUN apt-get install -y --no-install-recommends curl

Phase 5: Verification

Step 5.1: Rebuild Image

# Rebuild with no cache to ensure fresh packages
docker build --no-cache -t myapp:fixed .

Step 5.2: Re-scan

Invoke mcp_snyk_snyk_container_scan with:

  • image: myapp:fixed
  • file: ./Dockerfile

Step 5.3: Compare Results

## Fix Verification

| Metric | Before | After | Change |
|--------|--------|-------|--------|
| Critical | 3 | 0 | -3 ✅ |
| High | 5 | 1 | -4 ✅ |
| Medium | 12 | 8 | -4 ✅ |
| Total | 20 | 9 | -11 ✅ |

### Remaining Issues
- 1 High: No fix available upstream (document risk)
- 8 Medium: Low priority (schedule for next sprint)

End-to-End Example

User: "Scan my app:latest image and help me fix it."

Step 1 — Run the scan:

mcp_snyk_snyk_container_scan(image="app:latest", app_vulns=true)

Step 2 — Tool returns (example output):

{
  "summary": "Found 18 vulnerabilities (2 Critical, 6 High, 10 Medium)",
  "baseImage": "node:16-alpine",
  "vulnerabilities": [
    { "severity": "critical", "pkgName": "openssl", "version": "3.0.8",
      "fixedIn": "3.0.12", "id": "CVE-2024-0001" },
    { "severity": "high", "pkgName": "lodash", "version": "4.17.15",
      "fixedIn": "4.17.21", "id": "CVE-2021-23337" }
  ]
}

Step 3 — Deliver structured response:

## Scan Results: app:latest
Base image: node:16-alpine | 2 Critical · 6 High · 10 Medium

### Immediate Actions
1. Upgrade base image → node:20-alpine (eliminates ~14 vulns)
2. Pin openssl ≥ 3.0.12 in Dockerfile (CVE-2024-0001, Critical)
3. Update lodash to ^4.17.21 in package.json (CVE-2021-23337, High)

### Dockerfile patch
FROM node:20-alpine        # was node:16-alpine
RUN apk add --no-cache openssl>=3.0.12

Step 4 — After applying fixes, rebuild and re-scan to confirm resolution.


Common Scenarios

Scenario 1: "Scan my Docker image"

1. Invoke snyk_container_scan(image="app:latest")
2. Summarize findings by category
3. Recommend highest-priority fixes
4. Provide Dockerfile changes

Scenario 2: "Secure my Dockerfile"

1. Review Dockerfile for best practices
2. Build image if not already built
3. Invoke snyk_container_scan(image=..., file="./Dockerfile")
4. Combine scan results with Dockerfile review
5. Provide unified remediation

Scenario 3: "Find a more secure base image"

1. Identify current base image and vulnerabilities
2. Scan alternative base images
3. Compare vulnerability counts
4. Recommend best option with migration notes

Base Image Quick Reference

Runtime Recommended Base Notes
Node.js node:20-alpine Smallest, may lack some libs
Node.js node:20-slim Debian-based, more compatible
Python python:3.12-slim Good balance
Python python:3.12-alpine Smallest
Java eclipse-temurin:21-jre-alpine JRE only
Go gcr.io/distroless/static No shell, minimal attack surface
.NET mcr.microsoft.com/dotnet/aspnet:8.0-alpine Runtime only

Distroless options (gcr.io/distroless/): static (Go/Rust), base (most languages), java, nodejs — all offer minimal attack surface with no shell.


Error Handling

Error Solutions
Image not found locally docker pull <image> · check name spelling · verify registry access
Registry authentication required docker login <registry> · verify credentials and permissions
Scan timed out Retry · pull image locally first · scan a .tar archive instead

Constraints

  1. Scan before deploy: Never deploy unscanned images
  2. Pin versions: Use specific image tags, not latest
  3. Document exceptions: If vulnerabilities can't be fixed, document why
  4. Regular rescans: Images should be rescanned weekly for new CVEs
  5. Multi-stage builds: Prefer smaller production images
Weekly Installs
20
GitHub Stars
29
First Seen
Mar 29, 2026