一句話:本卡為 FR-108 母案,掃 jedi-detection(弱點掃描與檢測工具整合)除 R2b 已派 11 支外的全部 149 支正式碼,四棒,只掃不修。子卡清單在末段。
客戶買了「弱點掃描」功能後,系統要記住客戶的掃描工具帳密(SonarQube、ZAP、OpenSCAP 等)、讓客戶上傳或指定掃描基準(一包規則檔)、把掃描任務派給裝在客戶機房的代理程式、再把報告收回來存成證據。這條鏈同時碰到客戶第三方系統的明文帳密、客戶上傳的壓縮檔要解開來解析、伺服器代替客戶去抓外部網址、跑外部程式(cinc-auditor)解析規則檔四件高風險的事。
_resolve_credentials 解密後放進派工 payload 的。控制面不驗身分那半是 remote-agent 的事,帳密怎麼解、解了放哪、有沒有落 log 是這裡的事。detection_secret_params/detection_profile_archive/safe_http_fetch/profile_extractor),每一支都自陳做了什麼防護、也自陳了界線——要驗的是自陳成不成立、界線外有沒有真的路。_guarded_factory 套宿主的 auth_required;每條再掛 require_license(軸⑥:客戶有沒有買);能力點只在「租戶工具設定」寫入三支掛 plugin.update;公版基準的寫入靠 service 層 viewer_is_platform_admin();分類骨幹三支寫入掛平台管理員守門。「有沒有買」≠「是不是你的」——執行、取消、刪除掃描這些動作的專案歸屬檢查在哪一層,是 D3 要答的。credentials_encrypted 整欄加密;任務層 tool_params 內 secret 欄位用 {__enc__: fernet} 信封逐欄加密。設計文件說「三處必須一起做:加密存取/FE 顯示剝除/稽核 log 剝除,漏一處防護等於零」——D1 逐處驗。converge_timed_out_executions 是背景排程進來的(無 HTTP、無 user context),走什麼身分寫 DB——與 FR-094 排程具名身分那批同題。D3 驗。R2b 那 11 支(agent_file_access_service、common/agent_auth、兩個 connector、job_execution_detection_tool_agent 五檔)不在本案,屬 FR-077 CM-1601。主專案接線 core/plugins/detection.py 等 14 檔另棒。
low;scanRoot 一律 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/jedi-detection;一次只派一棒(可與別套件的棒用另一帳號並行),建議 D1 → D3 → D2 → D4(憑證的存與出先看,基準與骨架後看)。