Scanning images for vulnerabilities in Docker - Practice Problems & Coding Challenges

Challenge - 5 Problems

💻 Command Output

intermediate

Output of Docker image vulnerability scan using Trivy

You run the command trivy image alpine:3.18 to scan the Alpine Linux Docker image for vulnerabilities. What is the expected type of output you will see?

Docker

trivy image alpine:3.18

A A list of detected vulnerabilities with severity levels, package names, and fixed versions if available.

B A summary showing only the total number of layers in the image without vulnerability details.

C An error message stating 'image not found' because Alpine images cannot be scanned.

D A JSON output showing only the image size and creation date without any vulnerability info.

💡 Hint

Trivy scans images and reports vulnerabilities with details like severity and fixes.

Trivy scans container images and outputs detected vulnerabilities with details such as severity, affected packages, and fixed versions if available. It does not just show image metadata or layer counts.

🧠 Conceptual

intermediate

Understanding vulnerability scanning in CI/CD pipelines

Why is it important to include Docker image vulnerability scanning as part of a CI/CD pipeline?

A To detect and fix security issues early before deploying containers to production.

B To increase the build time significantly for better resource usage.

C To reduce the size of the Docker image by removing unused packages.

D To automatically update the base image without manual intervention.

💡 Hint

Think about security risks and deployment safety.

Including vulnerability scanning in CI/CD helps catch security problems early, preventing vulnerable containers from reaching production environments.

❓ Troubleshoot

advanced

Troubleshooting Trivy scan failure due to missing Docker daemon

You run trivy image myapp:latest on a server without Docker installed and get an error. What is the most likely cause?

Docker

trivy image myapp:latest

A The network connection is down, so Trivy cannot reach the vulnerability database.

B Trivy cannot find the Docker daemon to pull or inspect the image locally.

C Trivy requires root privileges to run the scan and you ran it as a normal user.

D The image name is invalid and Trivy cannot parse it.

💡 Hint

Trivy needs to access the image locally or remotely.

Without Docker installed or running, Trivy cannot pull or inspect local images, causing scan failures.

❓ Configuration

advanced

Configuring Trivy to ignore low severity vulnerabilities

Which Trivy command option correctly configures the scan to report only vulnerabilities with severity HIGH or CRITICAL?

A trivy image --severity-level HIGH,CRITICAL myapp:latest

B trivy image --ignore-severity LOW,MEDIUM myapp:latest

C trivy image --only-severity HIGH,CRITICAL myapp:latest

D trivy image --severity HIGH,CRITICAL myapp:latest

💡 Hint

Check Trivy's official option for severity filtering.

The correct option is --severity followed by a comma-separated list of severities to include in the report.

✅ Best Practice

expert

Best practice for scanning multi-stage Docker builds

In a multi-stage Dockerfile, which stage should you scan for vulnerabilities to ensure the final image is secure?

A Only scan the final stage image because it is the one deployed.

B Scan only the first stage since it contains the base OS.

C Scan all stages separately to catch vulnerabilities in build dependencies.

D Scanning is unnecessary for multi-stage builds as they are secure by default.

💡 Hint

Think about hidden vulnerabilities in build stages.

Scanning all stages helps detect vulnerabilities in build dependencies that might affect the build process or leak into the final image.

Practice

1. What is the primary purpose of running docker scan <image>?

easy

A. To find security vulnerabilities in the container image

B. To build the container image faster

C. To delete unused images from the system

D. To start a container from the image

Solution

1. Step 1: Understand the command purpose

   The docker scan <image> command is designed to analyze container images for security issues.

2. Step 2: Identify the correct use case

   It does not build, delete, or run images but scans them for vulnerabilities.

3. Final Answer:

   To find security vulnerabilities in the container image -> Option A

4. Quick Check:

   docker scan = vulnerability check [OK]

Hint: Scan images to catch security issues early [OK]

Common Mistakes:

• Confusing scanning with building images
• Thinking scan deletes images
• Assuming scan runs containers

2. Which of the following is the correct syntax to scan a Docker image named myapp:latest?

easy

A. docker scan -image myapp:latest

B. docker scan myapp:latest

C. docker scan --img myapp:latest

D. docker scan image=myapp:latest

Solution

1. Step 1: Recall the correct command syntax

   The correct syntax is docker scan <image-name> without extra flags.

2. Step 2: Verify options

   Options B, C, and D use incorrect flags or formats not supported by docker scan.

3. Final Answer:

   docker scan myapp:latest -> Option B

4. Quick Check:

   docker scan + image name = correct syntax [OK]

Hint: Use simple: docker scan image_name [OK]

Common Mistakes:

• Adding unsupported flags like -image or --img
• Using equal signs in command
• Misplacing image name

3. You run docker scan alpine:3.15 and get a report showing 2 vulnerabilities. What does this output mean?

medium

A. The scan failed and found no issues

B. The image is safe and has no vulnerabilities

C. The Alpine image has 2 known security issues to fix

D. The scan only checks for outdated packages, not vulnerabilities

Solution

1. Step 1: Interpret scan results

   The scan output listing 2 vulnerabilities means the image has 2 known security problems.

2. Step 2: Understand scan purpose

   Docker scan reports vulnerabilities, not just outdated packages or failures.

3. Final Answer:

   The Alpine image has 2 known security issues to fix -> Option C

4. Quick Check:

   Scan output = found vulnerabilities [OK]

Hint: Vulnerabilities count means issues found [OK]

Common Mistakes:

• Thinking vulnerabilities count means no issues
• Confusing scan failure with zero vulnerabilities
• Assuming scan only checks outdated packages

4. You tried docker scan myimage but got an error: ERROR: No such image: myimage. What is the likely cause?

medium

A. The image name must include a tag like ':latest'

B. The docker scan command is misspelled

C. Docker daemon is not running

D. The image 'myimage' is not present locally or in the registry

Solution

1. Step 1: Analyze error message

   The error says the image 'myimage' does not exist locally or remotely.

2. Step 2: Check common causes

   Misspelling or daemon issues cause different errors; tag is optional if 'latest' is default.

3. Final Answer:

   The image 'myimage' is not present locally or in the registry -> Option D

4. Quick Check:

   Image missing = error [OK]

Hint: Check image exists locally or remotely before scanning [OK]

Common Mistakes:

• Assuming scan command typo causes this error
• Thinking docker daemon stopped causes this error
• Believing tag is always required

5. You want to automate vulnerability scanning in your CI pipeline for image webapp:prod. Which approach is best?

hard

A. Add a step to run docker scan webapp:prod and fail if vulnerabilities found

B. Only scan images manually before deployment

C. Use docker build with a scan flag to auto-scan

D. Ignore scanning and rely on OS firewall for security

Solution

1. Step 1: Understand automation needs

   Automating scanning in CI means running docker scan during build or test steps.

2. Step 2: Evaluate options

   Manual scanning misses automation benefits; docker build has no scan flag; ignoring scanning is unsafe.

3. Final Answer:

   Add a step to run docker scan webapp:prod and fail if vulnerabilities found -> Option A

4. Quick Check:

   Automate scan + fail on issues = best practice [OK]

Hint: Automate scans in CI, fail on vulnerabilities [OK]

Common Mistakes:

• Skipping automation and scanning manually
• Expecting docker build to scan automatically
• Ignoring scanning for security