本卡屬 FR-108（母卡見建卡後補號），第 1 棒：檢測工具字典、租戶工具設定（含加密憑證）CRUD 與測試連線、任務層 secret 參數信封、api/ 守門與 route 表、error code。40 檔，只掃不修。

這一棒在做什麼（白話）

客戶要用弱點掃描，先在設定頁填掃描工具的帳密（SonarQube 權杖、SSH 帳密等），系統加密存起來。這棒看：帳密存進去、讀出來、送到畫面、寫進 log 的每一段有沒有漏；「測試連線」會不會被拿來當跳板；誰能改別家客戶的設定；以及整支套件 35 條 route 的守門宣告與守門殼。

為什麼切這一塊

這是 CM-1595 那條明文帳密鏈的「存」端，也是整支套件唯一有能力點檢查的地方（3 支寫入掛 plugin.update）。守門殼與 route 表是全套件共用，放第 1 棒先讀過。

重點看什麼（工具不照清單走，掃完逐項回頭核，沒碰的自己開檔查並標「（工具未報，人工查證）」）

• ① 租戶工具設定的守門（api/routes/detection_tool_route.py:50-151）。清單／明細只掛 require_license("plugin")＋登入；新增（:67）／修改（:88）／重置（:105）多掛 plugin.update；測試連線（:126）與引用計數（:144）沒掛能力點。要驗：測試連線會解密憑證去打 agent 再由 agent 打工具——只要登入就能觸發（帶 host 參數，detection_tool_service.py:158），回應會不會洩漏憑證或成為探測管道；tenant_id 從 get_user_context() 來還是 payload 來；plugin.update 是客戶層級（DEV is_platform=f），客戶管理員改的是自己那列還是能指定別的 config_uid（RLS 1 條 FOR ALL policy 兜底，但 get_config_by_id 用數字 id 查）。
• ② 憑證三處防護逐處驗（設計自陳「加密存取／FE 顯示剝除／稽核 log 剝除，漏一處等於零」）。存：detection_tool_service.py:83/:104 _crypto.encrypt(json.dumps(creds))；讀回前端：api/serializers/detection_tool.py:29-46 只回 has_credentials——驗 field_values 欄位有沒有混進 secret（_resolve_credential_group_params :122）；log：grep 這 40 檔所有 logger.* 有沒有印 creds／payload／config。任務層 common/detection_secret_params.py：信封 {__enc__, value}——encrypt_secret_params(previous=…) 的 merge 語意會不會讓「沒改的 secret 欄」以明文回寫；strip_secret_params 是誰呼叫、有沒有路徑漏剝。
• ③ 守門殼與 route 表（api/routing.py、api/guards.py、common/guard.py）。_guarded_factory(None) 回 lambda cls: cls——宿主不給 auth_required 時 35 條 route 全裸，create_blueprint 有沒有像 jedi-asset／jedi-issue 那樣「缺了拒絕掛載」（首腦初看 mount_routes(bp, auth_required=None) 預設 None，要追 plugin/assembly.py 有沒有 assert——那支屬 D4，本棒只驗 routing 這半、標交接點）；_guard() 缺 adapter 直接 RuntimeError＝fail loudly，正面案例，確認即可；require_license 的 resource_type 兩顆（plugin／detection-profile）字串凍結。
• ④ 工具字典與 param_schema（detection_tool_domain_service、detection_tool_param_schema_*）。detection_tools／detection_tool_param_schemas 兩張表零隔離、無租戶欄（DEV 實查）——依「有沒有主人」判準它們是碼表（8 筆工具、版本化 schema），回全表應為正確；驗有沒有任何寫入路徑（若只有 seed 寫入則無攻擊面）；param_schema 的 secret: true 標記是「哪些欄要加密」的唯一依據——誰能改 schema。
• ⑤ 任務綁定表（job_execution_detection_tool_* 四檔，D3 也會碰）。tool_params JSONB 混雜明文與信封；查詢 entity 有幾個欄、空條件會不會回全表（第 70 項）。
• ⑥ 錯誤碼與事件碼（common/*error_code.py、event_code.py）。訊息有沒有帶路徑／SQL／第三方回應原文。

已知背景（未經本輪面板驗證，只是參照）

• 本套件除 R2b 那 11 支（agent 檔案授權與兩個 connector，屬 FR-077 CM-1601、2026-09-16 已派）外從未掃過。 152 檔正式碼（原總表寫 251 是把測試算進去，已更正）。
• R1 F1／CM-1595（CRITICAL）的終點在這支：心跳 payload 組裝時 _resolve_credentials 解密租戶工具憑證明文交給 agent（主專案 detection_task_payload_provider.py＋本套件 detection_orchestration_service.py:1397）。那條是 agent 控制面不驗身分的問題，撞到標「重複 CM-1595」，但本套件這側「憑證解密後的流向與落點」是新的觀察面。
• DEV 唯讀實查（2026-09-16 21:50）：16 張 detection 相關表——7 張開 RLS（detection_executions／_groups／job_execution_detection_tools／_agents／tenant_detection_tool_configs 各 1 條 FOR ALL policy；detection_profiles／_versions 各 4 條）、9 張零隔離：detection_tools／detection_tool_param_schemas／detection_profile_taxonomies／detection_profile_controls（四張是碼表或公版內容，依「有沒有主人」判準可能正確）與 job_execution_comments／_devices／_org_units／_surveys（屬 flow-control 不在本套件）。8 顆能力點 is_platform 全 f。detection_tools 8 筆、tenant_detection_tool_configs 7 筆（1 租戶）、detection_profiles 11 筆（2 租戶）、detection_executions 76 筆。
• 跨 arc 總表第 70 項（空條件回全表）、第 31 項（分頁無上限）、第 22 項（密碼原文進 log）為共用底層，撞到標重複。
• common/guard.py 與 api/guards.py 是「未接線 fail loudly」設計（_guard() 缺 adapter 直接 RuntimeError）——與 FR-098 A1 ⑤ 同款正面案例，驗證它真的做到即可，不要當漏洞報。

怎麼做

第一步：驗 scope 檔數，對上 40 才啟動（明確檔案清單，不是目錄）：