15年老兵把2.6MB漏洞報告壓到6KB

一個中等規模的代碼倉庫，安全掃描工具能吐出2.6MB的原始報告。里面塞滿了通過的測試、完整的語法樹、重復的路徑引用。把這些直接丟給大模型處理，賬單數字會很難看。

我見過太多團隊在這個環節栽跟頭。他們要么手動翻幾百頁PDF，要么干脆關掉警報當沒看見。15年做安全審計的經驗告訴我：80%的風險藏在20%的數據里，關鍵是怎么讓AI也明白這件事。

「Antigravity」這個名字的潛臺詞

這套工作流叫Antigravity，取自《哈利·波特》里讓羽毛飄起來的咒語。開發者想表達的意思很直白：讓沉重的安全審查變輕。不是消除重力，是找到對抗重力的支點。

核心邏輯就三層。第一層用開源掃描器做臟活——Gitleaks挖密鑰泄露、Semgrep找代碼模式漏洞、Checkov掃基礎設施配置、OSV查依賴風險。這些工具免費、成熟、各自有十年以上的社區打磨。

第二層用jq做數據壓縮。不是簡單的「過濾」，是結構化瘦身。原始JSON里嵌套的數組、冗余的字段、通過的測試結果全部剃掉，只保留四元組：規則ID、文件路徑、行號、嚴重級別。

第三層才是AI入場。但這時候喂給它的數據體積，已經從2.6MB壓到了6.3KB——壓縮比超過400:1。

具體命令長這樣，可以直接抄：

`jq '[.[] | {rule: .RuleID, file: .File, line: .StartLine}]' gitleaks-raw.json > gitleaks-min.json`

`jq '[.results[] | {rule: .check_id, file: .path, line: .start.line, severity: .extra.severity}]' semgrep-raw.json > semgrep-min.json`

`jq 'if type=="array" then map(.results.failed_checks[]) else .results.failed_checks end | [.[]? | {rule: .check_id, file: .file_path, line: .file_line_range}]' checkov-raw.json > checkov-min.json`

`jq '[.results[]?.packages[]?.vulnerabilities[]? | {rule: .id, file: .package.name, line: "N/A", severity: ((.database_specific.severity) // "N/A")}]' osv-raw.json > osv-min.json`

Token Economy：被低估的工程設計

大模型的計費單位是token。原始報告里一段完整的抽象語法樹（AST）可能占用幾千token，但AI分析漏洞時并不需要知道「這個函數在第幾層嵌套」，它只需要知道「第47行用了不安全的隨機數生成器」。

Antigravity的開發者管這個叫「Token Economy」——不是經濟學概念，是工程約束下的資源分配策略。省下來的token可以直接換算成錢：Gemini 3 Flash處理壓縮后的報告，成本是Pro模型的1/20，但輸出質量足夠做第一輪篩選。

更隱蔽的收益是上下文窗口。即使是最新的長上下文模型，塞進去2MB的原始JSON也會擠占分析空間。壓縮后的數據讓AI有余力做跨文件關聯——比如發現某個密鑰在A文件硬編碼、又在B文件被調用。

實際跑出來的文件體積對比：

Checkov原始報告2.6MB，壓縮后6.3KB；Gitleaks原始19KB，壓縮后2.4KB；Semgrep原始61KB，壓縮后4.3KB。OSV最極端，11KB原始數據壓到107字節——幾乎只剩骨架。

「一條命令」背后的設計取舍

Antigravity最終封裝成單行命令執行。這個「一行」是結果，不是起點。開發者在博客里坦承：最早的版本有七個手動步驟，每次跑完要切四個窗口看輸出。

現在的版本用GitHub Actions做編排，掃描→壓縮→調AI→生成報告，全流程自動化。但關鍵決策是故意不做的事：不自動修復漏洞、不集成到CI阻斷流水線、不存儲歷史數據做趨勢分析。

這些「不做」讓工具保持輕量。自動修復容易引入誤傷，CI阻斷會讓開發者繞過檢查，歷史數據存儲則涉及合規風險。Antigravity的定位很克制：快速給出一個「哪里有問題、嚴重嗎、建議先看哪」的清單。

開發者舉了個例子：某個倉庫掃描出47個潛在問題，壓縮后的數據讓AI在90秒內完成分級——3個需要立即處理，12個本周排期，剩下32個是低優先級或誤報。沒有這套過濾，同樣的分析可能要消耗價值幾十美元的token，還要等上十幾分鐘。

開源工具的「組合拳」哲學

Antigravity沒有造新輪子。Gitleaks、Semgrep、Checkov、OSV都是現有生態里的成熟項目，各自有數千星標和活躍維護。這套方案的價值在于編排邏輯：什么時候跑哪個工具、怎么統一輸出格式、如何讓AI理解不同工具的嚴重級別定義。

有個細節很有意思：四個掃描器的原始JSON結構完全不同。Gitleaks是扁平數組，Semgrep嵌套了多層results，Checkov的failed_checks位置隨輸入類型變化，OSV的漏洞信息埋在packages層級下面。用jq處理這種異構數據，相當于寫了一層輕量級的ETL（數據抽取轉換加載）。

開發者把這套jq腳本也開源了。對于需要定制化的人，可以修改字段映射規則——比如某些團隊更關心CWE編號而不是工具自帶的規則ID，調整幾行jq就能適配。

成本結構攤開看：

掃描階段零成本（開源工具），壓縮階段零成本（jq是系統自帶工具），AI調用階段按token計費。一個典型倉庫的完整審查，Gemini 3 Flash部分花費不到0.01美元，如果升級到Pro做深度分析，再加0.05-0.1美元。對比人工審計的時薪，或者商業SaaS的訂閱費，這個定價模型對中小團隊很友好。

但限制也很明顯。它不處理業務邏輯漏洞——比如某個API設計本身就有權限繞過問題，靜態掃描器抓不到。它也不替代滲透測試，只是把「明顯的問題」快速撈出來。

開發者在自己的倉庫跑了三個月，每周自動執行。累計發現的真實問題里，密鑰硬編碼占37%，依賴漏洞占29%，配置錯誤占21%，代碼模式問題占13%。這個分布和業界統計基本吻合，說明工具鏈的覆蓋是有效的。

有個意外的副作用：因為報告足夠輕量，團隊開始在代碼評審時隨手跑一遍。原本季度做的安全審查，變成了每次提交前的習慣動作。頻率提升帶來的收益，可能比單次深度掃描更大。