北京
2024年，一個工程師偶然發現SSH登錄慢了500毫秒，順藤摸瓜揪出了幾乎成功的xz-utils供應鏈后門。這件事給所有開發者敲了警鐘：你手頭那五到十個副項目，依賴包可能正在悄無聲息地腐爛，而傳統的安全工具根本看不見。
Snyk、Dependabot這類工具只會追著已公開的CVE編號跑，但真正的供應鏈攻擊在爆發前往往同時亮起三盞紅燈：活躍高危漏洞、維護者棄坑、下載量斷崖式下跌。這三股信號碰頭時，風險就已成形，可市面上沒有一個工具能把它們聚合到一塊兒——直到有人用 Coral 寫了一條 SQL 查詢。
這條查詢花了六天打磨，最終在一個語句里聯查了三套實時系統：Google 的 OSV 漏洞庫、npm 包注冊表，以及 npm 下載統計 API。三個不同主機，零膠水代碼，出來的結果就是一個包的三維風險快照。舉個例子，minimist 這個 npm 包，直接查出 2 個已知 CVE，最高嚴重級別 CRITICAL，月下載量卻有 5.31 億次——典型的高懸頂炸彈。
查詢邏輯本身并不復雜：先用 CTE 從 npm 注冊表撈出包名、最新版本和最后發布時間；再去 OSV 按包名聚合 CVE 數量，同時取最高嚴重度對應的等級序號；再從 npm 下載 API 拿一個月內的下載量；最后左連接拼成一行。問題全出在實現細節上。
第一天就卡在了 OSV 數據源的定義文件上。Coral 允許用一個 YAML 文件描述外部 REST API 的返回結構，骨架寫得很快，但真跑起來才發現兩個坑。其一是自動扁平化并不存在——原本以為 database_specific 下的 severity 字段用雙下劃線命名 database_specific__severity 就能直接映射，結果始終返回 null。非得在 YAML 里顯式寫一個 expr，用 path 指定 [database_specific, severity] 才能正確提取。其二更隱蔽：受影響包的名字藏在 affected 數組的第一個元素里，取這個字段時，path 要寫成 [affected, "0", package, name]——索引得用字符串 “0”，用整數 0 會直接觸發 schema 校驗失敗。
coral source lint 能攔住 YAML 結構上的明顯錯誤，但這些嵌套路徑的匹配偏差，只能在對著真實包（比如 lodash、minimist）跑完查詢、把返回的字段和 spec 一行行手動比對時才會暴露。沒有任何自動化提示，全靠人肉 diff。
第二天面對的是 npm 數據源，這里讓作者直呼學到了最多。因為 npm 實際上需要對接的遠不止一個端點，后續的曲折讓他進一步看清，跨多個 API 對齊包名和統計口徑這件事，里面的坑比寫 YAML 多得多。
特別聲明：以上內容(如有圖片或視頻亦包括在內)為自媒體平臺“網易號”用戶上傳并發布，本平臺僅提供信息存儲服務。
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.
