北京
大部分在線密鑰掃描工具都假裝幫你檢查泄露，卻先讓你把密鑰原封不動貼進一個陌生網頁里。你對著一個看不見的服務器交出了自己最敏感的信息，然后祈禱對方不會悄悄記下來——這場信任的諷刺，幾乎寫在每一行“請在此粘貼你的配置文件”的提示里。
如果你正是一個需要快速排查代碼倉庫中誤提交密鑰的開發者，眼前的難題并不復雜：檢測規則是否覆蓋你使用的平臺？掃描結果是否及時？整個過程會不會二次泄露？正反雙方常常在“便利性”和“安全性”之間拉鋸。
正方邏輯很直接：線上工具打開就掃，幾分鐘就能告訴我 AWS、OpenAI、GitHub Token 等關鍵憑證有沒有裸奔在外，而且多數還免費。我手上幾十個倉庫等著過一遍，哪有功夫自己搭一套離線掃描？先把泄漏堵上，剩下的信任問題可以容后再說。
反方則沒那么樂觀：你把密鑰原封不動地輸入到一個遠程服務里，哪怕界面再干凈、隱私政策再誠懇，背后的服務器依然可以完整記錄每一次請求。密鑰一旦被中轉，就和公開在日志里沒有本質區別。所謂“我們不會保存你的數據”，在用戶端根本無法核實，全憑運營方的道德自律。
devguard-scan 的設計者顯然站在反方這邊，但這次他沒搞說教，而是直接把工具做成一種可驗證的狀態。整個掃描跑在瀏覽器里，完全零網絡依賴，不會發出任何 fetch、XMLHttpRequest、WebSocket 或 sendBeacon 請求。開發者只需打開瀏覽器的開發者工具，切換到網絡標簽頁，拖入一段代碼掃描，就能親眼看到請求數為零——這個空蕩蕩的網絡面板，就是它的安全憑證。它沒有能力外傳密鑰，因為它從來就不往外呼叫任何一個網絡函數。
覆蓋面上，工具內置了10種檢測規則，精準對應 OpenAI、AWS、GitHub（經典令牌和細粒度 PAT）、Stripe、Google API、Slack 令牌及 Webhook、私鑰塊以及通用的賦值型密鑰等場景。這些規則不是粗糙復刻了某個 Python 掃描器的簡化版，而是直接把一套成熟的 Python 掃描正則集逐字節核對移植過來，讓“在瀏覽器里跑”這個便利條件不以犧牲檢測覆蓋為代價。用作者的話說，它只是改變了運行位置，卻沒有在規則上做任何妥協。
項目本身以概念驗證形式開放，使用 MIT 許可，所有源碼和規則請求都通過 GitHub 倉庫公開。用戶可以提 issue 申請增加新的檢測模式，這讓它看起來更像一個運動——呼吁安全工具別再靠一句“相信我”來扛口碑。畢竟在安全領域，設計上的可驗證性遠比口頭承諾更誠實：空白的網絡請求列表，比任何擔保合同都有說服力。
順著這個思路推演下去，或許還有不少開發工具值得被重新審視。那些號稱離線工作的本地工具，是否真的可以完全斷網運行？那些聲稱不收集遙測數據的 IDE 插件，如何讓用戶獨立確認？當越來越多的隱私聲明靠一行小字“我們重視您的數據安全”來兜底時，把“可證明”作為設計前提，可能才是下一個該流行的工程習慣。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
