Uber開源了一個(gè)針對(duì)Claude Code、Cursor和Codex的安全監(jiān)控方案。這個(gè)方向非常實(shí)際現(xiàn)在很多公司都在批量引入AI編程助手模型代碼寫得好不好反而不是安全團(tuán)隊(duì)最操心的最擔(dān)心的是內(nèi)部代碼、密鑰、客戶數(shù)據(jù)會(huì)不會(huì)在開發(fā)過程中被IDE插件或命令行工具當(dāng)作上下文發(fā)到外部AI服務(wù)。適合看這篇文章的人主要有三類正在公司里做AI工具治理的安全工程師負(fù)責(zé)研發(fā)效能或內(nèi)網(wǎng)安全平臺(tái)的同學(xué)以及在私有化交付場(chǎng)景里需要評(píng)估AI工具風(fēng)險(xiǎn)的技術(shù)負(fù)責(zé)人。最值得關(guān)注的不是某個(gè)具體規(guī)則怎么寫而是Uber把“怎么發(fā)現(xiàn)、怎么記錄、怎么響應(yīng)”這條鏈路完整開源了出來。第一件事先說清楚我的判斷這類安全監(jiān)控方案的核心不是禁用一個(gè)工具而是讓AI編碼助手的使用過程變得可見。下面我從問題、落地、規(guī)則、排查和治理五個(gè)角度拆開講。1. 企業(yè)引入AI編碼助手后安全缺口到底在哪1.1 影子使用比模型輸出更容易出問題AI編碼助手和普通軟件很大的區(qū)別是它的工作方式天然包含“把本地代碼發(fā)送到遠(yuǎn)端”這一步。無論你用的是Claude Code的命令行交互還是Cursor這類IDE插件只要你讓它解釋代碼、補(bǔ)全邏輯、生成測(cè)試它就有概率把當(dāng)前文件、工程片段、相關(guān)注釋一起打包進(jìn)請(qǐng)求。這個(gè)行為對(duì)個(gè)人開發(fā)者很方便但在企業(yè)網(wǎng)絡(luò)里需要被納入審計(jì)范圍。我見過不少團(tuán)隊(duì)第一輪排查安全風(fēng)險(xiǎn)時(shí)只關(guān)注模型返回的代碼有沒有抄襲協(xié)議、有沒有不安全的API調(diào)用。實(shí)際上更常見的泄露路徑是開發(fā)者沒有意識(shí)到本地一個(gè)包含內(nèi)網(wǎng)IP、認(rèn)證串、業(yè)務(wù)邏輯注釋的配置文件會(huì)被當(dāng)作上下文發(fā)給模型服務(wù)商。傳統(tǒng)DLP方案往往覆蓋不了這類場(chǎng)景因?yàn)榱髁渴羌用艿陌l(fā)起者是終端上的開發(fā)工具出口又可能走CDN。Uber這次分享的方案本質(zhì)上就是把這個(gè)問題拆成了三層誰(shuí)在什么時(shí)候用了哪個(gè)工具請(qǐng)求里到底帶了哪些內(nèi)容命中敏感規(guī)則后有沒有進(jìn)入響應(yīng)流程。這三層缺一不可。只有進(jìn)程級(jí)監(jiān)控但看不到請(qǐng)求內(nèi)容容易產(chǎn)生大量無法判斷的告警只有請(qǐng)求內(nèi)容解析但沒做到身份綁定事后根本查不到人。1.2 Claude Code、Cursor、Codex 的監(jiān)控差異很多安全工程師拿到這類需求時(shí)第一反應(yīng)是“在邊界上攔一下就行”。真正落地就會(huì)發(fā)現(xiàn)這三個(gè)工具的監(jiān)控難點(diǎn)完全不同。Claude Code是命令行工具運(yùn)行在終端里權(quán)限和使用者的開發(fā)環(huán)境強(qiáng)相關(guān)。它讀取歷史記錄、配置、進(jìn)程參數(shù)都比較直接麻煩在于用戶可以自定義路徑、別名甚至通過包裝腳本調(diào)用日志目錄可能不統(tǒng)一。Cursor是圖形化IDE普及度高使用路徑更接近日常開發(fā)。它的難點(diǎn)在于請(qǐng)求往往不是用戶手動(dòng)觸發(fā)的而是補(bǔ)全、問答、重構(gòu)自動(dòng)觸發(fā)一次保存文件可能產(chǎn)生很多次請(qǐng)求。如果不做內(nèi)容聚合規(guī)則引擎會(huì)被大量低危事件刷屏。Codex同樣偏命令行和API但它的端點(diǎn)和模型配置經(jīng)常變化而且用戶可能會(huì)通過不同客戶端、不同環(huán)境變量來調(diào)用。監(jiān)控方案如果寫死了端點(diǎn)地址或者模型名工具一更新就會(huì)產(chǎn)生漏報(bào)。我把三者差異整理成了一張表方便在后面配置采集時(shí)對(duì)照工具類型主要形態(tài)監(jiān)控?cái)?shù)據(jù)源常見難點(diǎn)Claude CodeCLIshell歷史、進(jìn)程參數(shù)、配置文件、日志自定義路徑多進(jìn)程上下文復(fù)雜CursorIDE插件日志、IDE配置、網(wǎng)絡(luò)請(qǐng)求自動(dòng)觸發(fā)請(qǐng)求多需要內(nèi)容聚合CodexCLI/API命令調(diào)用、環(huán)境變量、API日志端點(diǎn)變化快多客戶端共存這里想強(qiáng)調(diào)一個(gè)容易被忽略的點(diǎn)不要一開始就追求工具級(jí)別的精細(xì)規(guī)則先把“工具名稱 用戶 時(shí)間 請(qǐng)求內(nèi)容”這幾個(gè)基礎(chǔ)字段采集完整后面做告警和分析時(shí)才有可回查的依據(jù)。2. 落地之前先把數(shù)據(jù)源和前置條件理清楚2.1 沒有數(shù)據(jù)源規(guī)則寫得再好也是空轉(zhuǎn)這套方案能不能落地很大程度取決于你拿得到哪些數(shù)據(jù)。根據(jù)我測(cè)試和部署這類監(jiān)控的經(jīng)驗(yàn)核心數(shù)據(jù)源有三類。第一類是終端側(cè)。最常見的做法是在統(tǒng)一管理的開發(fā)機(jī)上部署一個(gè)采集組件讀取常用AI編碼助手的工作目錄、日志文件、shell歷史和進(jìn)程命令行。優(yōu)點(diǎn)是對(duì)現(xiàn)有網(wǎng)絡(luò)改動(dòng)小缺點(diǎn)是覆蓋不全個(gè)人自帶設(shè)備、容器環(huán)境、遠(yuǎn)程開發(fā)機(jī)都會(huì)漏。第二類是網(wǎng)絡(luò)側(cè)。通過在出口或者代理層記錄訪問AI服務(wù)的請(qǐng)求能拿到完整流量。但如果啟用TLS解密就要面對(duì)證書信任、隱私合規(guī)、業(yè)務(wù)投訴等問題。很多公司卡在這里。我的建議是如果暫時(shí)不能解密至少把域名、源IP、用戶代理記下來作為終端側(cè)日志的補(bǔ)充關(guān)聯(lián)字段。第三類是工具側(cè)。Claude Code、Cursor、Codex都有自己的配置和日志體系有些還支持審計(jì)日志或者環(huán)境變量開關(guān)。工具側(cè)數(shù)據(jù)最精確但也最容易受版本升級(jí)影響。熱詞里那些“claude code版本不認(rèn)識(shí)某個(gè)模型名”之類的報(bào)錯(cuò)恰恰說明版本差異會(huì)直接影響工具自身的行為所以監(jiān)控模塊必須跟著工具版本走。采集完成之后需要先做一個(gè)數(shù)據(jù)質(zhì)量檢查。建議用一段已知敏感內(nèi)容通過某個(gè)AI編碼助手發(fā)一條真實(shí)請(qǐng)求然后去日志里查這條請(qǐng)求有沒有被完整記錄。不要急著寫很多規(guī)則。如果原始日志里連請(qǐng)求內(nèi)容字段都沒有后面所有正則和模型判斷都無從談起。2.2 權(quán)限、存儲(chǔ)、脫敏和賬號(hào)綁定除了技術(shù)數(shù)據(jù)源前置條件里最容易被低估的是賬號(hào)綁定。安全監(jiān)控要回答“誰(shuí)干的”不能只看來源IP。企業(yè)環(huán)境里開發(fā)人員可能通過跳板機(jī)、云開發(fā)環(huán)境、共享編譯機(jī)操作如果不綁定統(tǒng)一身份體系一條敏感代碼外發(fā)事件只能定位到一臺(tái)機(jī)器人會(huì)落實(shí)不到具體人。存儲(chǔ)也要提前規(guī)劃。AI編碼助手的請(qǐng)求內(nèi)容可能很多尤其Cursor這類IDE工具會(huì)自動(dòng)觸發(fā)補(bǔ)全。如果全量保存請(qǐng)求體存儲(chǔ)成本會(huì)迅速上升。可以按級(jí)別處理全量保存元數(shù)據(jù)只對(duì)有敏感命中的請(qǐng)求保存完整內(nèi)容。這樣才能兼顧調(diào)查需要和成本控制。數(shù)據(jù)脫敏和合規(guī)同樣要放在前面。監(jiān)控對(duì)象是開發(fā)者日常工作數(shù)據(jù)涉及源代碼和個(gè)人信息。落地前建議和法務(wù)、HR溝通清楚采集范圍、保留周期、誰(shuí)能訪問。不是我在這里講流程而是如果這一步?jīng)]做監(jiān)控方案本身可能變成新的合規(guī)風(fēng)險(xiǎn)。權(quán)限模型這塊我推薦一個(gè)最小化設(shè)計(jì)采集組件只能寫日志規(guī)則引擎只讀取日志告警系統(tǒng)按角色分組展示事件詳情頁(yè)只對(duì)安全調(diào)查人員開放。把每個(gè)環(huán)節(jié)的權(quán)限都收窄比事后補(bǔ)救靠譜得多。3. 從一條最小規(guī)則開始把監(jiān)控和告警鏈路跑通3.1 先做一個(gè)針對(duì)“密鑰外發(fā)”的驗(yàn)證規(guī)則當(dāng)我們討論“安全監(jiān)控”時(shí)很多人會(huì)直接想到模型分類器、AI檢測(cè)模型覺得要訓(xùn)練一個(gè)神經(jīng)網(wǎng)絡(luò)才能判斷代碼內(nèi)容是否敏感。實(shí)際落地時(shí)第一步往往是止損先用簡(jiǎn)單可靠的規(guī)則把最明顯的風(fēng)險(xiǎn)篩出來。比如云廠商AK/SK、私鑰片段、常見API Token。下面是一個(gè)簡(jiǎn)化示例用于說明規(guī)則引擎可以怎么組織。它和Uber開源方案不是一回事只做技術(shù)演示# 示例敏感數(shù)據(jù)檢測(cè)規(guī)則偽代碼 import re SENSITIVE_RULES [ (aws_access_key, re.compile(r(?i)AKIA[0-9A-Z]{16})), (private_key, re.compile(r-----BEGIN (RSA |EC |OPENSSH )?PRIVATE KEY-----)), (openai_api_key, re.compile(r(?i)sk-[A-Za-z0-9]{20,})), ] def check_request(text: str): hits [] for rule_name, pattern in SENSITIVE_RULES: if pattern.search(text): hits.append(rule_name) return hits把規(guī)則接入監(jiān)控鏈路時(shí)不要只記錄“命中”和“未命中”還要保存命中規(guī)則名、命中的原文片段、所在文件名或上下文。比如一條請(qǐng)求里包含了私鑰但文件名是test/fixtures/keys那它可能是測(cè)試數(shù)據(jù)誤報(bào)概率高。如果缺少這些上下文告警出來之后還得現(xiàn)去翻日志調(diào)查成本很高。3.2 告警分級(jí)和事件閉環(huán)規(guī)則跑通之后下一步是給事件分級(jí)。我建議分三檔高危命中私鑰、高可信云密鑰且請(qǐng)求對(duì)象是外部AI服務(wù)域名。中危命中Token格式但來自測(cè)試目錄或內(nèi)容為示例數(shù)據(jù)。低危命中URL、內(nèi)網(wǎng)IP關(guān)鍵詞沒有賬號(hào)上下文。分級(jí)的作用不是降低檢出標(biāo)準(zhǔn)而是讓安全團(tuán)隊(duì)在處理時(shí)有主次。告警一多如果沒有分級(jí)分析人員很快就會(huì)產(chǎn)生告警疲勞把中高危事件也漏掉。事件閉環(huán)至少要包括生成唯一事件編號(hào)、記錄原始請(qǐng)求頭、關(guān)聯(lián)用戶身份、通知責(zé)任人、標(biāo)記處理狀態(tài)、支持追加備注。很多監(jiān)控工具只做到彈告警這一步后續(xù)處置靠郵件時(shí)間一長(zhǎng)就變成“告警了但是沒閉環(huán)”。驗(yàn)證一條鏈路是否通暢可以用下面的方式構(gòu)造一條模擬請(qǐng)求包含一把測(cè)試密鑰通過實(shí)際工具發(fā)出去然后檢查日志是否完整采集、規(guī)則是否命中、事件是否生成、通知是否到達(dá)、詳情頁(yè)能不能看到原始內(nèi)容。五個(gè)環(huán)節(jié)都通過再考慮擴(kuò)展規(guī)則和覆蓋范圍。注意不要一上來就把幾十條規(guī)則全部推給所有團(tuán)隊(duì)。先用一條高置信度規(guī)則跑一兩個(gè)星期確認(rèn)誤報(bào)率可控之后再逐步增加規(guī)則和覆蓋率。4. 真實(shí)落地時(shí)最容易踩的坑和排查順序4.1 看著像規(guī)則問題實(shí)際是數(shù)據(jù)鏈路問題我自己的經(jīng)驗(yàn)是這類監(jiān)控方案在初期報(bào)錯(cuò)時(shí)絕大多數(shù)問題出在數(shù)據(jù)采集層而不是規(guī)則引擎。最常見的一種情況是安全團(tuán)隊(duì)配置好規(guī)則后發(fā)現(xiàn)一條告警都沒有。這時(shí)候先別高興先去確認(rèn)采集組件是不是真的在用戶終端上運(yùn)行。開發(fā)機(jī)裝了一堆工具但很可能是容器化開發(fā)環(huán)境采集組件只裝在宿主機(jī)實(shí)際請(qǐng)求發(fā)生在容器里。進(jìn)程級(jí)日志根本看不到。還有一種情況是工具更新導(dǎo)致日志目錄變化。舉個(gè)例子一個(gè)命令行工具升級(jí)后把日志從~/.config挪到了~/.local/share監(jiān)控組件還在舊目錄找文件自然什么都采不到。這就要求采集組件的配置項(xiàng)里路徑不能寫死至少要支持多候選目錄并且要定期驗(yàn)證數(shù)據(jù)新鮮度。熱詞里出現(xiàn)的“本地代理失敗”一類報(bào)錯(cuò)在安全監(jiān)控場(chǎng)景中也有參考意義。如果終端上有人配置了代理切換工具但沒有正確轉(zhuǎn)發(fā)AI工具的流量那么這條請(qǐng)求實(shí)際上沒有經(jīng)過你的代理日志。監(jiān)控側(cè)表現(xiàn)為“少了一條記錄”看起來像沒有敏感行為實(shí)際只是監(jiān)控盲區(qū)。4.2 規(guī)則太嚴(yán)會(huì)廢掉太松會(huì)漏規(guī)則誤報(bào)率太高分析人員會(huì)開始懷疑所有告警最終導(dǎo)致高危事件被忽略。規(guī)則太松則會(huì)出現(xiàn)大量“我們檢測(cè)到了但無法判斷是不是真的”的中間狀態(tài)。我比較推薦的做法是先用兩個(gè)星期歷史數(shù)據(jù)做規(guī)則回放看看每條規(guī)則在歷史請(qǐng)求里的命中率。如果某條規(guī)則命中率極高且大多數(shù)是誤報(bào)就縮小匹配范圍比如要求同時(shí)出現(xiàn)API Key和對(duì)應(yīng)域名特征。如果某條規(guī)則命中率極低要確認(rèn)它是真的沒發(fā)生還是因?yàn)樽侄螞]采集到。排查順序也可以固定成一套標(biāo)準(zhǔn)流程先確認(rèn)原始日志里有沒有這條請(qǐng)求。再確認(rèn)日志解析后有沒有把請(qǐng)求內(nèi)容字段提取出來。接著用相同樣本觸發(fā)一條規(guī)則看規(guī)則引擎能不能命中。然后看告警模塊有沒有生成事件編號(hào)。最后看通知和處置狀態(tài)。按這個(gè)順序走能在10分鐘之內(nèi)定位到90%以上的問題。最怕的就是跳過前面兩步直接改規(guī)則改完發(fā)現(xiàn)告警還是沒變化。4.3 工具本身的限制不要硬扛Claude Code、Cursor、Codex 都不是安全產(chǎn)品它們更關(guān)注開發(fā)體驗(yàn)。監(jiān)控方案如果強(qiáng)行依賴某個(gè)工具的私有接口或未公開日志很容易在升級(jí)后失效。遇到這種情況建議優(yōu)先考慮通用數(shù)據(jù)源比如進(jìn)程監(jiān)控、系統(tǒng)日志、代理日志把工具專用字段作為補(bǔ)充。5. 從“能監(jiān)控”到“能治理”還需要做哪些事5.1 把監(jiān)控結(jié)果接入研發(fā)流程安全監(jiān)控做到“能看到告警”只是第一步。真正有價(jià)值的落地是把結(jié)果接回研發(fā)流程。比如開發(fā)者在終端請(qǐng)求AI助手補(bǔ)全代碼時(shí)如果請(qǐng)求內(nèi)容里包含了生產(chǎn)環(huán)境的數(shù)據(jù)庫(kù)連接串采集組件不僅應(yīng)該記錄還可以通過IDE助手提示“當(dāng)前輸入可能包含敏感配置”在發(fā)送前攔截。這類能力對(duì)用戶體驗(yàn)影響很小但對(duì)數(shù)據(jù)防泄露的作用很大。再比如在CI/CD階段可以掃描提交信息和構(gòu)建日志看看構(gòu)建過程中是否有AI工具被調(diào)用以及調(diào)用內(nèi)容是否包含密鑰。這比完全在終端側(cè)監(jiān)控覆蓋得更全面因?yàn)楹芏郃I編碼請(qǐng)求發(fā)生在自動(dòng)化流水線里。5.2 用指標(biāo)判斷方案有沒有效監(jiān)控方案上線四周后建議用下面幾個(gè)指標(biāo)做一次驗(yàn)收覆蓋率安裝采集組件的開發(fā)機(jī)比例至少要知道未覆蓋范圍。采集有效性通過模擬請(qǐng)求驗(yàn)證采集成功率是否達(dá)到預(yù)期。規(guī)則命中率所有規(guī)則的命中次數(shù)、誤報(bào)率、待確認(rèn)比例。事件閉環(huán)率生成的事件里有多少完成了調(diào)查和處置。平均處置時(shí)長(zhǎng)從產(chǎn)生告警到確認(rèn)風(fēng)險(xiǎn)需要多長(zhǎng)時(shí)間。這些指標(biāo)不需要追求“零誤報(bào)”那是很難做到的。更合理的標(biāo)準(zhǔn)是高危事件不遺漏中危事件能追溯誤報(bào)率可以控制在團(tuán)隊(duì)能消化的范圍內(nèi)。5.3 開源方案和實(shí)際落地之間的差距最后說點(diǎn)現(xiàn)實(shí)的。Uber開源這個(gè)方案說明內(nèi)部已經(jīng)驗(yàn)證過效果但直接拿去部署到自己公司大概率會(huì)遇到三個(gè)差距。第一日志路徑和目錄結(jié)構(gòu)不一樣。不同發(fā)行版、不同安裝方式、不同用戶習(xí)慣會(huì)直接影響采集覆蓋率。第二身份體系和權(quán)限模型不一樣。Uber的方案假設(shè)有統(tǒng)一的賬號(hào)系統(tǒng)你如果還沒有需要先把身份關(guān)聯(lián)補(bǔ)上。第三規(guī)則庫(kù)和業(yè)務(wù)風(fēng)險(xiǎn)偏好不一樣。金融、游戲、傳統(tǒng)企業(yè)敏感數(shù)據(jù)定義完全不同規(guī)則必須自己調(diào)。所以我的建議是先把邏輯架構(gòu)吃透再做一個(gè)最小范圍POC最后再談全量推廣。不要指望一個(gè)開源倉(cāng)庫(kù)能直接解決所有問題。踩過幾次之后會(huì)發(fā)現(xiàn)很多所謂“監(jiān)控沒效果”的問題不是工具能力不夠而是前置數(shù)據(jù)和環(huán)境沒有處理干凈。先把“能看到一次完整的敏感事件”做扎實(shí)比堆花哨的模型和規(guī)則重要得多。