SecTor 2025 | How Secure is Your Base Image? A Live Security Test of Popular OSS Containers
三句話摘要
從三個熱門 Docker base image 的實例分析，揭示容器映像安全不只是 CVE 數量問題，更在於 Dockerfile 設計缺陷與攻擊面控管。 --- 容器安全的核心不是追著 CVE 數字跑，而是從 Dockerfile 設計源頭隔離 builder 工具、移除 root 權限，並把這套紀律自動化進部署流程。 1. 開發者映像混入生產環境是最普遍的根本問題
重點整理
重點- 1
1. 開發者映像混入生產環境是最普遍的根本問題
- 2
開發者為求方便，使用包含完整編譯工具（GCC、curl、libC-dev 等）的 builder image，卻直接部署到生產，導致攻擊面遠超過應有水準。這些工具在 runtime 從來不需要，卻每天都在生產環境跑著。
- 3
2. CVE 數量與實際風險成反比的悖論
- 4
Golang image 有 1,000+ CVE，MCP Gateway 只有 5 個，但 MCP Gateway 反而被評為最危險。少量 CVE 讓人掉以輕心，但每一個都可能是記憶體洩漏、競態條件、或防火牆規則遺失等高危漏洞，且有充足時間深入追蹤。
- 5
3. Debian 的「延遲修補」策略製造合規死角
- 6
Debian Bookworm 對部分 CISA KEV 等級漏洞採取 no-DFA（延後到下一版本修復）策略，使用者若不升級 OS 或自行 backport patch，將長期暴露於已知可利用漏洞，而平均 CVE 到 exploit 的時間窗口只剩 7–10 天。
- 7
4. Dockerfile 設計本身是安全邊界
- 8
`chmod -R 777 gopath`、沒有定義 USER 預設跑 root、Docker-in-Docker 架構、Socat 等 staging 工具殘留，這些 Dockerfile 層級的缺陷比 CVE 更根本，且往往是人工省略造成，而非惡意。
- 9
--
實用技巧與重點
乾貨- 數字與時間線
- Golang image：1,000+ CVE，含 CISA KEV 漏洞 CVE-2025-48384
- 合規 SLA：Critical 7 天修復、High 14 天、Medium 30 天
- CVE 公開到 exploit 平均時間：7–10 天（Critical/High 等級）
- Multi-stage 優化後估計：原 ~1 GB → ~100 MB 以下
- 工具與格式
- 掃描工具：Trivy（開源）
- 映像來源：Docker Hub（docker pull 指令）
- SBOM 格式：CycloneDX、SPDX
- VEX（Vulnerability Exploitability eXchange）：用於說明漏洞是否實際影響該映像
- Attestation：建置來源與安全流程的可驗證證明
- 具體漏洞
- CVE-2025-48384：CISA KEV，Debian Bookworm 無修補，需 backport
- CVE-2025-47907：Go database 競態條件，記憶體緩衝區腐敗洩漏
- GHSA（Docker client library）：Docker daemon 重啟後防火牆規則遺失，端口意外開放
- V2 map structure leak：高負載下洩漏 secrets 至 log 檔
- 有問題的 Dockerfile 模式
- `FROM golang:bookworm`（full image）
- `RUN chmod -R 777 $GOPATH`
- 無 `USER` 定義（預設 root）
- `RUN apk add docker-cli`（root 執行 Docker CLI）
- `FROM scratch AS mcp-gateway-dind`（Docker-in-Docker）
- 安裝 Socat 等網路偵測工具殘留 production
- 修復模式
- Multi-stage build：`FROM golang:bookworm AS builder` → `FROM debian:bookworm-slim`，`COPY --from=builder`
- 加入 `RUN useradd golang && USER golang`
- 將 libC-dev 等 header 留在 builder stage，不複製到 deployment stage
- Semantic version patch upgrade：1.2.3 → 1.2.4（安全），1.2 → 1.3（functional，謹慎）
- 以 sidecar pattern 取代 Docker-in-Docker
- --
結論
結論“容器安全的核心不是追著 CVE 數字跑，而是從 Dockerfile 設計源頭隔離 builder 工具、移除 root 權限，並把這套紀律自動化進部署流程。”
完整解析
詳細容器映像是現代軟體供應鏈的核心節點，開發者寫的程式在此打包，夾帶著大量開源套件進入生產環境。Root 的 CTO John 在這場演講中點破一個長期存在的認知落差：多數組織把 CVE 數量當作安全指標，但這只抓到了問題的表面，真正的風險往往藏在 Dockerfile 的設計決策裡。
John 從 Docker Hub 挑出三個他在客戶生產環境頻繁見到的映像：Golang、Python、MCP Gateway，逐一用 Trivy 掃描並對照 Dockerfile。Golang image 掃出 1,000+ CVE，令人警醒，但更值得注意的是其中一個 CISA KEV 等級漏洞（CVE-2025-48384）——美國政府要求 KEV 漏洞必須在極短時間內修復，而 Debian Bookworm 對此採取「no-DFA」策略，官方說要等下一個發行版（Trixie）才修，留下一個無法用常規 apt 更新處理的死角。與此同時，Dockerfile 裡 `chmod -R 777 $GOPATH` 直接給出全域寫入權限，加上沒有定義 USER 預設跑 root，使得攻擊者一旦進入這個容器，幾乎可以為所欲為。Python image 有類似的 builder 工具殘留問題：libC-dev 本質上只是 header 檔，不含實際可執行程式碼，但安全掃描器照單全收，產生大量誤報雜訊，真正的問題反而被淹沒。
MCP Gateway 的案例最具警示性：只有 5 個 CVE，乍看合規負擔輕鬆，但 John 細讀之後發現每一個都是高風險——競態條件導致記憶體洩漏、Docker daemon 重啟後防火牆規則遺失、高負載下 secrets 寫入 log。更嚴重的是架構設計：Docker-in-Docker 讓容器裡跑著另一個 Docker daemon，沒有設定 USER 的情況下 Docker CLI 以 root 執行，加上 Socat 這類網路偵測工具被打包進去——這組合對於加密貨幣挖礦惡意程式的作者而言是現成的後門。「CVE 少不等於風險低」這個結論，在這個例子裡被清晰地展示出來。
修復路徑的核心是 multi-stage build：把「建置軟體」與「打包部署」兩個關切分離。builder stage 引入所有編譯工具和 header，deployment stage 只從 builder 複製出最終 binary，使用 `debian:bookworm-slim` 為底，並加入非 root user。如此一來，原本 ~1 GB 的映像可壓縮至 100 MB 以下，CVE 數從千降至雙位數，合規審查的焦點因此能集中在真正重要的漏洞上。對於 Debian 不提供修補的 KEV 漏洞，解法是 backport patch——從未來版本取出變動、重新編譯、注入當前版本，雖屬進階操作，但是在不升級 OS 的前提下的唯一可行路。John 最後強調，shift-left 把安全壓回開發者身上是行不通的，真正的出路是把這些最佳實踐自動化進 CI/CD 流程，讓安全成為預設，而不是需要人工介入的負擔。
---
關鍵時刻
Pipeline v2帶時間戳的重點，會在逐字稿層級分析上線後產生。目前請先透過原始影片觀看。
事實查核
Pipeline v2說法查證是下一次管線升級的一部分。KeyFrame 只會顯示它真正能驗證的內容。
