問題與範圍
平台接入數百萬個儲存庫。每個儲存庫可提交鎖定檔、映像檔清單或 SBOM；漏洞來源會新增、修訂、撤回記錄。請設計從清單攝取、版本匹配、告警產生到通知和修復驗證的系統。預設支援 npm、PyPI、Maven 三種生態；程式碼掃描、全自動合併補丁和漏洞人工判定不在範圍內。
面試官在考察什麼
重點是把「依賴版本命中漏洞」與「告警生命週期」分開。版本區間、生態規範化、直接與傳遞依賴、漏洞修訂和撤回都會改變結果；不能把單次掃描當成永久事實。高品質回答還會說明去重鍵、可重播攝取、通知冪等、權限隔離和修復後重新驗證。
回答前要澄清的問題
- 清單是鎖定版本還是允許範圍？匹配實際解析版本還是宣告範圍？
- 是否辨識傳遞依賴、開發依賴、容器映像層和私有套件？
- 漏洞來源是否允許撤回、別名和嚴重性修訂？歷史告警保留哪個快照？
- 多個分支如何歸併？刪除分支後告警是否保留？
- 通知渠道、頻率和組織級靜音規則怎麼定義？
30 秒回答框架
「我會把清單正規化成不可變快照，按生態解析依賴圖，再用版本區間索引匹配漏洞記錄。匹配結果寫成冪等告警投影，鍵包含儲存庫、依賴、漏洞和受影響版本快照；漏洞修訂觸發增量重算。攝取、漏洞更新和通知都透過可重播的持久佇列，通知按組織策略聚合並帶冪等鍵。告警保留證據快照，修復驗證重新掃描目前提交，同時用權限檢查、對帳和延遲指標保證可解釋性。」
分步深入設計
控制面保存組織、儲存庫、分支和通知策略。攝取 API 接收帶提交雜湊的清單，先寫物件儲存和中繼資料，再發佈 manifest_received 事件。相同儲存庫、分支、提交和清單摘要重複提交時回傳既有快照，不重複建立掃描工作。大型 SBOM 使用分片上傳和校驗，租戶配額防止惡意超大清單拖垮解析器。
解析器按生態規則正規化名稱與版本，並展開鎖定的傳遞依賴。每個快照產出標準化元件座標、來源位置和開發／生產範圍。解析失敗要保留原始檔、錯誤位置和可重試狀態；不能把「無法解析」當成「沒有漏洞」。
漏洞攝取器從 OSV 等來源拉取或接收增量，驗證 schema、來源簽名和版本號。漏洞記錄包含受影響生態、套件名、版本區間、別名、嚴重性、修復版本、發佈時間、更新時間和撤回標記。區間匹配使用生態感知比較而非字串排序，並為高頻元件建立倒排索引。
告警至少包含 alert_id、組織、儲存庫、分支、元件座標、漏洞 ID、證據快照、狀態、首次發現、最近確認、修復提交和規則版本。(repository, branch, component, vulnerability_id, vulnerable_version) 唯一約束防止重複告警；別名集合先歸一化。撤回不抹掉歷史，只停止新通知並顯示依據。
通知不放在掃描交易內。告警事件進入按組織分區的佇列，由聚合器按策略合併相似告警、設定冷卻窗口並產生穩定通知鍵。郵件、程式碼託管評論和聊天適配器各自限流、重試和記錄投遞結果；消費者以通知鍵冪等。靜音規則必須有期限、操作者和稽核原因。
修復驗證接收新提交或定期快照，重新解析依賴圖並執行相同匹配規則。只有目前預設分支快照不再命中，或組織明確接受風險，告警才可關閉。修復版本只是建議，不能取代實際掃描。
可靠性依賴可重播事件和對帳。對帳任務比較已存清單、解析結果、匹配結果和告警投影的計數；比較漏洞來源版本與本地版本；比較應發通知與適配器回執。監控清單到告警的 p95 延遲、解析失敗率、漏洞更新積壓、重複率、撤回傳播延遲和通知重試。
高品質示範回答
「我會先保存帶提交雜湊的原始清單，再用生態解析器產生正規化依賴圖。漏洞來源持續更新；攝取器按漏洞版本增量更新倒排索引。匹配結果寫成帶證據快照和規則版本的冪等告警，唯一鍵防止同一儲存庫、元件和漏洞重複。撤回只關閉新通知，歷史記錄保留原因。
通知事件透過持久佇列與掃描交易解耦，按組織聚合並使用穩定鍵重試。靜音有期限、原因和稽核記錄，嚴重性升級可重新喚醒。每次新提交都重新解析目前依賴圖，只有實際不再命中才標記修復。對帳任務檢查清單、漏洞來源、告警和通知四個邊界，指標覆蓋可見性、撤回傳播、積壓、重複和適配器失敗。」
常見錯誤
- 只比較套件名 → 版本和生態不同會產生誤報 → 使用生態座標與區間比較。
- 解析失敗當成安全 → 鎖定檔損壞會靜默漏報 → 保留失敗狀態並重試。
- 每次掃描新建告警 → 同一問題造成通知轟炸 → 使用冪等鍵。
- 覆蓋漏洞更新 → 無法解釋歷史嚴重性和撤回 → 保存版本化記錄。
- 通知放在掃描交易內 → 渠道超時拖慢告警 → 使用持久事件解耦。
- 只看建議修復版本就關閉 → 實際提交可能仍命中 → 重新掃描目前提交。
- 永久靜音 → 風險長期無人負責 → 要求期限和到期提醒。
追問與回答
追問一：如何處理漏洞範圍修訂？
以來源版本產生受影響元件集合，只重算命中的快照。告警保存規則版本和匹配證據，結果變化時寫狀態遷移。
追問二：為什麼保留原始清單？
解析器和規則會升級。原始檔可在新規則下重播，也能證明告警基於哪個提交。
追問三：如何減少通知疲勞？
按組織聚合相同漏洞和元件，提供冷卻窗口、摘要和渠道策略。靜音限定範圍、期限和原因，嚴重性上調可立即通知。
追問四：傳遞依賴如何避免誤判？
依鎖定圖記錄父依賴路徑、直接或傳遞類型和環境範圍；沒有鎖定檔就顯示無法確認。
追問五：多分支如何建模？
分支是快照維度，告警鍵包含分支或引用。刪除分支產生終止事件，不刪除稽核記錄。
追問六：漏洞來源不可用怎麼辦？
使用最後校驗過的版本並標記新鮮度，暫停「無漏洞」結論；來源恢復後按版本差量補算。