容器工作流程中的 SBOM 生成：從建置時期到 OCI 倉庫的完整鏈路
Docker Documentation & Docker Blog · 2026-06-25
Docker 於 2026 年 6 月 25 日發布了一篇深度指南，說明如何在容器工作流程中產生高品質的軟體物料清單（SBOM）。根據 Omdia 2026 年軟體供應鏈安全報告，86% 的組織認為 SBOM 生成是一大挑戰，Docker 的官方指南直接從實作面切入，提供可落地的整合模式。
建置時期 vs. 建置後掃描：兩種方式的本質差異
SBOM 可以在兩個時間點產生：映像建置期間，或建置完成後對成品進行掃描。建置時期生成能夠取得完整的依賴解析樹與套件管理器檔案，因此輸出的 SBOM 更完整、版本更精確。建置後掃描則是對已完成的映像進行逆向工程，依賴套件中繼資料與檔案簽章判斷內容，可能遺漏靜態連結的二進位檔或中間建置層的 OS 套件。對於自行建置的映像，建議優先選擇建置時期生成；對於第三方或既有映像，掃描仍是唯一選項。
Docker BuildKit 透過 --attest type=sbom 旗標（或簡寫 --sbom=true）原生支援建置時期 SBOM 生成。以下指令會在推送映像時自動附加 SBOM 憑證（attestation）：
docker buildx build --tag <namespace>/<image>:<version> \
--attest type=sbom --push .若要在推送前驗證輸出，可使用本地匯出器將 SBOM 寫入本機目錄：
docker buildx build --sbom=true --output type=local,dest=out .這會在 out/ 根目錄產生 sbom.spdx.json。
SPDX 格式與 in-toto 憑證結構
BuildKit 預設使用基於 Anchore Syft 的掃描器外掛程式來產生 SBOM。輸出格式遵循 SPDX 標準，並以 in-toto 憑證的形式附加到映像，確保 SBOM 與映像摘要（digest）緊密綁定，隨映像在推廣管線中流動。憑證結構包含三個關鍵欄位：
- Statement type：
https://in-toto.io/Statement/v0.1 - Predicate type：
https://spdx.dev/Document - Subject：包含平台專屬摘要的映像參照
多段建置（multi-stage build）中，BUILDKIT_SBOM_SCAN_STAGE 建置引數可控制掃描範圍，例如僅掃描最終階段或指定命名階段（base,bin），避免將中間建置層的暫時性依賴混入最終 SBOM。
可操作 SBOM 的五項品質指標
指南列出評估 SBOM 是否真正「可操作」的五個維度：
| 指標 | 說明 |
|---|---|
| 完整性 | 涵蓋所有層與套件類型，包括 OS 套件、應用依賴及工具程式 |
| 精確性 | 記錄已解析的確切版本（如 4.17.21），而非宣告範圍（如 ^4.17.0） |
| 即時性 | 每次重建時重新產生，作為當下的快照 |
| 可驗證性 | 以加密方式簽署，透過憑證框架綁定到特定映像摘要 |
| 格式合規 | 通過 SPDX 或 CycloneDX schema 驗證，確保工具互通性 |
CI/CD 整合：五步驟標準流程
指南建議將 SBOM 的產生與驗證嵌入 CI/CD 管線，分為五個步驟：建置時產生、選擇憑證格式、附加到 OCI 倉庫、發布前驗證、持續掃描與強制執行。格式選擇上，容器映像預設使用 SPDX，安全掃描工作流程則優先考慮 CycloneDX。
推送至 OCI 倉庫後，SBOM 可透過以下指令直接查詢：
docker buildx imagetools inspect <namespace>/<image>:<version> \
--format "{{ json .SBOM.SPDX }}"這樣 SBOM 便與映像本身一同在倉庫中流動，不需維護額外的旁側儲存（sidecar storage）。
生成工具本身也是攻擊面
指南特別提醒，SBOM 生成工具在建置期間擁有高度存取權限，自身也構成供應鏈風險。應固定至不可變的參照（commit SHA），而非版本標籤；執行前驗證校驗和；並僅在 CI 環境中執行，避免在開發者本機產生不一致的結果。
法規合規驅動需求
美國行政命令 14028 要求銷售給聯邦機構的軟體須提供 SBOM；歐盟《網路韌性法》（Cyber Resilience Act）將要求延伸至所有含數位元件的產品；EU AI Act 的技術文件要求也讓元件層級清單成為 AI 工作負載的實際必要條件。
原始來源：Docker Build SBOM Attestations 文件、Docker Blog：SBOM Generation for Container Workflows
Podman 6.0 正式發布：設定檔架構全面重寫，移除多項舊版依賴
LWN.net / Podman Blog · 2026-06-25
Podman v6.0.0 已於 2026 年 6 月正式釋出，LWN.net 於 6 月 25 日刊出詳細報導。此版本帶來設定檔處理機制的全面重寫、多項新功能，以及大量破壞性變更（breaking changes）——包括移除 BoltDB、iptables、CNI 網路與 cgroups v1 等舊版元件。
設定檔處理機制大改造
Podman 6.0 最核心的變動是統一了 Podman、Buildah 1.44、Skopeo 1.23 三個工具的設定檔解析邏輯。過去各工具對設定檔的查找路徑與合併行為不一致，新版本引入一致的查找順序：
/usr/share/containers（發行版預設）/etc/containers（系統管理員設定）$XDG_CONFIG_HOME/containers或$HOME/.config/containers（使用者設定）
同時新增了 root 與 rootless 專屬目錄，讓不同使用者類型可以擁有獨立設定，不互相干擾。
三個主要設定檔的破壞性變更
containers.conf 現在只讀取優先序最高的單一設定檔，不再合併所有層級的設定。舊版的 containers.rootless.conf 檔案遭棄用，替換為 drop-in 目錄支援。
storage.conf 中的 rootless_storage_path 欄位已被廢棄，改以 storage.rootless.conf.d/ 下的 drop-in 檔案取代。有預設路徑的發行版必須將 root 專屬設定遷移至 storage.rootful.conf.d/。
registries.conf 移除了對舊版 v1 語法的支援，強制要求使用 v2 語法。registries.d、policy.json、certs.d 也新增了對 /usr/share/containers 的查找支援。
新功能：GPU 支援、多 IP、Quadlet 增強
功能面，v6.0.0 新增對 AMD GPU 的 --gpus 旗標支援，補齊了此前只支援 NVIDIA 的缺口。容器現在可以配置多個靜態 IP 位址，同時支援黑洞（blackhole）與不可達（unreachable）路由類型，滿足更複雜的網路隔離需求。Quadlet 功能也獲得擴充，新增匿名卷支援、UID/GID 設定選項，以及供發行版打包使用的新搜尋路徑。
磁碟區管理同樣有所改善：podman volume prune 新增 --all 與 --dry-run 選項；podman machine os update 指令讓使用者可以在不重建 VM 的情況下更新虛擬機器作業系統。
移除的舊版元件與平台支援
此版本移除了多個已長期標記為棄用的元件：
- BoltDB 資料庫後端
- iptables 網路後端
- CNI 網路驅動程式
- cgroups v1 支援
- slirp4netns 網路工具
- Intel Mac 與 Windows 10 平台支援
網路隔離現在預設啟用，Go 匯入路徑也從原本路徑變更為 go.podman.io/podman/v6，對直接依賴 Podman Go 函式庫的專案有影響。
安全性修補
此版本修復了環境變數洩漏漏洞 CVE-2026-57231，同時修正了 Quadlet 模板依賴問題、容器檢查點一致性問題，以及多次掛載時卷掛載選項的洩漏問題。
原始來源：Podman v6.0.0 Release Notes、Podman Blog：Configuration File Changes
在 Kubernetes 叢集內自建 AI 代理：Argo CD、GitOps 與本地 LLM 的整合實踐
CNCF Blog · 2026-06-25
CNCF Ambassador、RELEX Solutions 首席雲端工程師 Maryam Tavakkoli 於 2026 年 6 月 25 日在 CNCF 部落格發表了一套完整的叢集感知 AI 代理實作方案。該方案讓 AI 代理在 Kubernetes 叢集內部運行，透過 Kubernetes API 取得即時狀態，使用本地 LLM 進行推理，所有資料完全不離開叢集。
LLM 與代理的本質差異
文章首先釐清一個常見混淆：LLM 僅根據訓練資料回答問題，而代理（agent）會先觀察環境、取得上下文，再進行推理。這套系統提供兩個端點來體現這項差異：/ask 用於一般 Kubernetes 知識問答（不需叢集狀態），/diagnose 則先抓取叢集中的即時 pod 狀態、事件與日誌，再連同使用者問題一起送入 LLM。
技術架構：Ollama + FastAPI + 唯讀 ServiceAccount
Runtime 層由兩個元件組成：Ollama 在連接埠 11434 本地提供 Mistral 7B 模型推理，FastAPI 在連接埠 8000 對外暴露 HTTP 端點。
RBAC 設計採取最小權限原則——ServiceAccount 僅持有 get 與 list 的 ClusterRole 權限。如作者所言：「能夠根據自身推理刪除 pod 的代理，就是一場等待發生的生產事故。」這個設計哲學確保了代理只能觀察，不能變更叢集狀態。
API 端點清單如下：
POST /ask：通用 Kubernetes 知識問答POST /diagnose：帶叢集即時上下文的診斷分析GET /health：服務健康檢查GET /models：可用模型列表
GitOps 交付管線：GitHub Actions + Argo CD Image Updater
交付層遵循標準 GitOps 三段式架構：GitHub Actions 負責建置多架構 Docker 映像並以 commit SHA 作為標籤推送至倉庫（CI）；Argo CD Image Updater 持續輪詢倉庫，偵測到新映像後自動更新 Git 中的 manifest（促進）；Argo CD 從 Git 倉庫同步叢集狀態（CD）。這種模式讓 Git 成為唯一的真相來源，每次部署都有對應的 commit 可追溯。
硬體需求與首次部署注意事項
由於需要在叢集內跑 Mistral 7B，此方案對資源有一定要求：最低 8 GB RAM（建議 16 GB），以及 20 GB 以上的磁碟空間供 LLM 模型使用。首次部署時，Ollama 拉取模型需要 5 到 10 分鐘；部署步驟包括安裝前置工具（kubectl、minikube、helm、argocd）、建置並推送映像、安裝 Argo CD、註冊倉庫，最後部署 Argo CD Application 資源。
平台工程視角的意義
這套方案展示了一個重要趨勢：將 AI 推理能力嵌入平台層而非應用層，讓開發團隊無需建置自己的 LLM 基礎設施，即可獲得叢集感知的診斷能力。同時，選擇本地部署 LLM 而非呼叫外部 API，直接解決了敏感的日誌與 pod 資料外洩疑慮，適合對資料主權有嚴格要求的企業場景。
原始來源：github.com/MaryamTavakkoli/local-k8s-ai-agent、CNCF Blog