Omdia 2026 調查：77% 企業去年曾遇軟體供應鏈事件，AI 躍升頭號風險因子
Docker Blog（引用 Omdia《2026 Software Supply Chain Security Report》） · 2026-08-04
問題現況
Docker 於 2026 年 8 月 4 日發布部落格文章，整理研究機構 Omdia 針對北美 400 位 IT、資安與應用開發專業人士完成的《2026 Software Supply Chain Security Report》調查結果。數據顯示過去 12 個月內，77% 的受訪組織曾發生至少一次軟體供應鏈安全事件，其中 38% 的攻擊手法是利用第三方軟體中已知的漏洞。報告全文可於 Docker 官網下載，共 24 頁，涵蓋風險現況、事件衝擊、工具有效性與 SBOM 採用四大主題。
受訪者被問及最擔心的供應鏈風險來源時，AI 技術首次登上第一名，占 40%；第三方與開源程式碼占 39%，軟體依賴套件占 38%，三者差距不大，顯示風險來源已從單一開源套件擴散到整個 AI 開發鏈路。
關鍵數據
| 指標 | 現況 | 12 個月後預期 |
|---|---|---|
| 程式碼逾半來自第三方的組織比例 | 38% | 58% |
| 程式碼逾半為開源（OSS）的組織比例 | 31% | 51% |
在事件實際造成的衝擊上，46% 的組織遭遇應用程式或資料的未授權存取，37% 的服務等級協議（SLA）因為修復作業受影響，35% 則是開發者憑證、密鑰或機密外洩。工具有效性方面，僅有安全容器（secure containers）這一項，在 12 類資安工具中被過半數（51%）受訪者評為「非常有效」，其餘 11 類都未獲得多數認可。
- 42% 的組織將 SBOM（軟體物料清單）列為所有應用程式的強制產出項目，55% 則是視情況產生
- 73% 認為 SBOM 有助於更有效率地處理漏洞修復
- 72% 認為 SBOM 有助於落實安全控管與流程
- 68% 認為 SBOM 有助於滿足法規遵循要求
應對方向
調查也反映出責任正在下放：98% 的組織將「把安全左移給開發者」列為優先事項，其中 32% 視其為應用程式安全的首要任務。但開發者端的準備度並非全面到位——僅 45% 的開發者表示完全樂於承擔安全責任，38% 只是大致上可以接受；同時 45% 的資安團隊承認自己對開發者所使用的安全產品「僅有中等或更低程度」的影響力。62% 的組織預期未來將顯著加碼供應鏈安全投資，37% 則傾向較保守的投入幅度。
原始來源：Docker Blog、Omdia 2026 Software Supply Chain Security Report
CNCF：傳統 APM 看不懂 AI Agent，可觀測性要靠三支柱重建
CNCF Blog · 2026-08-04
核心改動
CNCF 部落格於 2026 年 8 月 4 日刊出文章，指出傳統應用效能監控（APM）工具是為固定的請求—回應流程設計，無法呈現 AI agent 的決策過程，因此提出重建 agent 可觀測性所需的三個支柱。第一項是追蹤（Traces）：完整記錄一次 session 內的模型呼叫、工具呼叫與子 agent 委派，並附上各步驟的耗時與成本；文章建議以 Langfuse 作為追蹤後端，且強調要用批次匯出器（batch exporter）非同步送出追蹤資料，避免同步發送 HTTP 請求拖慢工具執行本身。
第二項是成本（Costs），需要同時看兩個層級：單一 session 的總花費、token 用量拆解與模型分佈，以及跨 session 的彙總趨勢。文章主張成本控管要靠主動式的防護機制而非事後告警，例如硬性的迴圈次數上限、單一工具呼叫的預算上限，以及偵測連續重複呼叫的迴圈偵測機制，在超支前就先擋下 agent 的行為。
影響範圍
第三項是稽核（Audit）：對工具呼叫與治理決策做結構化、僅可附加（append-only）的紀錄，並在資料落地前先做 PII 淨化，確保紀錄可回溯又不外洩敏感資訊。文章同時提到以 Prometheus 匯出指標、Grafana 呈現儀表板，作為落實成本與稽核兩支柱的實作路徑。三支柱合起來的重點在於：AI agent 的失敗模式（例如陷入重複呼叫迴圈、或在多步驟推理中偏離目標）在傳統的請求/回應層級監控下幾乎不可見，必須把「決策歷程」本身當作一等公民來收集與展示。
原始來源：CNCF Blog
GitHub 推出 gh-stack：把巨型 AI 生成 PR 拆成可逐層審查的堆疊
GitHub Blog Engineering · 2026-08-04
核心改動
GitHub 工程部落格於 2026 年 8 月 4 日發文，作者 Julia Muiruri 指出 AI coding agent 常一次產出巨大、難以審查的單一 PR，解法是引導 agent 直接以堆疊式 pull request（stacked pull requests）產出程式碼——把一項工作拆成邏輯上有序、彼此可獨立審查的多層分支。文章以一個購物助理的商品搜尋功能為例，拆成四層：feat/catalog-data（型別化商品目錄與種子資料）、feat/search-api（/api/products/search 端點）、feat/chat-grounding（把 API 接進聊天回覆）、feat/grounded-ui（商品引用卡片與 UI 狀態），後一層皆依賴前一層。
對應的 CLI 工具是 GitHub 官方擴充套件 gh-stack，安裝方式為 gh extension install github/gh-stack。核心指令包括 gh init stack 初始化堆疊、gh stack add 逐層加入新分支、gh stack push 推送到遠端、gh stack submit 在 GitHub 上建立彼此連結的 PR。技術細節可參考官方文件 Stacked pull requests，其核心定義是「把大型程式碼變更拆成一串較小、彼此相依、可獨立審查與合併的 pull request」。
gh extension install github/gh-stack
gh init stack
gh stack add feat/search-api
gh stack push
gh stack submit影響範圍
當底層分支需要修改時，gh stack rebase 可在本機重新對齊堆疊——文章特別建議優先用這個指令而非透過網頁 UI 操作，以保留 commit 簽章；gh stack sync 則會把 rebase 結果與各層 PR 狀態一次串連更新。審查流程的建議做法是「由上往下讀、由下往上審」：先讀最上層掌握整體目標與情境，再從最底層開始逐層審查已完成的部分，每個 PR 的變更量都小到足以讓審查者維持專注，堆疊地圖（stack map）也提供跨關聯 PR 之間的一鍵導覽。
原始來源：GitHub Blog Engineering、GitHub Docs：Stacked pull requests