The problem hiding in plain sight
Containers won because they made shipping software boring. A Dockerfile, a base image, a docker build, and your application runs the same on a laptop as it does in production. But that convenience quietly moved a large part of the security surface into an artifact most teams treat as configuration rather than code.
A single <FROM python:3.9> line pulls in an entire operating system: hundreds of system packages, transitive libraries, and whatever CVEs happened to be present the day the image was published. Layer on a few <RUN apt-get install> commands, a hardcoded credential in an ENV, and a base image that was never pinned, and a routine build can inherit thousands of known vulnerabilities before your own code is even copied in. Scan a common base image today and it is not unusual to see hundreds of critical and high-severity findings.
The tooling to detect this is mature. Scanners like Trivy enumerate CVEs in packages, Hadolint lints Dockerfiles against best practices, and Docker Scout compares your image against its base and suggests upgrades. These are excellent tools. The problem is not detection. The problem is what happens after detection.
The wall of red
Anyone who has run a container scan in a CI pipeline knows the experience: a wall of red, 200-plus findings, each with a CVE identifier, a severity label, and a terse description written for a vulnerability database rather than a developer. The output answers "what is wrong" but almost never answers the three questions a developer actually has:
-
Which of these actually matter for my container, given how it is built and run?
-
What, specifically, do I change in my Dockerfile to fix it?
-
If I can only fix five things today, which five move the needle most?
Faced with an undifferentiated list, teams do one of two things. They ignore it, because triaging 200 findings by hand is not a sprint task. Or they bolt on a suppression file and move on. Neither improves security. The detection was never the bottleneck; the translation from findings to action was.
This is the gap DockSec was built to close.
What is DockSec?
DockSec is an OWASP Lab Project: an AI-powered Docker security scanner that explains vulnerabilities in plain English and, crucially, tells you how to fix them in the context of your specific Dockerfile. It does not reinvent detection. It wraps the industry-standard scanners you already trust—Trivy, Hadolint, and Docker Scout—and adds a reasoning layer on top that prioritizes, explains, and remediates what they find.
The distinction matters. Trivy will tell you that <openssl> in your image has a critical CVE. DockSec will tell you that, and that your base image is unpinned, and that you are running as root, and that you have an API key hardcoded on line 3—and then it will hand you a corrected Dockerfile with a pinned slim base image, a non-root USER directive, and the secret moved to a runtime injection pattern. It turns a scanner's report into a code review.
Think of it as pairing the recall of automated scanners with the judgment of a security engineer sitting next to you, reviewing the Dockerfile in real time.
Why an AI layer, and why now?
Skepticism about "AI-powered" anything is healthy, so it is worth being precise about what the language model actually does here, because it is narrow and grounded.
The LLM does not invent vulnerabilities. Every CVE DockSec reports comes from Trivy or Docker Scout; every lint finding comes from Hadolint. The model's job is to correlate those grounded findings with the actual content of your Dockerfile and produce three things the raw scanners cannot: a prioritized narrative of what matters most, a plain-English explanation of why each issue is dangerous in your context, and specific, line-level remediation you can paste back into your file. It is the reasoning and translation layer, not the source of truth.
This matters because the alternative—a human doing this correlation across three tools and a Dockerfile for every service, on every build—does not scale. Security teams are outnumbered by developers by an order of magnitude. The only way contextual remediation reaches every Dockerfile is to automate the reasoning, not just the detection.
The design principles that fall out of this
Once you accept that the value is in contextual remediation, several design choices follow naturally, and they shape everything in the rest of this series.
Bring your own model
Contextual analysis should not require shipping your proprietary Dockerfiles and image contents to a vendor's cloud. DockSec supports OpenAI, Anthropic Claude, and Google Gemini for teams that want hosted models, and Ollama for teams that need everything to stay on their own hardware. A regulated or air-gapped team can run the full pipeline—scanning and AI remediation—without a single byte leaving their network.
Detection without AI is always available
The AI layer is additive, not mandatory. A <--scan-only> mode runs the full scanner stack with local, rule-based scoring and no API key at all. You get the wall of findings and a security score; you simply do not get the plain-English narrative. This keeps DockSec useful in the strictest environments and in fast CI paths where you only want a gate.
Open source and vendor-neutral
As an OWASP project under the MIT license, DockSec has no commercial tier that withholds features, no telemetry, and no lock-in. The comparison that matters is not against Trivy—which DockSec builds on—but against the commercial platforms that offer AI remediation only by hosting your data on their infrastructure. DockSec offers the same class of remediation while keeping you in control of both your data and your choice of model.
Where this series goes
This first article made the case for why a reasoning layer on top of mature scanners is the missing piece in container security. The rest of the series gets concrete.
-
Part 2 opens the hood: The architecture, how the three scanners and the LLM pass fit together, and how a single results contract flows through scoring and reporting
-
Part 3 is hands-on: Scanning a Dockerfile, an image, and a full Docker Compose stack, with real commands and output
-
Part 4 covers automation: Gating builds with severity thresholds and exit codes, SARIF for GitHub code scanning, and baseline "ratchet" mode for adopting gates on existing projects
-
Part 5 steps back to adoption: The security scoring model, the metrics worth tracking, and how an OWASP-governed tool fits into a broader program
Container security does not fail for lack of scanners. It fails at the last mile, where a list of findings has to become a change someone actually makes. That last mile is the whole point of DockSec.
This is the first in a five-part series. Watch for coming installments on Tuesdays.
