本地 LLM 幫你睇 Docker Compose：有用，但唔好當安全審計

件事有咩值得睇

XDA 作者 Shekhar Vaidya 喺 2026 年 7 月 6 日講咗個幾貼地嘅實驗：佢個 homelab 由 Jellyfin、Nextcloud 起步，去到而家多過 15 個 active services，每個 stack 各有 Compose file；佢拎 compose、.env、exported JSON 掉入本地 Gemma 4（作者話經 Ollama 跑喺 RTX 4070 Ti），本來想做 inventory，結果模型開始問返一堆安全舊帳。呢篇唔應該包裝成漏洞新聞，因為全部都係個人設定問題；但佢有個好有用嘅提醒：Docker Compose 最危險嗰啲位，好多時源自當年為咗快啲起機留下嘅方便位。

圖片：Wikimedia Commons — Ollie Shotton (WMDE)（CC BY-SA 4.0）

LLM 幫到手嘅位

作者個 dashboard 未等 Gemma 開聲，已經數到 18 services、15 stacks、11 個 unpinned images、22 個 bind mounts 同 1 個 host networking；呢啲唔等於漏洞，但係夠你知道要由邊度查起。跟住 Gemma 標出 Vaultwarden compose file 入面硬寫咗 ADMIN_TOKEN，Keeper 入面有 GOOGLE_CLIENT_SECRET 同 ENCRYPTION_KEY，亦提醒 Dockge mount 咗 docker.sock，Scrutiny 接咗 /dev/sda。全部都要歸因 XDA 作者自己嘅環境；TechLab 冇實測呢套 Gemma pipeline，亦冇確認佢每個判斷。

呢類工具最啱做第一輪挑刺。你可以叫佢逐個 service 睇 privileged: true、network_mode: host、暴露出去嘅 ports、/var/run/docker.sock、host path bind mount、volume 有冇 :ro、container 有冇用 non-root user、cap_add 係咪太闊、secrets 係咪硬寫喺 .env 或 compose、image tag 有冇 pin 住、更新同回滾靠咩做。人手睇 15 個 stack 好悶，模型擅長搵 pattern，尤其係你幾個月冇回頭睇嗰堆 YAML。

本地跑嘅價值

呢個場景喺香港幾常見：屋企 NAS 跑 Jellyfin、相簿、Home Assistant，或者 SME 自己 host Nextcloud、Vaultwarden、automation dashboard。Compose file 入面可能有內網 hostname、DB password、OAuth secret、Cloudflare token，直接貼去雲端 AI 其實好難交代。本地 LLM 就算冇外連，仍然要當成內部工具處理；不過相對雲端 chat，至少你可以先喺自己部機上面做一次敏感 config review，唔使將成個內網地圖交出去。

YAML 唔識睇你個網絡

最易中伏係 false positive 同漏報。XDA 作者提到 AdGuard Home 俾 Gemma 指 host networking 風險，但佢話 AGH 只服務屋企 LAN，YAML 本身睇唔到 firewall、VLAN、reverse proxy、VPN、Cloudflare Tunnel 同 router ACL。相反，LLM 都未必知道某個 image 最新 CVE、某個 image rootless mode 會唔會爆、某個 port 喺你 ISP router 上有冇真係開咗出去。所以模型講「critical」唔代表要即刻照做，模型冇講亦唔代表安全。

官方文件個底線其實好清楚。Docker Engine security 文件講 container 靠 namespaces、capabilities 同 daemon 權限隔離，Docker Compose secrets 文件亦建議 password、API key 呢類敏感資料用 secrets 掛入 /run/secrets/，唔好長期放喺 environment variable。OWASP Docker Security Cheat Sheet 就講得好直接：唔好 expose docker.sock 畀 container、avoid --privileged、capabilities 要最少化、no-new-privileges 同 read-only filesystem 都係常見 hardening 位。CIS Docker Benchmark 就整理成可 audit 嘅基準，適合公司 IT 或 MSP 定期對表。

點用先唔會中伏

實際做法可以係：先用本地 LLM 讀晒 compose，要求佢用 checklist 形式列出每個 service 嘅風險、原因、可能修法、會唔會影響功能；再逐項返去 Docker、OWASP、CIS 文件核對，最後開測試 stack 逐項改、逐項試。尤其係 NAS 同細公司 server，唔好一次過塞晒 read_only: true、cap_drop: ALL、non-root user，因為好多 image 會因為寫 cache、改權限或者 bind device 即刻跪低。呢種 audit 最實際嘅作用，係幫你重新睇一次舊 compose，順手減少將 secrets 貼上雲端工具嘅需要。

參考來源

• XDA Developers — I gave my local LLM my Docker Compose files, and it found security holes I missed — original report
• Docker Docs - Docker Engine security — 核對 Docker daemon、namespaces、capabilities 同 rootless 等安全背景
• Docker Docs - Manage secrets securely in Docker Compose — 核對 Compose secrets 點處理 password、API key 同 per-service access
• OWASP Cheat Sheet Series - Docker Security Cheat Sheet — 核對 docker.sock、privileged、cap_drop、read-only filesystem 等 checklist
• CIS - Docker Benchmarks — 確認 CIS Docker Benchmark 係公開容器安全基準來源

本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。