比較
AI 資安工具會讀您的程式碼，但仍需要有東西記錄您的建置。
AI 程式碼審查與 AI 分級研判是資安計畫中實用的新工具。它們在完整且可重現的資料之上運作時效果最好，而 CRACI 正是位於這一層。
更新日期
您的團隊很可能已經在資安工作中導入 AI
現在大多數工程團隊的資安流程中，至少都有一個 AI 工具。一個模型審查 pull request，另一個為靜態分析警示提出修正建議，第三個則把掃描器的檢測結果分成「需要看一下」與「大概是雜訊」。這些工具確實節省時間，本頁也沒有任何反對它們的意思。
真正有用的問題是：哪些工作該交給它們，哪些工作需要一份每次產生結果都相同的記錄。與之相伴的問題是：當您的 AI 工具對相依套件做出判斷時，它們讀的是什麼。
AI 資安工具擅長的事
- AI 程式碼審查。GitHub Copilot code review 會在 pull request 上留下自然語言的評論與程式碼建議，也能依循儲存庫專屬的指示。它擅長處理忙碌的審查者會略過的閱讀工作。
- AI 修正。GitHub Copilot Autofix「會針對在 pull request 與預設分支上發現的 CodeQL 警示，自動產生程式碼變更建議」。開發人員會在警示旁看到建議的修補程式，而不是一個連到 CWE 頁面的連結。
- AI 分級研判。Semgrep 的 AI 功能會自動研判 Semgrep Code 的檢測結果並建議修正。Semgrep 的文件指出，其雜訊過濾「在將 Semgrep Code 檢測結果歸類為誤判時，準確率超過 95%」。
請留意後兩者的共同模式。Copilot Autofix 處理的是 CodeQL 警示，Semgrep 的分級研判處理的是 Semgrep 規則式引擎產生的檢測結果。AI 是在確定性輸出之上加入判斷，本身並不產生底層的檢測結果。
廠商自己怎麼說明限制
對 AI 工具的極限說得最清楚的，正是廠商自己，這一點值得肯定。
- 關於程式碼審查，GitHub 寫道「Copilot 可能無法找出程式碼中存在的所有問題」，並且「有產生幻覺的風險」，也就是會指出並不存在的問題。
- 關於 Autofix，GitHub 寫道它「使用非確定性的生成式模型。即使警示與程式碼相同，它也可能無法產生可行的建議，或每次嘗試產生的建議都不同」。
- 同樣關於 Autofix：「系統不知道哪些相依套件版本受到支援或是安全的，並可能建議以統計上看似合理的名稱發布的虛構相依套件。」
這些都不會讓這些工具變得比較沒用，而是界定了它們的工作：產生供人檢查的建議。這與產生供人比對依據的記錄，是不同的工作。
兩個層次，兩種工作
| 功能 | CRACI | AI 資安工具 |
|---|---|---|
| 回答的問題 | 這次建置取用了什麼？它是否已出貨？ | 這段程式碼或這項檢測結果是真正的問題嗎？ |
| 記錄建置取用的內容 | SBOM、網路追蹤記錄與來源證明資料 | 只能看到其他工具記錄下來的內容 |
| 相同輸入，相同輸出 | 不做任何推測 | 輸出可能不同，廠商自己的文件也這麼說 |
| 標示完整性 | 依作業與快取分別標示 | 僅限於提供給它的程式碼與檢測結果 |
| 審查程式碼邏輯 | Copilot code review 在 pull request 上留言 | |
| 檢測結果的分級研判 | 研判檢測結果並轉交給各團隊 | Semgrep Assistant 自動分級研判 |
| 最適合的用途 | 可交給稽核人員或客戶的佐證資料 | 供人工審查者採取行動的建議 |
- 支援
- 不支援
CRACI 位於記錄層。它取代 GitHub Actions 執行器（您只要將 runs-on 改為
craci），作業執行時，具備套件感知能力的代理伺服器會觀察建置連往套件來源的流量。
產出的是一份列出作業實際取用內容的 SBOM、每個作業與快取的完整性狀態，以及網路追蹤記錄。API 會回傳 SBOM、網路追蹤記錄與來源證明（provenance）。
需要確定性可視度的情境
「我們受影響嗎？」
當新的資安公告發布時，第一個問題就是您是否有任何建置包含受影響的版本。CISA 的 2026 年 SBOM 最低要素清楚說明了這項要求：SBOM 的接收者「若 SBOM 未列出該元件，應能據此斷定新通報的漏洞不會影響他們」。這個結論只有在清單完整時才成立。模型可以幫您解讀答案，但不應由它來決定建置中包含了什麼。
CRACI 彙整各建置與儲存庫的漏洞，並在新漏洞公開時重新評估受監控的 SBOM，因此這個問題是依據記錄下來的內容來回答。
由 AI 加入的相依套件
AI 程式設計助理會加入相依套件，而研究顯示，它們有時會提到根本不存在的套件。一項在 USENIX Security 2025 發表的研究，以 16 個模型產生了 576,000 個程式碼範例，發現幻覺套件的平均比例在商用模型中至少為 5.2%，在開源模型中則為 21.7%。今天不存在的名稱，明天就可能被人註冊。不論是誰或什麼加入了相依套件，CRACI 都會記錄建置實際下載的套件，而網路對外連線政策可以將作業限制在您核准的套件來源。
稽核與客戶提問
稽核人員或客戶的資安團隊會問您如何得知出貨的內容。「模型說的」是很薄弱的答案。「這是在發布建置期間記錄的 SBOM、它的完整性狀態，以及該作業的網路追蹤記錄」才是有力的答案。SBOM 可匯出為 CycloneDX 或 SPDX（包含漏洞），API 也會回傳 SBOM、網路追蹤記錄與來源證明。
可重現的答案
有些問題無論由誰、在何時提出，都需要相同的答案。上週二的版本發布取用了哪些套件？生成式模型可以把答案說得很好，但依其廠商自己的說法，它每次的說法可能都不一樣。記錄下來的建置只會給出一個答案。
兩者如何搭配
行得通的模式，正是 Copilot Autofix 與 Semgrep 已在採用的模式：底層是確定性的資料，上層是 AI 的判斷。
- 讓 AI 程式碼審查與 AI 修正在 pull request 上運作，每項變更都由人工核准。
- 讓 CRACI 記錄每次建置取用的內容，並標示該記錄是否完整。
- 當您希望 AI 協助評估相依套件風險時，請將記錄下來的 SBOM 提供給模型。CRACI 的公開 REST API 會回傳 CycloneDX 格式的 SBOM、作業的網路追蹤記錄，以及建置產物的來源證明。
- 保留記錄下來的 SBOM 作為佐證資料，而不是模型對它的摘要。
如果您的團隊有大量程式碼是透過 AI 助理撰寫，我們的 AI 開發資安頁面說明了這種情況，而 建置時 SBOM 產生則說明這份記錄是如何產生的。