DockSec Series Part 3: How to Scan Dockerfiles, Images, and Compose Stacks for Security Vulnerabilities

Hands-on scanning tools are closing the gap between finding container vulnerabilities and actually fixing them — and DockSec's latest tutorial shows exactly how.

The third installment of the DockSec Series, published July 21, 2026, by Advait Patel on SecureWorld, moves beyond theory and into practice. The guide walks security engineers and DevOps teams through installing DockSec and executing real scans across Dockerfiles, built images, and full Docker Compose stacks. With container security remaining one of the most exploited attack surfaces in modern infrastructure, this hands-on breakdown arrives at a critical moment for teams trying to operationalize vulnerability management. Understanding why cybersecurity matters for modern infrastructure is essential context before diving into the tooling itself.

Setting Up DockSec and Understanding What It Scans

DockSec is available on PyPI and requires two external scanners to function at full capacity. Hadolint handles Dockerfile linting while Trivy manages vulnerability scanning. Docker is required for image scans and Docker Scout is used when present. Notably, DockSec can install those external scanners automatically, lowering the barrier for teams without dedicated tooling infrastructure.

To demonstrate real-world value, the guide introduces a deliberately vulnerable Dockerfile designed to commit several common security sins simultaneously. That Dockerfile includes:

• An unpinned base image
• Two hardcoded secrets
• Use of ADD instead of COPY
• An exposed SSH server on port 22
• No non-root user
• No health check

This is the container equivalent of broadcasting an open invitation for attackers — a controlled but recognizable recreation of mistakes that appear regularly in production codebases. The tutorial uses this flawed file as a testing environment, making the scan output immediately interpretable for readers who recognize these patterns from their own work.

Why Realistic Test Cases Matter

Using a purposefully broken Dockerfile rather than a sanitized example is a deliberate pedagogical choice. It forces the scanner output to surface findings that map directly to real misconfigurations, rather than edge cases that rarely appear in practice. Readers can cross-reference findings against their own Dockerfiles with confidence that the tool has been stress-tested against recognizable problems.

Scan Modes: From Fast CI Checks to AI-Powered Analysis

DockSec offers multiple scanning modes depending on the environment and level of detail required.

The --scan-only Flag

The --scan-only flag delivers the fastest useful output. It runs Hadolint, prints lint issues with file and line numbers, computes a local security score, and ends with a consolidated summary. That summary includes a severity table, a score rated from POOR to EXCELLENT, a "quick take" action block, and a suggested next command. No API key or AI model is required in this mode, making it the go-to option for fast continuous integration paths and locked-down environments.

The scoring system is deliberately unforgiving in the right places. Hardcoded secrets alone cap the overall score rather than being averaged into a misleadingly moderate number. A Dockerfile carrying exposed credentials will land firmly in the "POOR" category regardless of what else it gets right — which is the correct behaviour. A tool that softens the severity of exposed credentials through score averaging would actively mislead the teams relying on it.

AI-Powered Analysis

For teams that want plain-English explanations and line-level fixes, DockSec supports AI-powered analysis through OpenAI, Anthropic, Google, and Ollama. With a provider key configured, the output leads with an AI analysis section grouped into:

• Vulnerabilities
• Best practices
• Security risks
• Exposed credentials
• Remediation steps

Rather than a bare CVE identifier, the output surfaces statements like "hardcoded production API key exposed in image ENV layers — extractable via docker history" and pairs that finding with a concrete fix. The exposed-credentials section calls out variable names like API_KEY and DB_PASSWORD by name and line number. This specificity is what separates actionable security output from noise.

For teams that want only the AI narrative without running the full scanner stack, the --ai-only flag provides a rapid Dockerfile critique without additional dependencies.

Choosing the Right Mode for Your Workflow

The choice between scan modes is not binary. Fast CI pipelines benefit most from --scan-only, where speed and zero external dependencies matter. Pre-merge reviews or security audits benefit from AI-powered analysis, where developer comprehension and remediation speed are the priority. The --ai-only flag fills the gap for quick Dockerfile reviews during development, before a full build is warranted.

Scanning Built Images and Full Compose Stacks

Dockerfiles are static artifacts. Images are what actually ship to production, and DockSec treats that distinction seriously.

Image Scanning With Trivy and Docker Scout

Scanning a built image with the -i flag triggers both the AI Dockerfile analysis and a full image scan. Trivy enumerates CVEs while Docker Scout compares the target against its base image and suggests an updated alternative. For older base images, critical and high findings can run into the hundreds.

An --image-only mode handles published or third-party images that were not built locally — a particularly useful capability for teams auditing vendor-supplied containers or public images pulled from registries.

The Docker Scout summary consistently delivers some of the most actionable output in the entire scan. It presents the target's CVE counts, the base image's counts, and an updated base image with significantly lower counts side by side. Moving to a newer base tag is frequently the highest-leverage fix available, and Scout surfaces that recommendation directly rather than burying it in a long findings list.

Severity filtering is controlled with the --severity flag. The default reports CRITICAL and HIGH findings. Widening the filter to include MEDIUM triggers a fresh scan rather than replaying a cached result, because the severity level is baked into the cache key. Teams can also set a default using the DOCKSEC_DEFAULT_SEVERITY environment variable, which is worth standardising across teams to ensure consistent reporting baselines. A structured vulnerability assessment approach can help teams decide which severity thresholds are appropriate for their specific risk profile.

Compose Stack Scanning

Real applications rarely run as a single container, and DockSec addresses that reality through Compose stack scanning. The --compose flag scans an entire Compose file and every service within it. DockSec applies a curated set of Compose-level rules covering privileged mode, host networking, and missing resource limits. It then fans out across each service, scanning individual images and any Dockerfile where a build context is defined.

Compose-level findings contribute to the overall security score independently, meaning a stack with critical misconfigurations is scored accordingly even if the underlying service images are clean. This prevents teams from achieving a false sense of security by focusing exclusively on image hygiene while leaving orchestration-level exposure unaddressed.

Understanding the Consolidated Summary

Every scan concludes with the same consolidated summary structure:

• A severity table
• A 0-to-100 security score
• A quick take highlighting the most urgent issues
• A report of output files written
• A suggested follow-up command

Reports land in ~/.docksec/results/ by default and can be redirected with --output-dir or the DOCKSEC_RESULTS_DIR environment variable. The consistency of this structure across all scan modes is intentional — teams reviewing output from different modes or different pipeline stages can orient themselves immediately without adjusting to a different format.

Output and Formatting Options

The --quiet flag reduces output to warnings, errors, and the summary. The --no-color flag strips styling for log pipelines and terminals without color support, and it also honors the NO_COLOR environment variable. These options reflect the practical reality that container scanning output needs to be readable both by humans reviewing terminal output and by downstream log aggregation systems processing plain text.

Where DockSec Fits in a Broader DevSecOps Practice

Container scanning is one component of a broader shift toward embedding security earlier in the development lifecycle. Understanding why DevOps practices matter provides useful grounding for teams evaluating where scanning tooling fits within their pipeline architecture and culture. DockSec's design — with its zero-dependency fast mode, optional AI layer, and Compose-level awareness — reflects the operational realities of teams running containers at scale rather than treating scanning as an isolated compliance exercise.

The series continues on Tuesdays with Part 4 covering pipeline integration, SARIF output, and build gating — the logical next step once scanning is operational. For broader reference on container security standards and CVE data, the CVE Details database provides a comprehensive resource for understanding the vulnerability landscape that tools like Trivy draw from when enumerating image findings.