#013 · 供應鏈核驗
驗證 Grok Build CLI 上傳使用者程式碼倉庫事件
安全研究者 cereblab 披露 Grok Build CLI v0.2.93 會把整個程式碼倉庫連同完整 git 歷史上傳至 xAI 雲端。分析人員基於 AVL Code 對該版本的離線安裝樣本做靜態分析，逐條核驗傳言與用戶端程式碼是否對應。
生成依據：AVL Code + 瀾砥大模型
Grok Build CLI供應鏈核驗資料外洩汙點傳播分析靜態分析
案例概述
面對 cereblab 公開的 Grok Build CLI v0.2.93 整庫上傳指控，手上只有一個 42.8 MB 的離線安裝包，沒有原始碼。分析人員基於 AVL Code 雙 Agent 並行核驗：一路擷取 cereblab 的復現倉庫與公開封包擷取證據，一路對樣本做解壓、熵值計算、字串與 IOC 擷取、ELF 解析，再把兩側逐條對照，約 20 分鐘完成從樣本指紋到汙點路徑的核驗。結論是上傳鏈路的零件在用戶端二進位中確實齊全——儲存桶 grok-code-session-traces、上傳端點 POST /v1/storage、獨立於模型通道的上傳開關、devstorage.full_control 憑證權限與 git bundle 打包能力一一對應；同時明確劃出邊界：靜態分析證明「能做」，「做了」仍需依賴 cereblab 的動態封包擷取證據。
核心成果
- 逐條核驗 8 項公開指控，6 項與樣本程式碼吻合，2 項如實標註為「部分可推斷」與「依賴外部動態證據」
- 在用戶端二進位中定位完整上傳鏈路：儲存桶 grok-code-session-traces、端點 POST /v1/storage、GROK_TRACE_UPLOAD_* 上傳開關與 devstorage.full_control 憑證權限
- 還原「工作區 → git bundle → GCS」汙點傳播路徑，指出讀取拒絕（--deny）攔不住檔案被打進 bundle 的權限錯位
- 雙 Agent 並行，約 20 分鐘從一個 42.8 MB 離線安裝包完成核驗，全程樣本在唯讀沙箱內分析
技術亮點
雙 Agent 並行（外部證據擷取 + 樣本靜態分析）熵值驗證解壓正確性（7.999 → 6.24）字串與 IOC 擷取定位上傳鏈路汙點源—傳播路徑—汙點匯建模樣本沙箱唯讀，拒絕在樣本目錄內執行命令靜態與動態證據邊界分離
落地價值
為企業評估閉源 AI 程式開發工具的資料邊界提供了一套可複核的方法：在只有安裝包、沒有原始碼的前提下，仍能回答「這套上傳機制在不在二進位裡」。該流程可複用於任何閉源用戶端的供應鏈核驗——把傳言拉回樣本與證據本身，在指控與實證之間留下可追溯的對照，而不是停留在轉述。
相關產物
會話回放與報告為簡體中文原始記錄 · 生成依據：AVL Code + 瀾砥大模型