Qualys 將 AI 程式碼安全（AI Code Security）整合至 ETM

AI 驅動的程式碼安全已逐漸成為一個獨立的領域

目前業界的領頭羊包含 Anthropic 的 Claude Code Security 與 OpenAI 的 Codex Security，未來勢必有更多類似的工具問世。這些工具能以傳統靜態應用程式安全測試（Static Application Security Testing, SAST）難以觸及的深度來分析程式碼，進而發現傳統基於特徵的掃描器經常漏判的問題，例如：邏輯漏洞、無效的驗證機制、寫死在程式碼裡的機密資訊，以及複雜的注入攻擊路徑。

這種深度的檢測能力非常強大，但光是「發現問題」本身並不能算是實質的資安成效。如果這些漏洞只留在程式碼掃描工具裡，那充其量只是增加一個資訊孤島。真正能降低風險的關鍵，在於發現問題後的『處置作業』：必須將這些弱點精準關聯至對應的資產與負責人、與平台既有數據進行去重複化，並持續追蹤，直至完成修補。

這也正是 Qualys Enterprise TruRisk Management （ETM）的核心價值：專為處理跨資料來源、跨資產類別的資安風險而打造的平台。從架構設計之初，Qualys 就以支援多供應商與多資料來源為目標，目前已介接 CrowdStrike、Wiz、Microsoft、ServiceNow、AWS ，以及其他數十個品牌的資料。Anthropic 與 OpenAI 則是接下來要介接資料模型的供應商。Qualys ETM 之所以能無縫整合各種資料，關鍵在於其底層架構：它將資產與弱點進行標準化分類，並全面套用統一的 TruRisk 評分機制。

在 Claude 程式碼安全中執行掃描

Claude Code Security 的核心是針對程式碼儲存庫進行檢測。使用者只需將工具指向特定的程式碼儲存庫，選擇好分支（Branch）、模型以及檢測強度。掃描完成後，系統會產出一套結構化的檢測結果，完整包含嚴重性分級、漏洞位置、漏洞類型、詳細描述，甚至是 CWE Mapping，最後再匯出為 CSV 檔。

然而，找出漏洞只是基本功，如何落實後續的風險治理才是真正的考驗：在滿滿的檢測報告中，哪些漏洞需要優先修補？牽涉到企業哪些核心資產？而誰又是這項資產的實際負責人？

SAST 是首要的資料類型

在 Qualys 平台中，靜態應用程式安全測試（Static Application Security Testing, SAST）的掃描結果不會被歸類在通用的漏洞類別。Qualys 的資料模型將「應用程式 SAST」視為獨立類別，與主機資產、應用程式以及應用程式軟體組成分析（Application SCA）明確區隔。

圖 2. 在 Qualys 資料模型中，應用程式 SAST 被視為首要的資產類型。

這項設定背後的意義遠大於表面效益。因為「程式碼層級的弱點」和「主機漏洞」本質上完全是兩碼子事：在 SAST 的情境中，企業盤點的資產是程式碼儲存庫而不是伺服器；抓出來的問題是「某個檔案、某行程式碼的邏輯寫錯了」，而非「某個系統套件的既存 CVE」。因此，唯有將 SAST 獨立建模，才能端到端完整保留程式碼的語意結構與上下文脈絡。

即便市面上湧現各種 AI 驅動的程式碼安全工具，匯入的數據仍能直接對應至「應用程式 SAST」類別。資料匯入後即可套用平台既有的 TruRisk 風險評分機制、檢測規則、風險工作台（Workbench）以及 MITRE ATT&CK 威脅矩陣，協助企業實現真正一體化的無縫控管。

程式碼儲存庫成為 ETM 的類型化資產

連接器執行運作後，程式碼儲存庫將以「類型化資產（Typed Asset）」 的型態納入 Qualys ETM 資產清冊，而非僅以標籤的形式存在。

圖 3. ETM 中的 ai-qualys/juice-shop 範例。資產級別：應用程式，子級別：程式碼儲存庫。保留來源標註。

資產項目說明將全面套用在 ETM 對各類資產所進行的管理操作，包括：

• 資產關鍵度與 TruRisk 風險評分皆基於一致的主機、雲端工作負載和身分識別評估模型
• 完整的生命週期追蹤
• 商業架構對應，確保風險能對應至正確的權責單位
• 多來源情資整併能力，即便同一個程式碼儲存庫同時被三種不同的資安工具偵測，在系統中仍會維持「單一資產、三個資料來源」的註記，有效消除資訊碎片化。

標籤只能描述檢測結果，類型化資產則具備完整身分、生命週期、權責歸屬與風險評分。

此資產模型正是落實資安風險治理循環的核心關鍵。一個程式碼儲存庫今天透過 Claude Code Security、明天透過 Codex Security ，後天透過企業內部的 SAST 工具檢測，在系統底層架構中，只會是「具備三個資料來源的單一資產」，而非三個零散且互不相干的檢測結果。透過此模式，該儲存庫將擁有明確的負責人、隸屬的業務單位與動態的 TruRisk 風險分數，並直接整合至資安長每日研判的核心管理儀表板中，實現真正一體化的通盤控管。

檢測結果將納入風險管理內，並結合完整來源資訊

檢測結果會進入同一個風險管理平台，並包含主機漏洞、雲端配置錯誤、外曝身分和容器發現等資訊。

圖 4. 風險管理介面篩選範例：歸戶資料包括產品名稱「Claude Security」、廠商名稱「Anthropic」、資料來源「Claude Security」。

平台可針對「廠商名稱」、「資料來源」、「弱點類型」與「處理狀態」進行彈性查詢。這個統一介面查詢適用於所有來源，如 Wiz、CrowdStrike、ServiceNow，或是新介接的 Codex Security，皆能透過一致性的數據建模，將不同供應商的資產情資，納入同一個風險視角進行標準化呈現。

圖 5. 個別檢測結果匯總：每個都被歸類為「漏洞」型態，並基於 QVSS 進行評分，歸戶至 ai-qualys/juice-shop 應用程式資產。

每項檢測結果皆能無縫整合至分析師既有的風險營運組合中。包含「風險工作台（Risk Workbench）」、「MITRE ATT&CK 威脅矩陣」、「檢測規則」及「風險客製化設定」，皆能將這些檢測結果識別為原生物件。因此，從資料匯入完成的那一刻起，來自 Claude Code Security 的檢測結果便將與平台上的其他檢測資訊一致：具備統一的評分標準、優先級排序、可查詢性，並能轉化為實際的修補方案。

為何資料模型是決勝關鍵

隨著 AI 程式碼安全工具日益普及，Claude Code Security 與 Codex Security 等解決方案已逐漸成為市場主流，未來也將有更多供應商投入此領域。對企業而言，核心問題不再是「是否要導入這些工具」，而是「這些工具所產出的檢測結果，在匯入平台後應如何被妥善處理」。

Qualys ETM 透過三大核心架構，確保了數據處理的高效性與一致性：

1.類型化資料模型（Typed Data Model）：
平台將「應用程式 SAST」定義為獨立的首要資料型態，與主機、應用程式、SCA、雲端、容器及身分識別資產並列。Qualys ETM 完整保留了程式碼層級檢測結果的語意脈絡，不會為了適應傳統主機架構（Schema）而將其扁平化處理。

2.類型化資產模型（Typed Asset Model）：
Qualys ETM 將程式碼儲存庫視為具備獨立類別與生命週期的「實體資產」，而非只是弱點標籤。它具備與其他關鍵資產相同的管理維度，包括資產重要性、所有權歸屬、業務實體對應以及 TruRisk 風險評分。

3.多供應商整合設計（Multi-vendor by Design）：
Qualys 的連接器框架、供應商及情資歸戶模型和統一的 TruRisk 評分機制，已在超過百種正式營運情境中驗證多年。不論是 Anthropic、OpenAI 還是下一波新興的 AI 程式碼安全廠商，也將無縫對接至同一架構中。

在此架構下，AI 程式碼安全檢測結果不僅格式正確、來源歸戶精準，更依循與其他資產一致的評分模型，且明確歸屬至實際的資產實體與負責人。資安分析師無需學習新的作業流程，資安長也不必切換至額外的儀表板。既有的風險營運閉環將能無縫擴展，直接納管所有來源。

發掘弱點只是第一步，能落實後續處置才是降低風險的關鍵。 Qualys ETM 憑藉其類型化資料模型、類型化資產模型以及多供應商整合架構，成為企業實現跨場域風險治理的最佳利器。

後續發展方向

在資料匯入機制上，Qualys ETM 支援透過 API、Webhook 以及檔案式匯入實現自動化情資彙整。無論檢測結果透過哪種管道進入系統，平台皆會執行一致的去重複化、風險評分與工作流程套用，確保資料在掃描完畢後，平台能保持最新狀態。

情資的「即時性」至關重要，因為平台本身即是一套具備推理能力的決策分析架構。同時，Qualys 也為資安營運中心（ROC）分析師及資安長量身打造了 Qualys 網路風險助理 —— ROCky。

ROCky 運作於上述資安風險管理的平台上，能直接以自然語言回答各類提問，例如：「本週最重要的曝險項目為何？」、「和昨天相比，有哪些異動？」以及「哪些資產是某個特定來源的獨有項目？」。簡單來說，Qualys ETM 不僅能將來自 Claude Code Security 與 Codex Security 等多元來源的檢測結果整合於單一管理介面，更能讓 ROCky 針對這些彙總後的資料進行深度推理，並執行對應的防護決策，實現真正的智慧化風險治理。

參考來源：Qualys