D3-2 檢查結果：任務與工具綁定（jedi-detection）

檢查日期 2026-09-18｜對應卡片 CM-1875（D3 第 2 小棒）｜檢查範圍 5 個檔案 1,328 行

找到 1 條中風險：換工具時「掃描範圍」不會重新檢查，可以讓系統把一整個超大網段逐台展開，把後端伺服器的記憶體吃爆、服務倒掉。 要先是某個專案的管理者，送兩次修改再按執行才打得到，所以不急；修法很小——換工具時拿「實際會生效的值」重驗一次，再幫展開那支加一道硬上限。另外查證了卡片重點⑥的另外三項確認沒問題：密碼加密的時機是對的（綁定與 BPMN 兩份同源、不會留明文副本）、留空沿用不會把密碼寫到別人那列、掃描範圍只有專案管理者能改。

客戶在一張稽核任務上指定「要用哪個檢測工具、掃哪些機器、用什麼帳密登入」。這份設定存下來之後，按「執行」時會被拆成工單送給裝在客戶機房的代理程式。

這一棒看的是存設定的那一段，兩件事：

1. 帳密什麼時候加密、加密得夠不夠早。掃描設定裡混著非機敏欄位（逾時秒數）與機敏欄位（被掃網站的登入密碼），兩者同住一個 JSON 欄位。如果加密做得太晚、或只做了其中一條寫入路徑，密碼就會以明文留在資料庫或畫面上。
2. 掃描範圍是誰填的、有沒有檢查。「掃哪些機器」這欄使用者可以填 192.168.50.1-50 或 10.0.0.0/8 這種寫法，系統要把它展開成一台一台的位址。填得太大就是一顆炸彈——問題是檢查有沒有真的擋在每一條路上。

掃描目標 /Users/chouraymond/Projects/Jedicogy/module/jedi-python-package/jedi-detection，revision 955e40964baa（branch feature/review，工作區乾淨），mode scan，effort low，範圍 5 個檔案：綁定處理器 detection_job_binding_handler.py（659 行）、任務層敏感參數加解密 detection_secret_params.py（154 行）、掃描目標語法與展開 scan_target_spec.py（307 行）、分派參數工具 detection_assignment_params.py（171 行）、綁定表 model job_execution_detection_tool.py（37 行），共 1,328 行。

low 強度：一位研究員讀完這 5 個檔案就提報候選，未做元件盤點、未做威脅建模、未跑額外密鑰專項掃描，completenessCheckOutcome 為 not-applicable（低強度本來就不跑盤點）。驗證跑了 1 輪，2 個候選去重後仍是 2 個，沒有候選遺失、沒有嚴重度被降低、沒有候選被略過。研究員為了追資料流另外讀了範圍外的幾處（主專案的任務序列化器與 job service、BaseRepositoryImpl 的更新語意、編排服務的展開與派工、jedi-file-upload 的下載守門與 RLS），那些只當佐證、沒有納入稽核。

研究員沒有回報「哪些檔案沒讀完」的自述（coverage.research 為 null），所以工具端沒有做讀取完整度的交叉檢查。

工具沒有實際執行任何程式碼：沒跑測試、沒發請求、沒示範攻擊，所有判斷都是讀原始碼推出來的。唯一的例外是首腦核對時直接呼叫 scan_target_spec 這支純函式確認數字（count_spec('10.0.0.0/8') 回 16,777,214），那是讀取性質的驗算、不改任何狀態。

工具碰到了卡片重點⑥的「掃描目標驗證」那一半，「加密時機」那一半完全沒提出候選，由首腦回頭開檔查證補上，詳見下方「卡片重點逐項人工查證」段。

現況（2026-10-01）：本棒各條後來的處理結果如下（過程紀錄保留，不改）。

• F1（換工具時掃描範圍不重驗）＝M03 第 11 條，✅ 已修（CM-2058）。

被駁回 1 條（內部欄位沒過濾就寫進派工參數），三位檢查員一致認為拿不到好處，理由見下方。

F1 — 換工具時掃描範圍不重新檢查，超大網段會留在原地被逐台展開（MEDIUM，confidence medium）

這是什麼問題。 「掃哪些機器」這一欄有台數上限（預設 256 台），但上限只檢查「這次送上來的值」。如果這次的修改沒有帶這一欄，程式就當作沒東西要檢查、直接跳過；而底層更新又有一條規則是「沒送的欄位不覆蓋」，於是上次存進去的那個超大網段原封不動留著，工具卻已經換成受上限管的那一支了。等到按下執行，派工端才真的去展開這個網段——那裡沒有上限（那支程式的註解自己就寫著「這裡刻意不擋」）。

還有一個前提讓這件事打得成：不是每個工具都受台數上限管。OpenVAS 這類工具自己就吃網段寫法、不需要逐台登入，所以刻意豁免；OpenSCAP、Nmap、CINC Auditor 這幾支要逐台 SSH 登入的才受管。攻擊者就是利用這個豁免把大網段先存進去。

出事會怎樣。 一個 /8 網段展開後是 16,777,214 台（首腦實跑 count_spec 確認的數字）。展開的動作會在記憶體裡生出一千六百多萬個字串、一個去重用的集合，最後再把它們串成一條逗號分隔的長字串——而且整段過程都在一個請求的資料庫交易裡面。結果是那個 API 工人的記憶體被吃光、行程變慢或直接被系統砍掉，同時那個沒結束的交易還一直佔著資料庫連線。其他使用者這段期間會覺得系統卡住或連不上。

要先有什麼才打得到。

• 攻擊者得是某個專案的管理者（能登入、且在該專案有 manager 角色）。改任務設定這條路有守門：compliance-manager-be/app/flow_control/service/job_service.py:235 的 _require_manager。
• 要送兩次修改：第一次綁一支豁免的工具（OpenVAS）並把掃描範圍填成 10.0.0.0/8；第二次只換工具（換成 OpenSCAP）、不帶參數。
• 之後要按下執行，才會走到展開那一步。

三個條件都是「一個內部人員刻意做」才成立，不是外面的人打一個網址就中——所以是中風險不是高風險。

在哪裡。

• 缺口本體：jedi-detection/jedi_detection/app/service/detection_job_binding_handler.py:201-204 —— 台數檢查只吃 tool.get("params")，也就是這次送來的值
• 跳過檢查的那行：同檔 :331-333 —— values = [v for v in raw_values if v]，全是 None 就直接 return，後面的上限檢查一行都沒跑
• 沒送就不覆蓋的規則：jedi-common/jedi_common/session/database/repository/base_repository_impl.py:424 —— value is not None 這個條件讓 tool_params=None 被跳過，舊值留著
• 參數預設值來源：compliance-manager-be/api/flow_control/serializers/job.py:256 —— params = fields.Raw(allow_none=True, load_default=None)，沒帶就是 None
• 豁免表：jedi-detection/jedi_detection/common/scan_target_spec.py:60-67 —— SSH_ITERATED_TARGET_FIELDS，openvas 不在裡面
• 真正展開的地方：jedi-detection/jedi_detection/app/service/detection_orchestration_service.py:555 —— expand_spec(raw)，上游函式的 docstring（:535-537）明說「真的走到這裡還超量仍照展開」

另一個落點（首腦補查，工具沒提）。 同一個缺口在分派列那條路也成立，而且更直接：_replace_detection_tool_agent_assignments（:492）開頭的 if assignments is None ... return（:536）表示「沒帶分派清單＝不動既有設定」，於是 :570 那道同名的台數檢查根本不會跑，既有列裡的 hosts 就這樣帶著舊值跟到新工具底下。修法要兩條路一起補，只補其中一條會留下另一半。

怎麼修。 兩層，都要做：

1. 寫入端：在 detection_job_binding_handler.py:201 附近，把餵給檢查的值從「這次送來的」改成「實際會生效的」——tool.get("params") 取不到時回頭拿 existing.tool_params。判斷條件是工具有沒有換（detection_tool_id 與 existing.detection_tool_id 不同），換了就一定要用生效值重驗一次。分派列那條（:570）同樣處理：工具換了就把既有列的 hosts 一併拉出來重驗。
2. 展開端：在 detection_orchestration_service._expand_scan_target_fields（:551 的迴圈裡）呼叫 expand_spec 之前先呼叫 scan_target_spec.count_spec(raw)，超過一個硬上限就記 error 並跳過該欄位（或直接讓這張工單失敗），不要展開。count_spec 是純算術、不產生清單，成本幾乎是零（這正是它當初被寫出來的理由，見 scan_target_spec.py:168-170 的 docstring）。這一層是給存量資料的保險——就算寫入端補好了，資料庫裡已經存著的超大網段還是打得到。

⚠️ 注意展開端的現行設計是刻意不擋的（docstring 寫「寧可跑一張大工單，也不要讓一個已經存在的任務突然變成執行不了」）。所以那道硬上限要訂得比使用上限寬很多（例如 65,536），只用來擋「明顯是炸彈」的輸入，不要讓正常的大範圍掃描被誤擋——否則會推翻原本的設計判斷。

驗證。 3/3 三位檢查員確認成立（可達性、影響、既有防護三個角度），嚴重度維持 MEDIUM。三位各自獨立把鏈子追完：序列化器的預設值 → 檢查被跳過 → 底層不覆蓋 → 展開無上限，四個環節都對得上，且都確認中間沒有任何一處做過補救。

為什麼是 MEDIUM 不是 HIGH： 要先是專案管理者，還要分兩次送修改、再按執行；打不到資料（不會外洩也不會竄改），只會讓服務變慢或倒掉。

首腦核對註記。 屬實，逐環開檔核對過：:201-204 確實只吃這次的值、:331-333 確實提早 return、base_repository_impl.py:424 的 value is not None 確實會跳過 None、SSH_ITERATED_TARGET_FIELDS 確實不含 openvas、_expand_scan_target_fields 確實無上限。另外實跑 scan_target_spec 確認 10.0.0.0/8 語法檢查會通過、展開台數是 16,777,214、openvas 回空 tuple（不受管）、openscap 回 ('hosts',)（受管）——攻擊路徑的每一環都對得上。與 D1／D3-1 不重複：D1 查的是憑證存放與守門，D3-1 查的是結果回收信不信代理程式，都沒碰到綁定寫入這一段。淨新增 1 條，登記跨 arc 總表。

卡片重點⑥有兩半：「任務綁定的加密時機」與「掃描目標驗證」。工具只碰到後者（就是 F1），前者完全沒提候選，首腦開檔補查。

⑥-1 加密時機：哪些欄位進信封、會不會漏掉某條寫入路徑 — ✅ 沒問題

設計本身是對的。 密碼不是整欄加密，而是包成一個「自我描述的信封」：{"__enc__": "fernet", "value": "<密文>"}。這樣做的理由寫在 detection_secret_params.py 的模組說明裡，而且理由站得住——密文存進 JSON 之後跟明文一樣都是字串，光看值分不出有沒有加密；如果靠「查工具定義哪些欄位是機敏的」來決定要不要解密，那工具定義一改版，舊任務就會解錯（把明文當密文解會炸、把密文當明文送出去會讓代理程式拿密文去登入）。改成信封之後，值自己會說明自己加密與否，工具定義怎麼改都不影響既有資料。

兩條寫入路徑都有加密，沒有漏的。 任務層一條（:147-159）、分派列一條（:412-433），兩處都呼叫同一支 encrypt_secret_params。

加密的時機擋在對的位置——:139 的 _encrypt_tool_secret_params 是在 tool dict 剛進來、還沒分岔去寫 BPMN XML 之前就做的。這點很關鍵，該函式的 docstring（:128-133）自己點名了：同一個 tool dict 會同時被拿去寫綁定表和寫進 BPMN 流程定義的 XML，如果只在綁定那端加密，BPMN XML 裡就會留一份明文密碼副本，而那份還會被規劃頁與 BPMN 編輯器讀出來——等於加密了卻照樣外洩。現行寫法是在分岔前就加密，兩份拿到的都是密文。判定：時機正確。

「留空＝沿用原值」不會把密碼寫到別人那列。 前端對已設定的密碼欄位是留空的（不會把密文送回來），所以後端要從既有資料沿用。危險在於「沿用誰的」——分派列有很多列，拿錯列就會把 A 列的密碼寫進 B 列。核對 :415-417：沿用來源是用 uid 逐列對位建的表（previous_by_uid），沒有 uid 的列視為新增、本來就沒有前值。判定：對位正確。

三處剝除都在。 加密只解決資料庫，畫面與稽核記錄要另外處理：strip_secret_params 的做法是整個欄位不出現而不是遮成 ****——理由（:120-124）也站得住：遮罩仍要把值取出來走過序列化，任何一處忘了套就是明文外洩，而且遮罩後的密文照樣會落進 api_logs.response。判定依據是「值是不是信封」而不是查工具定義，所以連拿不到定義的讀取路徑（control-tree 的 raw SQL）也剝得掉。判定：沒問題。

兩個容錯行為的方向是對的（出錯時偏向安全）：crypto 沒注入時會記 warning 而不是靜默落明文（:79-83）；解密失敗時剝除該欄位而不是把密文丟給代理程式（:130-135），因為送密文過去會讓它拿密文當密碼去登入，症狀是「掃描跑完但沒進到登入後頁面」，比「缺欄位」難查得多——缺欄位至少會被連接器明確回報。

⑥-2 掃描目標驗證：接受什麼寫法 — ⚠️ 語法檢查沒問題，台數上限有缺口（就是 F1）

語法檢查本身寫得不錯，三個細節值得記。

• 主機名與 IPv6 原樣放行（scan_target_spec.py:93-99）。只有長得像「四段數字」的東西才套 IPv4 規則。這是必要的，因為掃描目標欄一直都允許填主機名，不能因為新增了 IP 語法就把它們擋掉。
• 「想寫範圍但寫錯」會明確報錯，不會靜默放行（:107-137）。192.168.1.1-192.168.2.5（跨網段範圍，目前不支援）長得像一個含連字號的主機名，如果讓它走放行那條路，會被當成一台叫這個名字的主機送出去，DNS 解析失敗變成一筆「主機不存在」——使用者以為掃了一整段、其實零台。現在會明確報錯告訴他要改寫法。這是靜默失敗的反面教材，寫得對。
• 範圍顛倒不自動對調（:127-129）。192.168.50.100-50 這種會報錯而不是幫他調過來，理由是「自動對調等於猜使用者的意思，猜錯就掃了一整段不該掃的機器」。

誰能改掃描目標：只有專案管理者。 三個入口（建立任務 :134、更新任務 :179、改分派 :235）都先呼叫 _require_manager（compliance-manager-be/app/flow_control/service/job_service.py:94）。這是 FR-048 軸③的資源域守門，走 app service 層、不是 route 層 decorator，符合規範。判定：權限這一層沒問題。

前端送來的內部欄位會被剝掉。 scan_targets 裡 _ 開頭的欄位是後端自己維護的狀態（例如源碼包的參照），前端看不到也不該送。:556-561 會先把前端送來的內部欄位一律丟棄，再從既有資料逐列保留原本的——剝除與保留是一組動作，少了後者的話使用者每次按儲存都會把源碼包參照清掉。判定：處理正確（這也正是下面被駁回那條候選的爭點，見後）。

缺口就是台數上限那一項 —— 見 F1。

附帶查證：內部欄位沒過濾就寫進派工參數 — ✅ 不成立（面板 0:3 全否，首腦同意）

研究員提報：綁定寫入那條路（detection_job_binding_handler.py:213）沒有做上面說的「剝掉 _ 開頭內部欄位」那一步（分派列那條路 :558 有做），所以前端可以塞 _source_file、_profile 這種內部欄位進去，一路流到代理程式讀取檔案時用的允許清單。

三位檢查員一致否決，理由一致且首腦複核同意：

• 寫入是真的，:213 確實少了那道剝除，注入的欄位也確實會存活到派工參數裡。
• 但拿不到任何好處：能做這件事的人本來就是專案管理者，而管理者原本就有那個檔案的存取權——攻擊者做完跟做之前的權限一模一樣。
• 下載端點的守門沒被影響：/api/1.0/file/download/<uid> 的守門與這個欄位無關。
• 抓檔跑在該代理程式自己的租戶脈絡下：agent_file_access_service.py:127-130 會從代理程式那筆資料推出租戶身分，讀取時被資料庫的租戶隔離（RLS，就是「每個客戶只能看自己資料」的機制）擋住，跨租戶拿不到東西。

判定：不是漏洞，不計為發現。 不過既然兩條寫入路徑對同一件事的處理不一致（分派列剝、綁定不剝），建議在修 F1 時順手把 :213 也補上那道剝除——一致性本身有價值，而且「兩條路不一樣」這件事本身就是下一個人踩坑的來源。列為體質改善建議。

分兩層講：

「報出來的這條存在嗎」——可信度高。 F1 的每一環首腦都開檔核對過，而且實跑純函式確認了數字（/8 是 16,777,214 台、openvas 不受管、openscap 受管）。三位檢查員從三個不同角度獨立追同一條鏈，三票全過。另外首腦補查時還找到同一缺口的第二個落點（分派列那條路），這增加而非削弱了對這條發現的信心——但也代表修法不能只補一處。

「只有這條嗎」——可信度中等，有三個已知限制。

1. 強度是 low，只有一位研究員讀一遍，不是多位分工交叉讀。低強度的設計目的是快速篩，不是窮盡。
2. 這 5 個檔案的下游不在範圍內。F1 的後半段（真正展開的那一步）在編排服務裡，那支檔案屬於 D3-4a／D3-4b 兩小棒，本棒沒掃。同理，若編排服務在參數落地時另有問題，本棒看不到。
3. 加密那一半的「沒問題」是人工定向查證，不是面板投票的結果——工具對這一半一條候選都沒提。這幾項結論沒有三票背書，可信度低於 F1 那條。首腦讀的是設計意圖與實際程式碼是否一致，若有人刻意繞過這套信封機制另寫一條路（例如直接寫 SQL 更新那個 JSON 欄位），本次查證看不到。

verification.status 為 verified：三位檢查員對 2 條候選各投一票，6 票全數投出，沒有漏投，票數由工具自己的程式碼統計、不是任何 agent 自報。

這一棒是「每棒總行數 ≤ 2,000」判準的第二次實證。 1,328 行、零重試跑完。另外這棒是刻意與另一支掃描（jedi-evidence-classification E1）平行跑的——決策者要驗「並行」是不是死因之一。結果是平行沒有害死它，這與第 6 次診斷的結論一致：死因是研究員單次思考超過 180 秒被判停滯，跟並行無關。不過樣本只有一次，「一次只跑一棒」的紀律沒有因此解除，後續仍照舊。