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

然后大家繼續(xù)開開心心地發(fā)布漏洞鏡像。

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

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

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

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

一行代碼，邏輯徹底翻轉(zhuǎn)。掃描發(fā)現(xiàn)高危問題時，進程直接返回非零狀態(tài)碼，CI流水線當場變紅，構(gòu)建中斷。沒有人工審核環(huán)節(jié)，沒有"下次再改"的借口。

GitHub Actions里的配置長這樣：

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

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

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

多階段構(gòu)建：終于有人搞懂了

Dockerfile掃描有個經(jīng)典難題：多階段構(gòu)建。

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

docker-scan-lite現(xiàn)在能識別最終階段。它知道什么會真正跑在生產(chǎn)環(huán)境，什么只是構(gòu)建過程中的中間態(tài)。

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

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

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

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

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

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

配置稍微復(fù)雜一點：

- 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守護進程依賴，沒有二進制下載的網(wǎng)絡(luò)焦慮。

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

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