把服務打包成 Docker 映像檔,跑一次安全掃描,報表常常一片紅:基底映像有已知漏洞、套件版本過舊、Dockerfile 寫法有問題、容器權限太寬。開源工具 DockSec 做的就是處理這種報表,2026 年 5 月的報導指出,它已被開放網路應用安全計畫(OWASP)收為孵化專案。它在本機跑 Trivy、Hadolint、Docker Scout 等掃描器,合併重複的警訊,依嚴重程度和被利用的可能性排序,再用 AI 解釋每個問題、給出修法。

這個工具最值得參考的地方,是它自己畫的線。依專案說明,它的自動修正功能只套用 Dockerfile 裡機械式的修改,會先留備份、改完再掃一次;它不會替你挑基底映像的版本、不會搬動密鑰、也不會改部署用的設定檔;遇到還沒提交的變更,除非強制,否則拒絕修改。

這條線也適合團隊照用:改錯容易發現、容易退回的機械修改,可以讓 AI 動手;會改變容器行為的決定,例如換基底映像、改執行權限、改部署設定,要有人測試和放行。

一行修改,影響常常比那一行大

AI 能把一條漏洞說明翻成白話,再附上一行升級指令,看起來很省事。但容器裡的修改,影響常常比那一行大。換一個基底映像版本,可能同時換掉幾十個系統套件,讓已經驗證過的行為改變;把容器改成非 root 使用者執行,可能讓服務讀不到某個目錄而啟動失敗。

這些問題不會出現在掃描報表上,只有實際跑過才知道。DockSec 不替你挑基底映像版本,正是因為這個選擇需要對服務的了解和測試。

先分類,再決定誰動手

機械修改: 例如 Dockerfile 的寫法建議、移除不必要的套件快取、固定版本標籤。改錯容易從建置失敗或差異中看出來,可以讓 AI 修改,但修改要看得到差異、可以退回。

會改變行為的修改: 換基底映像、升級主要系統套件、改容器的執行使用者、改對外開放的連接埠。這類要在測試環境跑過,由服務負責人放行。

資料邊界: 開啟 AI 解讀之前,先知道會送出什麼。依 DockSec 的說明,AI 模式會把 Dockerfile 或部署設定檔的內容,以及漏洞數量的摘要送給模型;看起來像密鑰的值預設會先遮蔽。如果 Dockerfile 裡寫了不該外流的內部位址或設定,可以用只掃描、不呼叫 AI 的模式,或改用在本機執行的模型。

廣告

大量警訊先看是否真的會被用到

掃描結果裡的漏洞,不一定在你的服務執行時會被用到。排序時先問:外面是否已經有人在利用、服務會不會執行到那段程式、外部輸入能不能送進去,參考〈漏洞排序別只看分數,先查執行路徑與外部輸入〉。排好順序之後,AI 產生的修補能不能上線,則要看出事時退不退得回去,參考〈AI 能寫出漏洞修補,能不能上線要看出事時退不退得回去〉。

工具畫的線,還是要依你的服務判斷

DockSec 是一個由個人開發、仍在孵化階段的開源專案,功能和預設值可能改變;這篇引用的是它目前公開的說明,導入前請以專案最新文件為準。工具畫的線可以參考,但哪些修改算「機械式」,還是要依你的服務判斷:同一行修改,在不同服務裡的風險可能完全不同。

AI 整理卡

我們的 Docker 映像檔掃描出一大批警訊,想用 AI 協助整理,同時劃清哪些修改可以讓 AI 動手、哪些要人放行。
判斷方法來自這篇文章:https://boosterminiclass.com/posts/docker-ai-security-scanner-human-fix-gate/
文章的看法是:改錯容易發現、容易退回的機械修改,可以讓 AI 動手;換基底映像、改執行權限、改部署設定這類會改變容器行為的決定,要有人測試和放行。開 AI 解讀前,要先知道哪些檔案內容會送到模型。

請只以唯讀方式查看我授權的 Dockerfile、部署設定和掃描報告,不要修改檔案或執行建置。
1. 把警訊依來源分類:基底映像、套件、Dockerfile 寫法、執行權限或對外連接埠;
2. 把每一類建議修改分成「機械修改」和「會改變行為的修改」,並說明理由;
3. 檢查 Dockerfile 和設定檔裡有沒有不該送到外部模型的內容,例如內部位址或密鑰,並建議用只掃描模式還是本機模型;
4. 列出會改變行為的修改需要在測試環境驗證的項目,以及放行人。
不要替我決定基底映像的版本,只列出候選和要測的地方。
廣告

Share

分享這篇微課

如果這篇剛好解開一個工作卡點,可以分享給也在判斷 AI 怎麼用的人。

參考來源