Docker Hardened Images 與 Black Duck 整合：VEX 資料自動消除容器掃描假陽性
Docker Blog · 2026-05-05
Docker 與 Black Duck 於 2026 年 4 月啟動整合，讓 Black Duck SCA 掃描器在識別到 Docker Hardened Images（DHI）作為 base image 時，自動引入 Docker 提供的 VEX 聲明資料以排除不可利用的漏洞，將 CVE 告警聚焦在應用程式層的真實風險，而非 base image 中已由 Docker 確認無影響的條目。
VEX 的運作機制
VEX（Vulnerability Exploitability eXchange）是一種標準化格式，用於說明已知 CVE 對特定軟體的可利用性狀態。Docker 為 DHI 維護 VEX 聲明，對每個 CVE 標記以下狀態之一：not_affected（漏洞存在但因系統加固或配置無法觸發）、fixed（已修補）、under_investigation（調查中）。當 Black Duck 掃描識別到 DHI 的 binary 指紋後，自動引入對應的 VEX 資料並抑制 not_affected 條目，無需人工介入。
技術架構
整合分為兩層分析：Black Duck Binary Analysis（BDBA）對編譯後的容器映像進行 signature-based 成分識別，無需原始碼；Black Duck SCA處理應用程式層的依賴關係圖。兩者合併後，系統可精確區分 base image 層與應用程式層的漏洞，並只針對應用程式自訂層的問題升級告警或觸發 pipeline gate。
VEX 資料的信任鏈設計同樣值得關注：Docker 提供的 VEX 聲明經由 Docker 的簽名機制保護，確保 VEX 內容的完整性。對於需要合規報告的場景（如 EU CRA、FDA 醫療器材軟體法規），此整合能輸出攜帶 VEX 狀態的高保真 SBOM。
實際效果
- 對使用 DHI 的團隊，掃描結果中的 not_affected 告警可大批量自動抑制
- Black Duck Security Advisories（BDSA）的分析通常比 NVD 資料早數天，提前預警視窗更長
- 支援觸發 Jira/email 工單、CI/CD pipeline 阻斷，條件可設定為僅針對可達路徑（reachable path）的漏洞
原始來源：Docker Blog
AI Agent 在 Kubernetes Bug 修復上的檢索策略基準測試：RAG vs. 全上下文 vs. 工具呼叫
CNCF Blog · 2026-05-08
CNCF 社群成員 Brandon Foley 於 2026 年 5 月發表基準測試，以 Kubernetes 真實 bug 修復任務評估三種 AI coding agent 的檢索策略：RAG（向量相似度檢索）、長上下文全輸入（full-context stuffing）與結構化工具呼叫（tool-based retrieval），量化各自在正確性、成本與延遲上的表現差異。
測試設計
測試集從 Kubernetes 的 GitHub issue 追蹤器中取樣已修復的 bug，要求 agent 在給定 issue 描述與相關程式碼片段的前提下生成正確的 patch。三種策略的核心差異在於如何向 LLM 提供必要的程式碼上下文：RAG 策略以 embedding 相似度檢索 top-k 程式碼段；full-context 策略將整個相關套件的原始碼塞入 context window；tool-based 策略讓 agent 自行呼叫 grep/AST 工具探索程式碼庫。
主要發現
RAG 策略在成本與延遲上最優，但在需要多跳推理（multi-hop reasoning）的 bug 上準確率下降明顯——向量相似度無法捕捉跨模組的因果依賴。Full-context 策略準確率最高，但 token 消耗量是 RAG 的 4–8 倍，且受限於 context window 上限，對大型 codebase 無法完整輸入。Tool-based 策略在準確率與成本間取得較好平衡，但依賴工具設計品質，呼叫鏈過長時延遲顯著上升。
影響範圍
這份測試提供了一個針對真實工程任務的對照框架。對 Kubernetes 本身而言，此類 agent 評估也有助於識別哪類 bug 適合 AI 輔助修復——測試結果顯示類型單純的 nil pointer 與邊界條件錯誤的修復成功率遠高於涉及複雜狀態機的問題。
原始來源：CNCF Blog