當(dāng)一份容器安全掃描報(bào)告擺在面前時第一眼看到的不應(yīng)該是恐慌而是一份資產(chǎn)清單。我們維護(hù)的 NanoClaw 鏡像在第一次做全量漏洞掃描時報(bào)告里出現(xiàn)了 1,400 多個 CVE。當(dāng)時團(tuán)隊(duì)的第一反應(yīng)是“這鏡像還能不能用”第二反應(yīng)是“這要修到什么時候”。后來我們把工作重點(diǎn)從“逐個 CVE 打補(bǔ)丁”改成“從鏡像構(gòu)建源頭減少風(fēng)險(xiǎn)暴露面”用一個迭代周期把嚴(yán)重和高危漏洞清零整體 CVE 數(shù)量從千級降到個位數(shù)。這篇文章就把這次加固的完整思路和落地方法整理出來。NanoClaw 是一個以容器化方式運(yùn)行的 AI Agent 工作流項(xiàng)目鏡像里既要裝 Python 運(yùn)行時又要裝模型調(diào)用和工具執(zhí)行相關(guān)的依賴。這類鏡像的典型問題是為了“省事”基礎(chǔ)鏡像選通用開發(fā)鏡像依賴包不鎖定版本運(yùn)行時還保留 shell、包管理器、編譯工具鏈。掃描器把這些歷史包袱全部折算成 CVE 清單時數(shù)字自然非常驚人。這篇文章會講清楚三件事CVE 到底是怎么進(jìn)入鏡像的如何通過基礎(chǔ)鏡像、依賴層、運(yùn)行權(quán)限三個方向的改造把風(fēng)險(xiǎn)降下來以及如何把漏洞掃描和準(zhǔn)入門禁嵌進(jìn) CI/CD 流程防止問題再次反彈。文章中的方法不只適用于 NanoClaw也適用于任何基于 Python 或 Node.js 的 AI 服務(wù)、Agent 工具和內(nèi)部平臺鏡像。1. 1,400 個 CVE 意味著什么先糾正一個常見誤區(qū)CVE 數(shù)量并不等于“鏡像一定不安全”但它是安全審計(jì)、合規(guī)審查和鏡像交付時的硬指標(biāo)。CVE 的全稱是 Common Vulnerabilities and Exposures也就是公開的漏洞編號體系。掃描器讀鏡像里的軟件清單與公開漏洞庫做匹配命中一個就給一條記錄。鏡像里的軟件越多、版本越老、來源越雜CVE 數(shù)量就越多。CVE 的嚴(yán)重程度通常用 CVSS 評分分級等級CVSS 分?jǐn)?shù)范圍典型處理策略Critical9.0 - 10.0立即修復(fù)阻斷發(fā)布High7.0 - 8.9優(yōu)先修復(fù)短周期內(nèi)處理Medium4.0 - 6.9按風(fēng)險(xiǎn)評估排期修復(fù)Low0.1 - 3.9記錄跟蹤隨版本更新看到 1,400 這個數(shù)字時首先要做的是區(qū)分漏洞來源。容器鏡像中的 CVE 并不來自同一個地方通常由四類組件構(gòu)成基礎(chǔ)鏡像自帶的系統(tǒng)軟件包比如 libc、openssl、curl、ca-certificates語言依賴包比如 Python 的 pip 包、Node.js 的 npm 包項(xiàng)目自己引入的二進(jìn)制程序比如下載到鏡像里的 CLI 工具鏡像構(gòu)建過程中臨時安裝又沒清理的編譯工具和緩存文件。AI Agent 類項(xiàng)目更容易中招原因是嵌套依賴非常深。模型調(diào)用 SDK 可能引入 aiohttp、httpx、pydantic、numpy 等一大批間接依賴間接依賴又可能繼續(xù)引入底層 C 擴(kuò)展庫。如果依賴文件只寫了頂層包名而沒有鎖定版本構(gòu)建時拉到的間接依賴可能會在幾個月內(nèi)從“安全”變成“危險(xiǎn)”。所以 1,400 個 CVE 的真正含義是鏡像的可信度被打了問號。它不一定是 1,400 個真實(shí)可利用的攻擊入口但它意味著鏡像瘦身、基線和依賴管理的優(yōu)先級必須上調(diào)。2. NanoClaw 鏡像出現(xiàn)大量 CVE 的根因分析在一次加固前的鏡像分析里我們把 NanoClaw 鏡像的分層拆開把每一層里命中的 CVE 按來源歸因最后得到了三個根因。2.1 基礎(chǔ)鏡像層直接復(fù)用通用開發(fā)鏡像一開始Dockerfile 的基礎(chǔ)鏡像寫得非常隨意FROM python:3.11-bullseye這個鏡像自帶完整的 Debian 發(fā)行版用戶態(tài)包含軟件包管理器、Shell、編譯工具鏈。對一個最終只需要“運(yùn)行 Python 應(yīng)用”的鏡像來說這里面有不少組件在運(yùn)行時根本不會被使用。每個系統(tǒng)軟件包都有各自的漏洞跟蹤記錄即使很多只存在于鏡像里而不會被攻擊者觸達(dá)掃描器也會如實(shí)在 CVE 清單里記錄。2.2 依賴層版本不鎖定全量安裝requirements.txt 里充滿了形如下面這樣的寫法flask2.0 requests openai這種寫法在本地開發(fā)時問題不大但一旦固化成鏡像就有兩個隱患。第一2.0這種范圍是“構(gòu)建時漂移”今天構(gòu)建和三個月后構(gòu)建拉到的版本可能不同覆蓋的 CVE 也隨之變化第二openai這種包會拉取大量間接依賴不做鎖定就無法追溯某一條漏洞來自哪個依賴。另一個問題是安裝方式。很多 Python 鏡像會寫成RUN pip install -r requirements.txt這條命令會把所有依賴裝進(jìn)系統(tǒng) Python 的 site-packages然后為了兼容某些需要編譯的包又必須保留 gcc、python3-dev。編譯工具鏈一旦進(jìn)入最終鏡像掃描器就會把這些編譯工具依賴的 CVE 也算在鏡像頭上。2.3 運(yùn)行時配置層root 用戶與完整 Shell加固前的鏡像沒有單獨(dú)創(chuàng)建運(yùn)行用戶容器默認(rèn)以 root 身份運(yùn)行。這意味著一旦某個 CVE 被實(shí)際利用攻擊者直接獲得的是容器內(nèi)最高權(quán)限。鏡像里還保留了/bin/bash、/bin/sh、curl、wget等工具這些工具本身是運(yùn)維排查時的好幫手但也是真實(shí)的攻擊面。權(quán)限和攻擊面都不收口CVE 數(shù)量自然收不回去。從這三個根因可以得出一個重要結(jié)論CVE 的源頭是鏡像生產(chǎn)過程中的選擇不是漏洞庫本身的膨脹。修復(fù)工作如果只在掃描報(bào)告出來之后一個個 Suppress永遠(yuǎn)追不上漏洞庫的更新速度只有改變鏡像構(gòu)建的原料和過程才能在下一次掃描時讓清單自然變短。3. 加固鏡像的總體思路從“事后補(bǔ)丁”走向“源頭治理”我們在 NanoClaw 加固項(xiàng)目里的核心思路可以概括為一句話先量化再分層后治理。3.1 先量化不要拿著掃描報(bào)告就直接改。先做一次全量掃描把結(jié)果導(dǎo)出成 JSON 或 CSV按 CVE 嚴(yán)重程度、組件類型、是否可被利用三個維度分組。這樣能回答三個問題哪些 CVE 來自系統(tǒng)層哪些來自 Python 依賴哪些 CVE 屬于“已修復(fù)但鏡像沒更新”哪些 CVE 只影響開發(fā)工具完全不影響運(yùn)行路徑量化階段推薦使用 Trivy 全量掃描trivy image --format json --output nanoclaw-scan.json \ your-registry.com/nanoclaw-agent:v1.4.0把 JSON 導(dǎo)入本地分析工具后按Class字段分組通常能直觀看出系統(tǒng)包和語言包各占多少比例。3.2 后分層鏡像加固按下面四個層次推進(jìn)每個層次有獨(dú)立的驗(yàn)收標(biāo)準(zhǔn)層次改造內(nèi)容驗(yàn)收標(biāo)準(zhǔn)基礎(chǔ)鏡像層更換為精簡鏡像不裝系統(tǒng)包管理器系統(tǒng)級 CVE 數(shù)量明顯下降依賴層鎖定直接和間接依賴移除運(yùn)行無關(guān)包語言級 CVE 可控、可復(fù)現(xiàn)運(yùn)行時層非 root 運(yùn)行避免安裝 shell只讀根文件系統(tǒng)攻擊面收口權(quán)限最小化供應(yīng)鏈層生成 SBOM鏡像簽名CI 加入掃描門禁每次發(fā)布有清單、有簽名、有可追溯性3.3 后治理最后一步是把掃描接入 CI/CD。不是掃描完看一眼就好而是設(shè)置退出碼門檻嚴(yán)重和高危 CVE 不為零時流水線失敗。中危漏洞可以放行但必須記錄在案并設(shè)定修復(fù)時間。這樣下一次安全審計(jì)來臨時你能拿出的是“策略 數(shù)據(jù) 例外說明”而不是一張巨大的漏洞表格。這個治理思路也能避免“CVE 清零后又反彈”的問題只有構(gòu)建流程里強(qiáng)制掃描和阻斷鏡像的漏洞水平才會持續(xù)被控制在閾值以下。4. 基礎(chǔ)鏡像替換把“萬能鏡像”換成“最小鏡像”基礎(chǔ)鏡像是 CVE 的第一大來源。替換基礎(chǔ)鏡像是性價(jià)比最高的動作但替換不是無腦選 “Alpine” 或 “Distroless”要考慮運(yùn)行時兼容性和團(tuán)隊(duì)維護(hù)能力。4.1 先看改造前的 Dockerfile加固前典型的 NanoClaw 鏡像構(gòu)建文件# 文件路徑Dockerfile.before FROM python:3.11-bullseye WORKDIR /app COPY requirements.txt . RUN pip install -r requirements.txt COPY . . ENTRYPOINT [python, main.py]這個鏡像的問題一目了然基礎(chǔ)鏡像包含完整 Debian 用戶態(tài)pip 安裝沒有關(guān)閉緩存構(gòu)建工具鏈全量保留并且沒有創(chuàng)建非 root 用戶。4.2 加固后的 Dockerfile加固后我們采用“構(gòu)建階段和運(yùn)行階段分離”的多階段構(gòu)建方式。構(gòu)建階段負(fù)責(zé)安裝依賴和打包運(yùn)行階段只保留運(yùn)行需要的最小內(nèi)容# 文件路徑Dockerfile FROM python:3.11-slim-bookworm AS builder ENV PIP_NO_CACHE_DIR1 \ PIP_DISABLE_PIP_VERSION_CHECK1 \ PYTHONDONTWRITEBYTECODE1 WORKDIR /app COPY requirements.txt . RUN apt-get update \ apt-get install -y --no-install-recommends build-essential \ rm -rf /var/lib/apt/lists/* \ pip install --prefix/install -r requirements.txt FROM python:3.11-slim-bookworm RUN apt-get update \ apt-get install -y --no-install-recommends ca-certificates \ rm -rf /var/lib/apt/lists/* \ useradd --create-home --shell /usr/sbin/nologin appuser WORKDIR /app COPY --frombuilder /install /usr/local COPY --frombuilder /app /app COPY . . ENV PYTHONUNBUFFERED1 USER appuser EXPOSE 8080 ENTRYPOINT [python, main.py]這個 Dockerfile 做了幾件關(guān)鍵的事基礎(chǔ)鏡像從bullseye換成slim-bookworm減少大量未使用系統(tǒng)包構(gòu)建階段的build-essential只存在于 builder 階段最終鏡像不保留--prefix/install把 Python 依賴安裝到獨(dú)立目錄運(yùn)行階段只復(fù)制該目錄運(yùn)行階段只保留ca-certificates刪除 apt 緩存創(chuàng)建appuser容器不再以 root 運(yùn)行。4.3 如何選擇精簡基礎(chǔ)鏡像如果對兼容性要求更高可以繼續(xù)走兩個方向基礎(chǔ)鏡像優(yōu)點(diǎn)需要注意的問題python:slim體積適中g(shù)libc 兼容性好仍包含部分系統(tǒng)工具python:alpine體積小musl libc部分 C 擴(kuò)展需要單獨(dú)做 musl 編譯gcr.io/distroless體積最小無 shell排查問題不方便沒有包管理器cgr.dev/chainguard/python默認(rèn)非 rootCVE 數(shù)極少包更新策略需要跟隨上游對 NanoClaw 這類需要頻繁調(diào)試 AI 依賴的鏡像我們最終沒有直接用 Distroless而是選擇python:3.11-slim-bookworm搭配多階段構(gòu)建。原因是 pydantic-core 等 C 擴(kuò)展在 glibc 環(huán)境下兼容性最好團(tuán)隊(duì)排查問題也更方便。如果條件允許后續(xù)可以把運(yùn)行階段換成 Chainguard 鏡像進(jìn)一步壓降系統(tǒng) CVE。這里真正容易踩坑的地方是不要為了“CVE 更少”而選一個團(tuán)隊(duì)不熟悉的基礎(chǔ)鏡像。鏡像能不能正常啟動比 CVE 數(shù)字多幾個少幾個更重要。先用最小改動替代一個大基礎(chǔ)鏡像再逐步激進(jìn)是更穩(wěn)妥的路徑。5. 依賴層加固鎖定版本、刪除冗余、生成 SBOM依賴層是 AI 項(xiàng)目 CVE 的第二大來源。一個 NanoClaw 鏡像里Python 依賴包數(shù)量通常在 100 到 300 之間其中一半以上是間接依賴。間接依賴的版本不可控是 CVE 追蹤困難的根源。5.1 用 pip-tools 鎖定直接依賴和間接依賴推薦的做法是維護(hù)兩個文件requirements.in記錄直接依賴requirements.txt記錄完全鎖定后的依賴清單。requirements.in示例flask3.0,4.0 openai1.30.0 requests2.31.0 pydantic2.5.0然后用 pip-tools 生成完整鎖文件pip install pip-tools pip-compile requirements.in --output-file requirements.txt生成的requirements.txt會列出所有間接依賴和精確版本號。構(gòu)建時用這個文件安裝兩次構(gòu)建拿到的依賴完全一致CVE 掃描結(jié)果也就可復(fù)現(xiàn)、可追蹤。如果需要進(jìn)一步防篡改可以在鎖文件里加入哈希校驗(yàn)pip-compile requirements.in --output-file requirements.txt --generate-hashes安裝時加上校驗(yàn)參數(shù)pip install --require-hashes -r requirements.txt這樣做的好處是保證依賴不會被中間環(huán)節(jié)篡改壞處是每次升級依賴都要重新生成哈希維護(hù)成本略高。對于面向公網(wǎng)發(fā)布的 AI 鏡像強(qiáng)烈建議開啟。5.2 移除運(yùn)行無關(guān)的依賴AI 項(xiàng)目中經(jīng)常出現(xiàn)“調(diào)試依賴”與“運(yùn)行依賴”混裝。比如pytest、ruff、ipython這類工具在本地開發(fā)時需要但不應(yīng)該進(jìn)入最終鏡像。把它們從requirements.in中拆出去放到requirements-dev.in中配合多階段構(gòu)建只安裝運(yùn)行依賴。判斷一個依賴是否該進(jìn)入鏡像的方法很簡單鏡像必須能獨(dú)立啟動服務(wù)但不需要跑測試和靜態(tài)檢查。凡是只在開發(fā)時使用的包全部排除。5.3 生成 SBOM 和鏡像簽名依賴鎖定解決的是可復(fù)現(xiàn)問題SBOM 解決的是可追溯問題。SBOM 的全稱是 Software Bill of Materials軟件物料清單。它把鏡像里的組件、版本、許可證、依賴關(guān)系整理成一份機(jī)器可讀的清單安全審計(jì)時可以快速定位某個 CVE 影響哪個組件。用 Syft 生成 SBOMsyft packages your-registry.com/nanoclaw-agent:v1.4.0 \ -o spdx-json nanoclaw-sbom.spdx.json生成 SPDX 格式的 SBOM 后可以把它作為制品和鏡像一起發(fā)布。更進(jìn)一步用 Cosign 對鏡像簽名保證鏡像本身和 SBOM 未被篡改cosign sign --key cosign.key \ your-registry.com/nanoclaw-agent:v1.4.0不要求立刻上容器鏡像倉庫的簽名校驗(yàn)完整鏈路但至少在 CI 里加上簽名這一步后續(xù)做準(zhǔn)入校驗(yàn)時就有了基礎(chǔ)。6. 用 Trivy 做基線掃描與 CI 門禁鏡像加固完成后最怕的是下次發(fā)布時 CVE 反彈。所以掃描和門禁必須嵌入 CI/CD。6.1 本地掃描驗(yàn)證先做一次本地掃描確認(rèn)改造效果trivy image --severity HIGH,CRITICAL \ --ignore-unfixed \ your-registry.com/nanoclaw-agent:v1.5.0參數(shù)說明--severity HIGH,CRITICAL只輸出高風(fēng)險(xiǎn)漏洞減少噪音--ignore-unfixed忽略上游還沒有修復(fù)補(bǔ)丁的漏洞避免把“無法解決”的歷史包袱算進(jìn)來。理想情況下這條命令的輸出結(jié)果應(yīng)該是 “Total: 0 (HIGH: 0, CRITICAL: 0)”。如果還殘留少量漏洞先確認(rèn)是不是基礎(chǔ)鏡像更新滯后。常見操作是把基礎(chǔ)鏡像重新拉取一次再觸發(fā)一次構(gòu)建掃描很多 CVE 會因?yàn)樯嫌午R像更新而消失。6.2 在 CI/CD 中加入阻斷門禁掃描命令加上--exit-code 1當(dāng)高危險(xiǎn)漏洞數(shù)量不為零時命令退出碼為 1流水線失敗trivy image --severity HIGH,CRITICAL \ --ignore-unfixed \ --exit-code 1 \ --format table \ your-registry.com/nanoclaw-agent:v1.5.0以 GitLab CI 為例可以在鏡像構(gòu)建階段后加入一個 scan 階段# 文件路徑.gitlab-ci.yml 片段 image_build: stage: build script: - docker build -t $IMAGE_TAG . - docker push $IMAGE_TAG image_scan: stage: test script: - trivy image --severity HIGH,CRITICAL --ignore-unfixed --exit-code 1 $IMAGE_TAG rules: - if: $CI_COMMIT_BRANCH main這樣每次合入主分支或發(fā)布版本時鏡像都必須通過掃描門檻。中危和低危漏洞可以記錄在掃描報(bào)告里不阻斷發(fā)布但要在發(fā)布記錄中注明。6.3 例外漏洞的治理即使做了多階段構(gòu)建和基礎(chǔ)鏡像替換某些 CVE 仍可能因?yàn)樯嫌我蕾嚿形葱迯?fù)而存在。此時不要直接關(guān)閉掃描而是通過.trivyignore文件管理例外并寫明原因# 文件路徑.trivyignore CVE-2024-0000 # 說明該漏洞僅影響解析惡意構(gòu)造的 X 文件功能本鏡像不處理用戶輸入文件 CVE-2024-1111 # 說明依賴 libfoo 1.2.3上游修復(fù)版本 1.2.4 尚未發(fā)布已建立升級計(jì)劃例外清單要定期評審隨著上游修復(fù)版本發(fā)布及時移除。一個 CVE 例外如果連續(xù)幾個版本仍然存在說明依賴已經(jīng)嚴(yán)重滯后應(yīng)該升級依賴而不是繼續(xù)忽略。7. 常見問題與排查思路在加固鏡像和接入掃描的過程中團(tuán)隊(duì)會遇到一些典型問題。下面的表格來自我們維護(hù) NanoClaw 鏡像時的真實(shí)排查記錄。問題現(xiàn)象可能原因排查方式解決方案Alpine 鏡像安裝 pydantic 失敗musl libc 不兼容部分 C 擴(kuò)展的預(yù)編譯 wheel查看 pip 安裝日志確認(rèn)是否觸發(fā)源碼編譯換用 slim-bookworm 或指定強(qiáng)制編譯參數(shù)鏡像啟動后提示 openssl 找不到精簡鏡像裁剪掉了系統(tǒng)證書或 SSL 庫docker run --entrypoint python image -c import ssl檢查安裝 ca-certificates確認(rèn)依賴庫已復(fù)制掃描結(jié)果與實(shí)際依賴不一致鎖文件未生成或構(gòu)建時使用了緩存對比 requirements.txt 與鏡像內(nèi)pip freeze輸出重新生成鎖文件構(gòu)建時關(guān)閉緩存Trivy 掃描出大量無法修復(fù)的 CVE基礎(chǔ)鏡像過舊或軟件包未更新重新 pull 基礎(chǔ)鏡像觸發(fā)重建定期更新基礎(chǔ)鏡像 tag跟蹤上游安全公告流水線掃描失敗但本地通過CI 中沒有登錄私有鏡像倉庫查看 CI 日志中的拉取錯誤在掃描前執(zhí)行鏡像倉庫登錄操作忽略策略不生效掃描命令未指定 ignore 文件路徑檢查 Trivy 是否讀取.trivyignore使用--ignorefile .trivyignore顯式指定切換 Distroless 后無法調(diào)試鏡像里沒有 shell使用debug版本或通過docker run --debug附加調(diào)試容器僅在排查時啟用調(diào)試鏡像運(yùn)行鏡像保持精簡這里特別想提醒的是“CVE 掃描為零”不一定是終態(tài)。只要基礎(chǔ)鏡像或依賴有更新一個舊鏡像的掃描結(jié)果很快會重新出現(xiàn)新的 CVE。所以掃描不應(yīng)該是“發(fā)布前的一次性動作”而應(yīng)該是“每次構(gòu)建的固定步驟”。建立這個習(xí)慣比某一個鏡像的 CVE 清零更重要。8. 生產(chǎn)環(huán)境的最佳實(shí)踐與工程建議完成一輪加固后如果團(tuán)隊(duì)負(fù)責(zé)的不只是 NanoClaw 一個鏡像而是多個 AI 服務(wù)鏡像下面這些建議可以直接復(fù)制到團(tuán)隊(duì)規(guī)范中。8.1 鏡像標(biāo)簽使用不可變版本生產(chǎn)環(huán)境用摘要不要在生產(chǎn)環(huán)境使用latest標(biāo)簽。latest指向的鏡像會漂移掃描報(bào)告和實(shí)際運(yùn)行鏡像對不上。發(fā)布時使用語義化版本標(biāo)簽docker build -t your-registry.com/nanoclaw-agent:v1.5.0 . docker push your-registry.com/nanoclaw-agent:v1.5.0更嚴(yán)格的團(tuán)隊(duì)可以記錄鏡像摘要并在部署 YAML 中固定docker inspect your-registry.com/nanoclaw-agent:v1.5.0 \ --format{{index .RepoDigests 0}}把輸出形如your-registry.com/nanoclaw-agentsha256:xxxx的地址寫到 Kubernetes Deployment 的image字段避免同一 tag 被覆蓋后產(chǎn)生漂移。8.2 非 root 與只讀文件系統(tǒng)加固后的 Dockerfile 已經(jīng)創(chuàng)建了appuser生產(chǎn)環(huán)境部署時還可以進(jìn)一步配置只讀根文件系統(tǒng)。在 Kubernetes 中設(shè)置readOnlyRootFilesystem: true、runAsNonRoot: true業(yè)務(wù)需要寫數(shù)據(jù)的目錄單獨(dú)掛載 volume# 文件路徑deployment.yaml 片段 securityContext: readOnlyRootFilesystem: true runAsNonRoot: true runAsUser: 10001 allowPrivilegeEscalation: false這個配置能保證即使鏡像里某個 CVE 被利用攻擊者也無法寫系統(tǒng)目錄也不能提權(quán)。8.3 組件責(zé)任到人CVE 治理最怕“人人都管人人都不管”。建議為依賴組件劃分負(fù)責(zé)人組件負(fù)責(zé)人更新頻率基礎(chǔ)鏡像平臺組每月更新一次 tagPython 依賴應(yīng)用開發(fā)者每周檢查安全公告SBOM/簽名CI 平臺組每次發(fā)布自動生成例外清單安全評審人每兩周評審一次8.4 掃描報(bào)告存檔CI 里每次掃描后生成 JSON 報(bào)告并歸檔保留至少 90 天。這樣后續(xù)安全審計(jì)時可以直接對比“上個版本有多少 CVE這個版本為什么多了兩條”。歸檔建議使用獨(dú)立的 S3 或?qū)ο蟠鎯δ夸洶寸R像名和版本號組織trivy image --format json --output \ reports/nanoclaw-agent/v1.5.0.json \ your-registry.com/nanoclaw-agent:v1.5.08.5 安全基線分級鏡像不是所有 CVE 都必須清零。生產(chǎn)環(huán)境建議關(guān)注“嚴(yán)重和高危清零”中危和低危按照修復(fù)成本和可利用性評估。如果中危漏洞只影響一個非網(wǎng)絡(luò)暴露的組件且沒有攻擊路徑可以把它列入例外并設(shè)置修復(fù)日期。但如果一個中危漏洞涉及網(wǎng)絡(luò)請求處理即使評分不高也要盡快修復(fù)。9. 總結(jié)與后續(xù)學(xué)習(xí)方向這次 NanoClaw 鏡像加固表面上是從 1,400 個 CVE 降到了個位數(shù)實(shí)際做的是把鏡像構(gòu)建從“能跑就行”變成了“可追蹤、可掃描、可治理”。核心動作就四個基礎(chǔ)鏡像精簡、依賴鎖定、運(yùn)行時權(quán)限收口、CI 掃描門禁。從 1,400 到 0真正改變的其實(shí)不是數(shù)字而是鏡像生產(chǎn)流程。如果你手頭的項(xiàng)目也有類似的鏡像漏洞積壓建議不要直接跳進(jìn)“逐條修復(fù)”的坑先做一次全量掃描把漏洞按來源分組然后從基礎(chǔ)鏡像和依賴層開始改。你會很快看到效果。下一步值得繼續(xù)深入的方向有三個一是鏡像簽名和準(zhǔn)入控制比如用 Cosign 在鏡像倉庫側(cè)做簽名校驗(yàn)二是把治理范圍從鏡像擴(kuò)展到整個軟件供應(yīng)鏈比如對基礎(chǔ)鏡像的來源和 SBOM 的真實(shí)性做驗(yàn)證三是用策略引擎自動處理例外清單比如把.trivyignore的變更納入評審流程避免“為清零而忽略”。容器鏡像安全沒有終點(diǎn)但有了基線、鎖文件和門禁每次新 CVE 出現(xiàn)時團(tuán)隊(duì)不再需要重新面對一份千級漏洞清單。希望這篇實(shí)踐記錄對你加固自己的鏡像有幫助。