在人工智慧輔助開發（AI-assisted development）普及的今天，軟體開發的速度與數量呈指數級成長。然而，當 AI 代理人（AI Agents）開始能直接生成程式碼、修改基礎設施甚至處理系統故障時，企業面臨的挑戰已不再是如何快速產出代碼，而是如何證明這些軟體的來源、建構過程以及是否符合安全規範。針對此議題，IBM 與 Red Hat 近期宣布擴展其 Lightwell 專案，將其從開源計畫轉化為包含商業服務的完整方案，旨在為 AI 時代的軟體交付生命週期建立一套可驗證的信任基礎設施。
背景與 AI 帶來的安全挑戰
傳統的軟體供應鏈安全主要聚焦於防止惡意程式碼進入建構管線，通常依賴程式碼審查或漏洞掃描等事後檢查。但在 AI 驅動的自動化流程中，軟體變更的頻率大幅增加，單靠人力審查已不切實際。更重要的是，當 AI 參與開發時，企業需要明確知道「是誰」或「哪個 AI 實體」執行了操作、使用了什麼身份以及是否遵循了既定政策。
這種環境使得信任的定義發生轉變。信任不再是發布前最後一關的安全檢查，而應成為一種伴隨軟體從開發到部署全過程的屬性。因此，建立一個能追蹤軟體來源、確保未經篡改且符合合規要求的信任架構，成為企業在 AI 時代生存的基礎能力。
Lightwell 的核心運作與技術整合
Lightwell 並非試圖發明全新的安全概念，而是將過去數年業界已有的多項安全標準整合進一個統一的平台中，將原本碎片化的工具轉化為協同運作的治理體系。其核心目標是將軟體簽署、來源證明與政策執行整合在一起，讓組織能驗證交付過程中的每一個階段。
在技術實作上，Lightwell 整合了多項關鍵標準：首先是 Sigstore，這是一個用於對軟體產出物進行數位簽署的框架，解決了金鑰管理複雜的問題；其次是 in-toto，它提供了一套紀錄軟體供應鏈步驟的框架，確保建構過程符合預期。此外，Lightwell 亦採用了 SLSA（Supply-chain Levels for Software Artifacts），這是一套定義軟體產出物安全等級的標準，用以量化供應鏈的抗篡改能力。最後是 SBOM（Software Bill of Materials，軟體物料清單），它像是一份詳細的成分表，列出軟體中所有包含的開源組件及其版本，讓企業能迅速掌握依賴項的風險。
透過將這些標準商業化並平台化，Lightwell 讓企業無需自行拼湊多個開源專案，即可實現產出物簽署、來源證明生成、政策驗證以及全生命週期管理。
實務意義與產業趨勢
Lightwell 的擴展反映了軟體工程的一個重大演進：從「信任程式碼」轉向「信任流程」。在 AI 代理人能自主貢獻代碼的未來，加密證明（Cryptographic Attestations）與工作負載身份（Workload Identity）將變得至關重要。這意味著每一行代碼、每一次基礎設施的變更都必須有對應的加密證據，證明其是在核准的環境中、由授權的身份所產生。
這種趨勢在整個產業中已成共識。例如 GitHub 透過 CodeQL 與產出物證明強化追蹤能力；Google 積極推動 SLSA 與 Sigstore 的普及；Microsoft 則將簽署與來源證明整合進 Azure DevOps 與 GitHub Advanced Security 中。甚至 Linux 基金會的 Akrites 專案也在探索如何利用加密信任模型來抵禦 AI 驅動的新型威脅。這些嘗試共同指向一個目標：軟體之所以值得信任，不應僅僅因為它能正常運行，而應是因為其從源頭到部署的整個生命週期都是透明且不可篡改的。
影響與限制
對於企業而言，導入如 Lightwell 這樣的信任架構能顯著降低 AI 生成代碼帶來的治理風險，使自動化交付過程變得可問責。然而，這也對組織的運維能力提出了更高要求。實施這套體系需要將「政策即代碼」（Policy-as-Code）的理念深植於開發文化中，而非僅僅安裝一個工具。
此外，雖然 Lightwell 整合了多項標準，但其成效仍取決於整個生態系統的參與度。如果上游的開源組件沒有提供標準的 SBOM 或簽署證明，下游的驗證鏈條就會出現斷層。因此，建立信任基礎設施不僅是單一企業的技術選擇，更是整個軟體供應鏈協作模式的升級。
總結來說，IBM 與 Red Hat 的動作預示了未來軟體安全的重心將從單一的安全工具轉向全面的信任架構。在 AI 加速開發的浪潮下，唯有建立起可驗證的供應鏈，企業才能在追求速度的同時，確保系統的安全性與合規性。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。