Docker掃描工具躺平3年，1行代碼讓流水線真敢攔

上個月有個叫Nick Ciolpan的開發者開源了docker-scan-lite。上線即巔峰——掃描速度夠快，警告信息夠全，GitHub星標漲得也漂亮。

然后大家繼續開開心心地發布漏洞鏡像。

問題出在一個數字：exit 0。無論掃描出多少高危漏洞，無論Dockerfile里硬編碼了多少AWS密鑰，無論是不是以root用戶運行——CI流水線永遠顯示綠色?。警告歸警告，部署歸部署，兩不相干。

這就像你家煙霧報警器響了，但設計成了"只響不停電"。該著火的照樣著火。

從"提醒"到"阻斷"：一個flag的逆襲

Nick在第二版里加了個參數：--exit-code high。

一行代碼，邏輯徹底翻轉。掃描發現高危問題時，進程直接返回非零狀態碼，CI流水線當場變紅，構建中斷。沒有人工審核環節，沒有"下次再改"的借口。

GitHub Actions里的配置長這樣：

- name: Scan Dockerfile
uses: nickciolpan/docker-scan-lite@v1
with:
dockerfile: Dockerfile
fail-on: high

三種情況直接攔停：硬編碼密鑰、root用戶運行、敏感環境變量明文存儲。其他問題——比如沒寫HEALTHCHECK、鏡像標簽不規范——保持警告，由團隊自行判斷。

這種分級處理很聰明。安全團隊要的是"高危必攔"，開發團隊要的是"低噪高效"。兩邊訴求都照顧到了。

多階段構建：終于有人搞懂了

Dockerfile掃描有個經典難題：多階段構建。

典型場景是這樣的——第一階段用golang:1.21編譯，第二階段用alpine:3.18跑二進制。第一階段的問題（比如以root編譯）其實不影響最終產物，但傳統掃描工具不分青紅皂白，統統報一遍。

docker-scan-lite現在能識別最終階段。它知道什么會真正跑在生產環境，什么只是構建過程中的中間態。

另一個修復是誤報率。舊版本把任何URL都當成"數據庫連接字符串"：

?? database_url: https://example.com/install.sh

現在只認真實的數據庫協議：postgres://、mysql://、mongodb://。FROM scratch也不會再被誤判為"使用了latest標簽"——它本來就不是個鏡像標簽。

想要更嚴格的策略？--severity high只輸出關鍵問題，信息密度直接拉滿。

SARIF輸出：漏洞終于能進GitHub安全面板了

企業級團隊需要的不只是命令行輸出。docker-scan-lite支持SARIF格式（靜態分析結果交換格式），可以直接接入GitHub Security tab。

配置稍微復雜一點：

- name: Scan
uses: nickciolpan/docker-scan-lite@v1
with:
dockerfile: Dockerfile
format: sarif
fail-on: ''

- name: Upload SARIF
uses: github/codeql-action/upload-sarif@v3
if: always()
with:
sarif_file: scan-results.sarif

效果是你的Dockerfile問題和CodeQL findings并排展示。安全審計時不用在十幾個工具之間切來切去，一個面板看全。

安裝方式也保持了極簡：Homebrew一條命令，或者go install直接拉源碼。沒有Docker守護進程依賴，沒有二進制下載的網絡焦慮。

Nick在文檔末尾留了句話，挺扎心的："這篇文章和代碼都是LLM寫的。我們還在假裝2026年不是這么干活的嗎？Claude寫了大部分。"

工具鏈在進化，攻擊面也在擴張。你的CI流水線上次放行過什么不該放的東西？