You package a service as a Docker image and get ready to hand it to a teammate for testing or deployment. After the security scanner runs, the screen suddenly fills with dozens, sometimes hundreds, of warnings: outdated packages, vulnerable base images, unsafe Dockerfile settings, and permissions that may be too broad for a container.
If security is not your daily work, it is easy to fall into one of two extremes: ignore the warnings, or ask AI to “fix everything.” The first choice may leave a real hole in place. The second is not safe either, because AI may change versions, install steps, or runtime permissions in ways that make the service look safer while breaking something else.
OWASP Incubator Project DockSec has recently been covered by several security and open-source outlets. It brings together existing Docker scanning tools such as Trivy, Hadolint, and Docker Scout, then uses large language models—AI systems that can read text and generate explanations—to organize warnings, explain risk, and suggest Dockerfile fixes. It also offers an offline scan-only mode, where it scans without calling AI; when explanation is needed, it can connect to OpenAI, Anthropic, Google Gemini, or a local Ollama model.
The value of this kind of tool is not that AI can press the fix button for you. The real lesson is this: when scan results multiply, the team needs a workflow that first sorts the warnings, then fixes them, and finally asks a human to approve the risky parts.
The problem is not too few warnings, but too many warnings with no clear first step
Docker is a way to package an application, its runtime environment, and its dependencies together. Many websites, APIs, internal tools, and small AI services use Docker because it makes deployment more predictable. The problem is that the package can contain operating-system packages, language packages, configuration files, and startup commands at the same time. If any layer is outdated or has too much permission, it can become a risk.
Traditional scanners are good at finding problems, but they do not always help teams decide what to fix first. For an everyday developer, a scan report often looks like this:
- Some warnings are urgent and should be fixed today.
- Some warnings exist inside a package, but the service does not use the vulnerable function.
- Some fixes look like simple version upgrades, but may change compatibility.
- Some Dockerfile suggestions are reasonable, but may break the existing deployment flow.
Tools like DockSec try to fill the gap between “a pile of warnings” and “a readable repair plan.” Open Source For You quoted the project author describing a common problem: developers may receive more than 200 CVEs, meaning publicly numbered security vulnerabilities, and still not know which lines to fix first.
But that creates a new risk. When AI explains a fix smoothly, a team may start to feel that the decision has already been made. It has not. AI can organize clues; it cannot decide whether this service is allowed to change versions, switch base images, or remove a package.
First split fixes into three layers: routine, test first, human decision
When you see an AI-organized scan report, do not start by asking whether it is smart. Ask: if this fix is wrong, who is affected?
| Fix layer | Common examples | Next step |
|---|---|---|
| Routine fix | Dockerfile formatting, clearly unnecessary temporary files, documented low-risk settings | Apply the change, but keep a diff record |
| Test before fixing | Package upgrades, base-image changes, build-step changes | Run tests in an isolated environment; make sure rollback or recovery is possible |
| Human decision required | Permission-model changes, removal of core packages, network or credential changes, customer-data impact | Ask the responsible owner to confirm risk, timing, and release window |
The point of the table is to turn an “AI suggestion” into a traceable fix decision. AI can explain why a vulnerability matters and point to possible Dockerfile changes. But if the fix affects deployment, permissions, data handling, or customer availability, AI advice should not flow straight into production.
Permission-related changes deserve extra care. Reducing permissions is often good, but if the service relies on a file, connection, or system capability, cutting that permission can pass local tests and fail only in production. Security is not about removing every permission. It is about knowing why each permission exists, which ones can be removed, and which ones need narrower replacements.
Every AI fix suggestion should pass four checks
If a team wants to put AI-assisted scanning into its daily workflow, each fix suggestion can pass through four checks.
| Check | Question to ask | Why it matters |
|---|---|---|
| Impact scope | Does this vulnerability affect the current image, runtime mode, and exposed entry points? | Avoid spending time on warnings that cannot be triggered |
| Change type | Is AI suggesting a version change, a setting change, a permission change, or a full build-flow change? | Different changes need different test depth |
| Test evidence | After the change, did you run unit, integration, startup, or deployment tests? | Avoid “higher scan score, broken service” |
| Recovery path | If the fix causes trouble, can you quickly return to the previous version? | Security fixes also need rollback and recovery plans |
Rollback or recovery means returning a change to the last stable state. That is not pessimism; it is part of security work. The more a fix touches base images, system packages, or deployment permissions, the more important it is to know how to reverse it before making the change.
Do not treat a 0-to-100 security score as the only target either. Scores can help track improvement, but they are not a complete answer to whether the product is safe. What matters is whether high-risk warnings were handled, whether fixes were tested, whether exceptions were approved, and whether the next scan can explain why a warning was left in place.
When AI should not fix automatically
Some work is well suited to AI assistance: translating a report into plain language, merging duplicate warnings, and listing possible Dockerfile changes. That saves reading time.
But the following situations should not move from AI auto-fix to production on their own:
- The service handles customer data, payments, login, internal credentials, or company secrets.
- The fix changes the base image, database driver, encryption package, or network settings.
- There are no automated tests and no clear deployment rollback or recovery path.
- Nobody on the team can explain which permissions the container needs.
- The scanner and AI model need to send report data to an external service, and you have not confirmed whether the data includes sensitive information.
DockSec’s documentation notes that it can run offline scans and can use different AI models when needed. That is a useful reminder: before introducing any AI-assisted security tool, first check whether data leaves the local machine, whether the tool sends a full image or only scan metadata, who can see the report, and where the report is stored.
If you cannot answer those questions yet, do not put the tool into the production build flow. Start in an isolated test environment, using a non-sensitive project, and practice the sorting and fix workflow there.
A minimum workflow: let AI explain, but let a human approve
A small team does not need a complex security platform on day one. A practical starting point is to put scan results into a simple table. This table is not a third new standard. It is a worksheet that compresses the three-layer sorting table and the four checks above into something you can paste into a pull request, ticket, or fix record.
| Field | What to record |
|---|---|
| Warning summary | The problem described by AI or the scanner |
| Impact judgment | Whether it affects the current service; if not, why not |
| Fix type | Routine fix, test-before-fix, or human decision required |
| Test evidence | Which tests ran after the change and what happened |
| Approver | The person who truly confirmed that this fix can be merged or deployed |
This workflow looks slower than “fix everything with one click,” but it prevents the most dangerous misunderstanding: assuming that because AI explained the vulnerability, AI also carries the consequences of the fix.
Everyday four-panel comic
- The team receives a box full of security warnings, and every card looks urgent at first.
- They sort the warnings into routine fixes, test-first fixes, and human-decision items.
- AI helps organize clues and a checklist, while people still verify tests and recovery plans.
- Only low-risk fixes move forward; risky items wait for the responsible owner.
Tools like DockSec can make security scans easier to read, and that is useful. But the easier a report is to read, the more clearly it needs human gates. The next time a Docker scanner dumps a pile of vulnerabilities, do not rush to ask AI to fix them all. First decide which items are just organization work, which are engineering changes, and which affect real product responsibility.
AI handoff card
Ask AI to organize this article's specific situation
Copy this into your own AI chat tool to turn this mini class into a personal checklist. BMC will not see what you paste into your AI tool.
References
- OWASP: DockSec project page — https://owasp.org/www-project-docksec/
- GitHub: OWASP/DockSec — https://github.com/OWASP/DockSec
- Open Source For You: OWASP-Backed Open Source DockSec Uses LLMs To Fix Docker Vulnerabilities Faster — https://www.opensourceforu.com/2026/05/owasp-backed-open-source-docksec-uses-llms-to-fix-docker-vulnerabilities-faster/
- Help Net Security: DockSec: Open-source AI-powered Docker security scanner — https://www.helpnetsecurity.com/2026/06/08/docksec-open-source-ai-docker-security-scanner/
- SecurityWeek: Open Source DockSec Uses AI to Cut Through Vulnerability Noise in Docker Images — https://www.securityweek.com/open-source-docksec-uses-ai-to-cut-through-vulnerability-noise-in-docker-images/
