比較
AI 與資安
AI 能幫上忙的地方,以及您需要確定性佐證資料的地方。
更新日期
每篇比較都會說明另一款產品的強項、CRACI 的不同之處,以及何時適合兩者並用。所有類別請見所有比較。
兩層架構,兩種工作
大多數資安團隊已經在導入 AI:用來審查程式碼、研判發現項目與撰寫修正。這是很好的用法。問題在於 AI 依據的是什麼。資安計畫需要兩層:
- AI 層:負責閱讀、解釋與行動,包括程式碼審查、分級研判與修正 pull request。
- 紀錄層:說明實際發生了什麼,也就是每次建置擷取了哪些相依套件,每次都以相同方式記錄,並指出紀錄不完整之處。
AI 在紀錄之上運作效果最好。本頁其餘內容與下方的指南,說明了每一層的強項所在。
資安資料的三項檢驗
離開工程團隊的資安資料,無論是用於稽核、客戶問卷或 CRA 報告,都必須通過三項檢驗。
- 可重現性。同一個問題問兩次,得到相同的答案。模型的輸出每次執行都可能不同;建置的紀錄則不會。
- 可稽核性。說明您如何得知。紀錄會指向它所來自的建置;推論出的答案則無法以相同方式交代推導過程。
- 完整性。您無法通報從未看到的東西。無論是 AI 工具還是掃描器,都無法列出從未出現在它面前的相依套件。
確定性是必要條件,但不是充分條件。SBOM 產生工具都是確定性的,結果卻彼此不一致,因此真正能補上缺口的是觀察:記錄建置拉取的內容,並在紀錄不完整時明確指出。CRACI 會將每個作業與快取標示為 Complete、Complete with connections、Incomplete、Unavailable 或 Not recorded。 AI 與確定性資安的比較,附實際範例
AI 擅長的地方
- 程式碼審查:處理忙碌的審查者會略過的閱讀工作,以 pull request 上的留言與建議呈現。
- 分級研判:以淺白的語言解釋資安公告,並排出優先查看的順序。
- 修正:撰寫變更、調整程式碼以因應破壞性升級,並開立 pull request。這些修正是否有幫助,取決於 AI 被要求修正什麼。 AI 漏洞修補
- 處理已記錄的 SBOM:摘要哪些元件帶有風險,並草擬相關文件供人員審閱。
需要紀錄的地方
- 「我們受影響嗎?」當新的資安公告發布時,答案必須涵蓋每一個拉取了該套件的建置,而不只是模型或掃描剛好檢視過的那些。
- AI 新增的相依套件。AI 程式設計助理會新增相依套件,有時還會寫出根本不存在的套件名稱。建置的紀錄會顯示實際下載了什麼。
- 稽核與客戶提問。稽核人員或客戶要的是能夠查核的佐證資料,而不是一段描述。
- CRA 下的 SBOM。AI 產生的 SBOM 只是對您建置的猜測;Cyber Resilience Act(CRA)與 2026 年 CISA 最低要素要求的是紀錄。 為何 AI 產生的 SBOM 不是佐證資料
原則很簡單:讓建置產生紀錄,再讓 AI 讀取它。 AI 資安工具與 CRACI 如何互相搭配
CRACI 與各工具比較
AI 與資安:常見問題解答
AI 工具能幫我撰寫 SBOM 嗎?
它能很快寫出看起來像 SBOM 的東西。但模型依據的是提供給它的程式碼與檔案,而不是建置實際擷取的內容,而幻覺是已有記錄的失效模式。主管機關與客戶要求的是產品所含內容的紀錄。請讓建置產生 SBOM,再讓模型讀取它。
AI 資安工具能取代 SCA 或建置佐證資料嗎?
不能。AI 程式碼審查、分級研判與修正 pull request 是資安計畫中實用的補充,但它們在完整且可重現的資料之上才能發揮最大效果。這兩層負責不同的工作,大多數團隊兩者都需要。
確定性的掃描器就足夠了嗎?
確定性是必要條件,但不是充分條件。SBOM 產生工具都是確定性的,結果卻彼此不一致,因為每個工具都自行決定什麼算是元件。確定性的掃描器可能每次都重現同樣不完整的答案。真正能補上缺口的,是記錄建置實際拉取的內容,並在紀錄不完整時明確指出。
CRACI 位於哪一層?
紀錄層。CRACI 取代 GitHub Actions 執行器,並由一個能辨識套件的代理伺服器在每個作業執行期間記錄其擷取的內容。產出包括作業所拉取內容的 SBOM、每個作業與快取的完整性狀態,以及網路追蹤紀錄。API 會回傳 SBOM、網路追蹤紀錄與來源證明。AI 工具可以在這份紀錄之上運作。