程式碼安全掃描有個長期被吐槽的毛病：誤報太多。安全團隊每天往開發群裡丟幾十條漏洞提醒，最後發現八成是虛驚一場。開發者起初還會點開看，後來乾脆全選忽略。這種"狼來了"式消耗，比不掃描更危險。
Checkmarx 最近釋出的 Next-Gen SAST，就是衝著這個問題去的。它不再只是換個規則庫或加幾個檢測模式，而是把三種掃描層疊在一起，先廣撒網，再精準篩，最終送到開發者面前的，只有被確認過的真實漏洞。
三層設計：先找到，再確認
第一層是 Checkmarx 多年積累的規則引擎。這類引擎講究一個穩，對 SQL 注入、跨站指令碼這些經典漏洞的識別已經非常成熟，而且每次掃描都能給出可解釋的命中理由。
第二層是專門調優過的 LLM。這個模型的主要任務，是覆蓋傳統規則跟不上的新程式碼形態——尤其是 AI 生成的程式碼。現在開發者用 Copilot 或 Codex 寫程式碼越來越普遍，AI 生成的程式碼在邏輯排布上往往和人類習慣不太一樣，老工具偶爾會漏掉。這一層就是為了兜住這些邊角。
第三層叫 Finding Analysis Engine，也就是 FAE。它把前兩層產出的所有候選結果收集起來，逐一做驗證，把真正能復現、真正構成威脅的挑出來，把"看起來像漏洞但其實安全"的濾掉。這一步在過去的 SAST 裡通常由人工來完成，現在交給了自動化引擎。
這三層並不是串聯的流水線，更像是一個漏斗——第一層負責不漏，第二層負責更全，第三層負責更準。最終輸出給開發者的，是經過三重確認的命中列表。
對開發團隊的實際價值
最直接的感受是，警報數量變少了，但每一條都值得看。對正在跑 DevSecOps 的團隊來說，這意味著安全負責人不用再花時間給開發擺事實講道理，解釋為什麼"這條警報不用修"。開發者也不用在碎片時間裡去排查那些無意義的告警。
另外，對大量使用 AI 輔助編碼的團隊，這一代的掃描器可以說正好踩在節點上。AI 生成的程式碼越多，安全盲區就越大，Checkmarx Next-Gen SAST 算是目前少數把"AI 程式碼檢測"當成一等公民來做的 SAST 工具之一。
少一次誤報，就多一分開發對安全團隊的信任。Checkmarx 顯然深諳這一點。
獲取方式對現有使用者非常友好：只要你的團隊在使用 Checkmarx One 平臺，這套能力會在現有訂閱裡直接解鎖，不需要額外付費，也不需要重新部署一套環境。對新使用者來說，這成了選擇 Checkmarx 的一個加分項，但最終值不值，還是要看它在自己專案裡的誤報率表現。
上手需要注意什麼
- 建議先在一箇中等規模專案上試點，把新舊引擎的誤報率、漏報率拉出來對比，用你團隊自己的資料說話。
- 如果你們公司有大量自定義安全規則，一定要確認這些規則能否被 FAE 的驗證層識別和處理——並不是所有規則都自動相容。
- 對 AI 生成程式碼的檢測能力，最好自己造一份包含 AI 生成程式碼的樣本庫來測，別隻依賴官方演示。
Checkmarx Next-Gen SAST 沒有發明新的掃描正規化，它只是把"減少噪音"這件事做到了更深的層次。在安全工具普遍讓人疲勞的今天，這種面向開發者體驗的優化，可能比增加幾個新的檢測外掛更能撬動實際安全水位。
評論
暫無評論
成為第一個評論的人