AI 資安工具的不足之處，以及確定性建置佐證資料能涵蓋的範圍

把論點說得精確一點

這並不是反對在資安領域使用 AI。模型擅長閱讀程式碼、說明檢測結果並提出修正建議，善用它們的團隊動作也更快。我們的論點範圍更窄：對於日後必須站得住腳的記錄，機率式模型不適合作為主要來源。這包括您交給主管機關的 SBOM、您所出貨建置產物的來源證明，以及「我們是否受到影響？」這個問題的答案。

一份記錄是否站得住腳，取決於三項特性。以下各節分別探討其中一項，並附上範例與來源。

1. 可重現性：問兩次，得到相同的答案

資安記錄只有在其他人能以相同輸入得到相同答案時才有用。語言模型並不保證這一點，廠商自己也這麼說。

• Anthropic 的文件：「即使將 temperature 設為 0，結果也不會完全確定，相同的輸入在不同的 API 呼叫之間可能產生不同的輸出。」
• GitHub 對 Copilot Autofix 的說明：「即使是相同的警示與程式碼，它也可能無法產生可行的建議，或每次嘗試的建議都不相同。」
• 建立 SecLLMHolmes 框架的研究人員，為 IEEE S&P 2024 以 228 個程式碼情境測試了八個 LLM。他們指出這些模型「提供不確定的回應」，而且「僅僅變更函式或變數名稱，或在原始碼中加入函式庫函式」，PaLM2 與 GPT-4 就分別在 26% 與 17% 的案例中給出錯誤答案。

範例。兩位工程師詢問同一個助理，某項服務是否受到一則新資安公告的影響。一位得到「沒有」，另一位得到「可能有，請檢查遞移相依樹」。兩個答案都不是記錄，六個月後也都無法為稽核人員重現。

經過記錄的建置沒有這個問題，因為其中沒有任何推斷。CRACI 會在作業執行時觀察它從套件來源取用的套件，而 SBOM 就是這項觀察的記錄。

2. 可稽核性：說明您如何得知

稽核的關鍵在於「您如何得知？」這個問題。模型可以給出流暢的答案，但它的解釋並不是佐證資料。SecLLMHolmes 的評估發現，LLM 對其評估的漏洞會給出「錯誤且不忠實的推理」，因此即使結論正確，附帶的解釋也可能站不住腳。

標準正朝著能說明自身來源的記錄發展。由 CISA 與 NSA、FBI 及國際夥伴共同發布的 2026 年 SBOM 最低要素，新增了 SBOM Tool Name、SBOM Tool Version，以及 SBOM Generation Context，用來說明 SBOM 是在「建置前」（before build）、「建置」（build）期間，還是「建置後」（after build）產生。同一份文件也警告：「組織在風險管理決策中，可能會將錯誤納入考量，無論錯誤源自 SBOM 作者的做法，還是選用了不適當的工具。」

範例。一份客戶問卷詢問您的 SBOM 是如何產生的。「由助理讀取儲存庫後撰寫」雖然提供了產生情境，卻不是審查人員能夠查證的。「它是在發布建置期間於 CI 執行器內記錄的，而該作業的完整性狀態為 Complete」，則是審查人員可以對照建置來驗證的。

3. 完整性：您無法回報從未看到的東西

模型只能就它看到的內容進行推理。如果它讀取的檔案沒有描述軟體的全貌，答案也不會，而且輸出中不會有任何提示。CISA 的 2026 年指引以接收方的決策作為標準：他們「應能在 SBOM 未列出該元件時，判斷新回報的漏洞不會影響他們」。這只有在清單中沒有某元件就代表建置中沒有該元件時才成立。

範例。anthropics/claude-code 儲存庫在 v2.1.259 版沒有任何形式的相依套件 manifest 或鎖定檔（lockfile）。已發布的 npm 套件宣告了零個執行階段相依套件，並包裝了一個預先建置的原生二進位檔。任何讀取儲存庫的工具，無論是否為 AI，幾乎都沒有東西可列，而實際執行的程式卻是一個已編譯的二進位檔。

範例。AI 程式開發工具本身也可能造成這個缺口。GitHub 警告 Copilot Autofix「可能建議以統計上可能的名稱發布的捏造相依套件」。一項 USENIX Security 2025 研究分析了 16 個模型產生的 576,000 個程式碼範例，發現商用模型的套件幻覺率平均至少為 5.2%，開源模型則為 21.7%，共出現 205,474 個不重複的幻覺套件名稱。

確定性是必要條件，但不是充分條件

誠實地提出這個論點，就必須包含下一點。SBOM 產生工具是確定性的，但它們彼此之間仍然意見分歧。對同一個 expressjs/express commit 執行，它們可能回傳不同的清單，因為每個工具都自行決定什麼算是元件、該信任哪些檔案。該儲存庫沒有提交鎖定檔，因此依據鎖定檔解析相依套件的工具，完全沒有任何 package.json 相依套件可以回報。

確定性的掃描工具每次都會重現同樣不完整的答案。可重複性是必要的，但真正能彌補缺口的是觀察：記錄建置實際取用的內容，並在記錄不完整時明白標示。CRACI 會將每個作業與快取標示為 Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。

實際範例：界定一則新資安公告的影響範圍

假設情境：某個廣泛使用的 npm 套件的某個版本發布了資安公告。依據 Cyber Resilience Act（CRA），製造商必須在 24 小時內向 ENISA 通報遭積極利用的漏洞，因此界定影響範圍必須既快又正確。

AI 優先的做法

您請助理檢查您的儲存庫。它會讀取 manifest 與鎖定檔，或許還有 Dockerfile。它看不到從 CI 快取還原的套件、建置步驟下載的工具，也看不到在沒有鎖定檔的儲存庫中於安裝時解析的版本。問兩次，答案可能不同。它的摘要有用，但您無法據此簽署您的通報。

記錄優先的做法

CRACI 會在組織層級、以預設分支為範圍，跨建置與儲存庫彙整漏洞，並在新漏洞出現時重新評估受監控的 SBOM。API 會回傳每次建置的 CycloneDX SBOM、網路追蹤記錄與來源證明。如果某個作業的記錄不完整，其完整性狀態會告訴您該從哪裡手動檢查。您仍然可以請模型摘要結果，但它摘要的是一份記錄，而不是自行產生記錄。

有了記錄，「哪些發布版本出貨了這個套件？」這個問題只需要查詢，而不需要調查。

並列比較

讓每種工具發揮所長

在判斷力有幫助、且有人會檢查輸出的地方使用 AI：程式碼審查、說明檢測結果、草擬修正。在輸出必須能重現、能稽核，或必須被視為完整而加以倚賴的地方，使用確定性的建置記錄：SBOM、來源證明與資安事件影響範圍界定。CRACI 能為更廣泛的 CRA 流程自動化相當大一部分的供應鏈佐證資料，但它無法單獨讓您達到法規遵循。

在建置時 SBOM 產生中了解記錄是如何產生的，或從 CRA 的要求開始。