檢測工具擴充：ZAP / InSpec / GCB / Nmap

這一節先確立「哪些事情已經不必再做」。FR-056 把工具知識完全逐出後端，FR-057 補齊了 SSH 型態與多檔證據回收——本案是站在這兩層地基上做接入，不是重建管線。

1.1 FR-056 建立的平台架構

1.2 evidence-agent 的 connector 架構

core/task_executor_connectors/base.py 定義 DetectionConnector 抽象類別，介面只有兩個方法：

connector 可用的注入點：cancel_event（CM-931 任務取消）、host_failures（CM-952 逐台失敗回報）、content_mismatch_hosts（CM-954 內容錯配回報）。

順序不是依重要性排的，而是依「摸索成本」與「相互依賴」排的——先把能被複用的引擎做出來，後面的工具才不必重複扛同一份工程。這個優先序在 2026-07-30 改採分批出貨後維持不變，變的只是四個工具改為序列分批交付（ZAP 先上線），不再四個一起收；批次安排見 §10.2。

2.1 四工具的整合形態分類

以「誰驅動掃描」與「連線型態」兩軸攤開，可以看出這四個工具分屬幾種完全不同的整合模式——差別在於 connector 面對的是遠端服務 API、目標主機的遠端 shell，還是 agent 本機的引擎。

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
graph TD
  ROOT["evidence-agent
connector"]

  ROOT --> API["① 連遠端服務 API"]
  ROOT --> REMOTE["② 遠端登入目標主機
(引擎裝在目標主機)"]
  ROOT --> LOCALENG["②′ agent 本機引擎
由引擎自己連出去
(目標主機 agentless)"]
  ROOT --> CLI["③ agent 本機 CLI
(至今無使用者)"]

  API --> OV["OpenVAS
(已上線)"]
  API --> ZAP["ZAP
FR-058.1"]

  REMOTE --> OSCAP["OpenSCAP
SSH · Linux (已上線)"]
  REMOTE --> NMAP["Nmap
SSH · FR-058.4
(D9 改案，原定 ③)"]

  LOCALENG --> INSPEC["CINC Auditor
SSH + WinRM · FR-058.2"]
  LOCALENG --> GCB["GCB
複用 CINC 引擎 · FR-058.3"]

  CLI --> NONE["尚無實際使用者"]

  classDef mode fill:#EEF2F3,stroke:#C7D1D2,color:#14201F;
  classDef shipped fill:#E4F1EA,stroke:#2E7D5B,color:#14201F;
  classDef newtool fill:#E2F0F1,stroke:#0E7C86,color:#14201F;
  classDef root fill:#F6EBD5,stroke:#9C6B12,color:#14201F;
  classDef empty fill:#FBFCFC,stroke:#C7D1D2,color:#7A8A8C;
  class ROOT root;
  class API,REMOTE,LOCALENG,CLI mode;
  class OV,OSCAP shipped;
  class ZAP,INSPEC,GCB,NMAP newtool;
  class NONE empty;
      

這是本案唯一需要動平台本體的項目，而且必須先於 ZAP 完成。方案已拍板採選項 A，此處三案並陳說明取捨。

3.1 問題：現有設計有一格是空的

使用情境是「任務可輸入要掃描的網站，有可能提供一組登入帳密讓 ZAP 做登入後掃描，沒有的話就一般掃描」。但現有設計把憑證與參數分成兩處放，而只有憑證那一條有加密：

這不是 ZAP 專屬問題：Nmap 若要做認證掃描、GCB 若每台主機帳密不同，都會撞上同一格。因此當成平台級能力補上，不做 ZAP 專屬的權宜處理。

3.2 三個評估過的選項

3.3 ZAP 的 param_schema（採用選項 A 之後）

沒有選登入模式時，後四欄整組不顯示。這對上「有帳密就深掃、沒有就一般掃描」的需求，而且用的是 FE 現成的 condition 機制，不需要新元件。

3.4 端到端流程（以 ZAP 登入後掃描為例）

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
sequenceDiagram
  participant U as 稽核員
  participant FE as 前端
  participant BE as 雲端 BE
  participant AG as evidence-agent
  participant Z as 客戶 ZAP daemon
  participant W as 被掃網站

  U->>FE: 發佈任務：填 target_url、選「登入後主動」、填測試帳密
  FE->>BE: POST 任務參數
  BE->>BE: 依 param_schema 對 secret:true 欄位 Fernet 加密
  BE->>BE: 寫入 tool_params（敏感欄位為密文）
  AG->>BE: 心跳（mTLS）
  BE->>BE: 組裝派工時解密敏感參數
  BE-->>AG: pending_tasks（含明文參數，僅傳輸中存在）
  AG->>Z: 設定 context + 登入認證 + logged_in_indicator
  AG->>Z: ajaxSpider.scan（爬取）
  loop 輪詢爬取狀態
    AG->>Z: ajaxSpider.status
  end
  AG->>Z: ascan.scan（主動掃描）
  loop 輪詢掃描進度（支援 cancel_event / timeout）
    AG->>Z: ascan.status
    Z->>W: 送出測試請求
  end
  AG->>Z: core.htmlreport（HTML 給人看）
  AG->>Z: core.jsonreport（JSON 供統計解析）
  Z-->>AG: 報告內容（記憶體，不落地）
  AG->>BE: ScanResult（HTML bytes + summary）
  BE->>BE: 走既有 blob 通道寫 job_evidences
  BE-->>FE: 執行紀錄顯示參數（敏感欄位已剝除）
  U->>FE: 於證據附件檢視 ZAP 報告
      

身分定位

原 OWASP ZAP，現歸 Checkmarx 維護，仍為 Apache 2.0 開源授權。屬 DAST（動態應用程式安全測試）——對執行中的網站主動送出測試請求，找出網頁層弱點。

整合形態

走 API / daemon 模式（與 OpenVAS 同型），不走 baseline CLI 模式。理由：API 模式能做「登入後掃描」，那是稽核場景真正有價值的能力；CLI baseline 只能被動掃表層，對合規證據的價值有限。

connector 骨架照抄 openvas.py 的形狀：連客戶既有的 ZAP 服務（不自己拉容器）、輪詢進度、雙格式取報告（core.htmlreport HTML 給人看 + core.jsonreport JSON 給程式解析統計；2026-07-30 D4 改版，見 §8 D4）、支援 cancel_event 與 timeout。

技術要點：ZAP 2.17.0 相容性

使用者公司已安裝 2.17.0，以下四點在實作前必須對齊。

沒有破壞性的 API 端點移除，主線呼叫序列可以沿用。

4.1 既有參考實作的三欄取捨

前同事寫的 auto-pentest 專案位於 ~/Documents/Projects/Jedicogy/auto-pentest/（DDD 分層 + MinIO 儲存）。它的價值不在架構，而在踩過坑才整理得出的那幾份知識。

本案工作內容

• SQL seed：detection_tools 新增 ZAP（connection_type='API'）+ config_field_schema（ZAP 服務位址、API key）+ param_schema（§3.3 那份，含 secret 欄位）+ setup_guide（daemon 啟動指令與 API key 設定說明）。
• agent connector：core/task_executor_connectors/zap.py，實作 run()（依 scan_mode 分支：被動 / 主動 / 登入後主動）與 probe()（只驗連得到 ZAP 且 API key 正確，不建立掃描資源）。
• 依賴：必須等 FR-058.0 任務層敏感參數完成，否則登入帳密無處安放。

4.2 登入後掃描的 SPA 限制（D12，2026-07-30 實測後追加）

這一節是本案嚴重度最容易被低估的發現。設計階段原本把它記成「SPA 掃不進登入後頁面、報告涵蓋範圍侷限」——實測證明那個記載是錯的，真實後果高出一個層級。

daemon log 摘錄（根因只有 insight.auth.failure : 100 那一行）：

[ZAP-Insights] INFO org.parosproxy.paros.control.Control - Shutting down ZAP due to High Level Insight:
HIGH : EXCEEDED_HIGH : http://192.168.50.151 : insight.auth.failure : 100
[ZAP-Insights] INFO ... - Discard Session
... (後續大量 Selenium NoSuchSessionException，為 ZAP 死後的餘波，非原因)
ZAP 2.17.0 terminated.
zap exited with code 2 (restarting)

讀 log 時容易誤判的一點：NoSuchSessionException 洗版看起來像 Selenium 出問題，但它發生在 Shutting down ZAP 之後，是 ZAP 已死造成的下游噪音，不是根因。

範圍界定（避免過度解讀）

為什麼 SPA 支援不做半套（D12 定案）

SPA 的登入後掃描要通，三件事必須同時解決，缺一則等於沒做：

被排除的三個折衷走法：① 本案一併擴充 json 認證 + script session——那是「認證方式擴充 + script 管理 + 測試站台」三件獨立工作，塞進第一批會拖住已可出貨的部分，而第一批的核心價值（ZAP 接入、HTML 證據進證據池、任務層敏感參數平台能力）不依賴登入後掃描。② 只做 json 認證、session 管理留待日後——沒有中間地帶：認證送出去了但 token 帶不進後續請求，一樣掃不進登入後頁面，結果與完全不做相同，卻已付出工程成本並在 UI 上留下「看起來支援了」的誤導。③ 只換掉 logged_in_indicator 的判定——那只解第三個原因，前兩個原因未解則掃描本來就進不去，判定準不準沒有意義。

實測數據（2026-07-30，對一個 Next.js SPA 站台）

這組數字同時是匿名掃描價值邊界的具體證據：對 SPA 而言，未解決登入即等同匿名掃描——能查出組態層問題但碰不到應用邏輯。這正是登入後掃描在稽核場景的價值所在，也是它值得列為獨立後續案、而非在第一批做半套的理由。

原稱「InSpec / CINC Auditor」，2026-07-31 統一為「CINC Auditor」——採用的就是 CINC，名稱裡掛著會混淆授權判斷的 InSpec 字樣沒有好處（見 D5）。本節保留 InSpec 字樣之處均為指涉上游專案或 profile 格式，非產品內的工具名稱。

身分定位

組態合規檢測引擎，用 Ruby DSL 撰寫檢測規則（profile）。本案接入它是為了解決 Windows 主機組態檢測這個既有缺口。

要解的問題

FR-057 的 OpenSCAP connector 是 SSH 加 Linux 寫死的（/usr/bin/oscap、/etc/os-release、sudoers），無法處理 Windows 主機。這個缺口已記錄於 Notion CM-953（「FR-057 後續：異質 OS 環境（Windows 等非 Linux 主機）的檢測支援方案」，狀態＝討論）。

5.1 為什麼不是繼續用 OpenSCAP

5.2 拍板路線：InSpec / CINC Auditor

5.3 實作揭露的架構事實（2026-07-31 回填）

實作時建立的三個約定

本案工作內容

• SQL seed：detection_tools 新增 CINC Auditor，connection_type 需涵蓋 SSH 與 WinRM 兩種目標 transport（透過任務參數或設定欄位選擇）。
• agent connector：新增 inspec.py，包裝 CINC Auditor CLI，統一走 --reporter json 解析結果；沿用 FR-057 建立的 host_failures 逐台失敗回報通道。
• agent image：加入 CINC Auditor（裝在 agent 本機，見 §5.3）。
• 結案 Notion CM-953。

身分定位

政府組態基準（TWGCB），我國公務機關資通設備的組態安全基準。屬合規稽核情境的高需求項目。

整合形態

GCB 與 OpenSCAP 一樣要分 Windows 與 Linux 兩邊，差別只在 content 不同；而 FR-058.2 的 CINC Auditor 本來就是 SSH 加 WinRM 雙 transport 的同一套引擎，因此兩邊一次由它承擔，GCB 不另立引擎、不另寫 connector。這部分已拍板，見決策 D7 引擎層。

6.1 官方實際提供什麼（2026-07-30 查訪盤點）

以下盤點不是本案的工作清單，而是後續評估 content 投入時的背景資料；在本案的作用只有一個——解釋為何 Demo 平台選 Windows。資料來源為 NICS 兩個官方頁面：GCB 說明文件（頁面標示 2026/6/26 更新）與 GCB 部署資源（頁面標示 2026/3/30 更新）。

說明文件頁：作業系統基準（只有 DOCX + PDF 兩種格式）

另有瀏覽器說明文件：Google Chrome、Mozilla Firefox、Microsoft Edge、Safari——同樣只有 DOCX 與 PDF。

部署資源頁：機器可讀檔（全部是 ZIP，且只有 Windows 與瀏覽器）

6.2 三類平台的落差（後續評估用）

這份落差就是本案 Demo 選 Windows 的理由：Windows 有 GPO 檔這個結構化來源可直接參考，寫一個最小 Demo profile 的成本最低；Linux 只有 DOCX，連一條 Demo 規則都要先人工翻譯文件敘述。要再次強調——這是選 Demo 平台的理由，不是要在本案做 Windows content 工程。

6.3 引擎與 content 的責任切分

本案工作內容（範圍已由 D7 裁示收斂）

• SQL seed：detection_tools 新增 GCB 條目，引擎指向 FR-058.2 的 CINC Auditor（Windows 與 Linux 共用）。
• 一份 Windows 最小 Demo profile：取最單純的一個基準項目，用途只有一個——驗證端到端鏈路（WinRM 連線 → 認證 → profile 執行 → 結果解析 → 證據上傳）可運作。不追求規則覆蓋量。
• content 外部載入接口：確保 profile 由外部提供給 connector，不硬編、不隨 agent image 發布。這是本案的設計約束。2026-07-31 改為「驗證 + 寫文件」見 §6.4。
• 不在本案 content 產製（逐條 TWGCB-ID 轉檢查規則）、Windows GPO 產生器、後台 content 更新機制（上傳 / 版更 / 套用）。macOS 15 一併排除。

6.4 D7 content 外部載入接口：改為「驗證 + 寫文件」（2026-07-31 裁示）

兩個已知限制（併入後台 content 更新機制的評估範圍）

• 封閉網路無法把 profile 送進 container——目前的來源都需要對外連線，內網隔離環境沒有投遞管道。
• 私有 repo 沒有憑證路徑——只能用公開來源。

身分定位

網路埠與服務探測工具。在合規情境對應「開放服務盤點」「非必要服務關閉」這類控制項的證據。技術上是四個工具裡最單純的一個。

整合形態 2026-07-30 D9 改案：CLI 型 → SSH 型

（改案後定案）走 connection_type='SSH'：nmap 由客戶安裝在自己指定的一台執行主機上，agent 透過 SSH 登入該主機執行掃描，與已上線的 OpenSCAP 完全同構。連帶結果——nmap 需要 SSH 憑證（requires_credentials=TRUE），不再是零憑證工具。

（原設計，已被取代）原定「我們驅動、agent 本機執行 CLI」，agent 直接呼叫 nmap -oX，並以此當作 connection_type='CLI' 型態的第一個實際使用者。改案後該型態至今仍無任何使用者（FR-056 定義後未曾被用過）。

7.1 D9 為什麼改案：兩個獨立的理由同時成立

Is designed specifically to execute Covered Software and parse the results
(as opposed to typical shell or execution-menu apps, which will execute
anything you tell them to).

評估過並排除的三個替代方案

改案的連帶影響

• nmap 不再是零憑證工具（requires_credentials=TRUE）。
• 零憑證放行的平台能力仍然保留且仍要做——它是平台級能力（見 D9 右半），只是換掉了第一個使用者；日後真正零憑證的工具會用到。
• connection_type='CLI' 仍然沒有實際使用者，原本「Nmap 是 CLI 型態首用」的價值消失。
• agent connector 範本從「本機子行程」改為對照 openscap.py 的 SSH 多目標模式。

本案工作內容（依 D9 改案後）

• 平台調整：讓 start_execution 認得「這個工具本來就不需要憑證」是合法狀態（平台能力保留，見 D9）。
• SQL seed：detection_tools 新增 Nmap（connection_type='SSH'、requires_credentials=TRUE）+ config_field_schema（SSH 憑證，對照 OpenSCAP）+ param_schema（掃描目標 / 掃描類型 / 埠範圍）+ setup_guide（客戶在自己指定的主機安裝 nmap、NPSL 授權說明、SSH 連線前提、埠掃描授權警語）。
• agent connector：新增 nmap.py——SSH 登入執行主機 → nmap -oX → XML 解析 summary + 報告上傳，逐台 host_failures 回報；probe() 分四段檢查（SSH 連線 / 認證 / 該主機 nmap 存在可執行 / 權限）。不 bundle 進 image。

決策全數拍板——原先唯一保留的 D7 content 層已於 2026-07-30 由決策者裁示收斂範圍，本案不再有開放問題。（原 D10 隨其對應工具一併移出本案，其餘編號維持不變，避免與先前溝通過的編號錯位。2026-07-31 更新：SonarQube 已重新納入為 FR-058.5，決策以 D13–D16 定案、D10 編號維持 tombstone 不重用，詳見 design.md §2 與 §4.6，本稿不重列。）實作期間有兩次改案與一項追加：D4 改版（ZAP 證據 PDF→HTML）、D9 改案（Nmap CLI 型→SSH 型）、D12 追加（ZAP 登入後掃描的 SPA 限制，實測後補列）。

以下不是待決策事項，是實作時會遇到、或本案會放大的既有問題。列出來是為了在拆任務時不被意外絆住。

依已拍板的優先序切成 5 個子需求加 1 個橫向項。2026-07-30 決策者進一步裁示分批出貨、ZAP 優先上線——不再四個工具一起收，改成三個批次序列推進，批次結束才做一次端到端測試。子需求本身的內容與優先序不變，變的是交付節奏。

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','secondaryColor':'#EEF2F3','secondaryTextColor':'#14201F','tertiaryColor':'#FBFCFC','tertiaryTextColor':'#14201F','lineColor':'#4A5A5C','textColor':'#14201F','mainBkg':'#E2F0F1','nodeBorder':'#0E7C86','nodeTextColor':'#14201F','edgeLabelBackground':'#FBFCFC','titleColor':'#14201F','clusterBkg':'#FBFCFC','clusterBorder':'#E4EAEB','actorBkg':'#E2F0F1','actorTextColor':'#14201F','actorBorder':'#0E7C86','actorLineColor':'#C7D1D2','signalColor':'#4A5A5C','signalTextColor':'#14201F','labelBoxBkgColor':'#EEF2F3','labelBoxBorderColor':'#C7D1D2','labelTextColor':'#14201F','loopTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#14201F','noteBorderColor':'#9C6B12','activationBkgColor':'#EEF2F3','activationBorderColor':'#C7D1D2','sequenceNumberColor':'#FFFFFF'}}}%%
graph LR
  subgraph B1["第一批 · ZAP 上線 (CM-958〜970)"]
    PX["橫向項 FR-058.X
_TOOL_ID_TO_CODE 解耦
(D11 已拍板)"]
    P0["FR-058.0
任務層敏感參數
(平台前置)"] --> P1["FR-058.1
ZAP connector"]
    PX --> P1
  end

  subgraph B2["第二批 (CM-971〜979)"]
    P2["FR-058.2
CINC Auditor connector
SSH + WinRM"] --> P3["FR-058.3
GCB
(引擎 + Windows Demo)"]
  end

  subgraph B3["第三批 (CM-980〜983)"]
    P4["FR-058.4
Nmap
SSH 型 (D9 改案)"]
  end

  B1 -->|"批次結束測一次"| B2
  B2 -->|"併第二批一起測"| B3

  classDef pre fill:#F6EBD5,stroke:#9C6B12,color:#14201F;
  classDef chain fill:#E2F0F1,stroke:#0E7C86,color:#14201F;
  classDef indep fill:#E4F1EA,stroke:#2E7D5B,color:#14201F;
  classDef cross fill:#E1ECF7,stroke:#2B6CB0,color:#14201F;
  class P0 pre;
  class P1,P2,P3 chain;
  class P4 indep;
  class PX cross;
      

10.1 原排程建議（已被分批出貨取代，保留備查）

10.2 分批出貨計畫（2026-07-30 拍板）

改成三個批次序列推進，每批結束才做一次端到端測試。優先序本身（ZAP → InSpec → GCB → Nmap）沒有變，變的是「分批出貨而非三線並行」。

為什麼 ID 解耦仍然先做（理由已換）

原本把橫向項排在最前面的理由是「三條線同時開工會搶同一個 factory 檔」。改成序列執行後這個理由已不成立，但結論不變，換成另一組更硬的理由：

• ZAP 會是第 5 個工具。不解耦的話，ZAP 要在三個環境都 seed 成 id=5、agent 端硬編再加一行 5: "zap"——正好踩中 D11 要解的那個「三環境 seed id 必須完全一致，錯一位就靜默跑錯工具」的坑。
• 更關鍵：先硬編做完 ZAP、之後再解耦，ZAP 的派工鏈路要重測一次。這與本案「不要重複測試」的要求直接衝突。
• 因此 ID 解耦併入第一批、不另開 session——它與 ZAP 動到同一批檔案（task_executor / factory），同一批做完一起測，省一輪。

為什麼 FR-058.0 敏感參數留在第一批

技術上 ZAP 的被動與主動掃描不需要登入帳密，只有「登入後掃描」才需要 .0，理論上可以先出不含登入的 ZAP。仍決定留在第一批：

• 需求情境本來就是「有帳密就深掃」，拿掉它 ZAP 對稽核的價值少一半。
• 分兩次出等於整條鏈路要測兩輪；.0 只有 4 個子任務，不值得為省它而多測一輪。
• 若後續排程吃緊，這是第一批唯一可砍的部分——抽掉 T-1.4 登入後掃描先出，但要接受之後補測一輪。

第一批的 session 切分（按技能與 repo，非按卡片順序）

兩個 session 可大幅重疊：Session 2 採「有 code 用 code、無 code 退回 id」的 fallback 寫法，不被 Session 1 擋住；只有最後的 T-1.4（登入後掃描）真正需要等 Session 1 的解密接線（CM-963）。欄位名稱固定為 detection_tool_code（§詳細設計已定），兩邊照此不需即時協調。

10.3 測試紀律

真正耗時的不是跑測試本身，而是重建 agent image、部署三台、等 300 秒心跳。因此測試動作依成本分兩類：

10.4 Notion case 樹座標

母案：CM-957

共 27 張卡，Case No 連號無斷號。另有 CM-953（異質 OS 檢測方案）已由 FR-058.2 吸收並結案。實作期間另補開 CM-984、CM-986〜CM-988、CM-992 等卡——見 §11。

以下四項不在原規劃的 27 張卡內，是實作與實測過程中暴露出來的平台缺口。共同特徵是：都由某個具體工具觸發，但都不是那個工具的特例——因此一律做成宣告驅動或平台級機制，而非在程式碼裡寫工具分支。

11.1 互斥憑證組別（credential_group_schema）

觸發者：CINC Auditor 是平台第一個「一個工具帶兩組互斥憑證」的工具——SSH 憑證用於 Linux 目標、WinRM 憑證用於 Windows 目標，使用者通常只填打算掃的那一組。GCB 會是第二個，所以做成平台能力。

Schema 形狀：{probe_param_key, prompt_label, groups:[{key, label, description, probe_param_value}]}。為什麼不塞進 config_field_schema：那是一個 JSONB 陣列，加頂層 metadata 會把形狀從陣列變成物件，所有讀取端都要跟著改。Notion CM-986。

11.2 憑證部分更新改 merge 語意

11.3 取消執行中的檢測任務

觸發者：CINC 對 Windows 的完整 baseline 掃描動輒十分鐘起跳（實測 894 項檢查），發現參數填錯時沒有任何止損手段。

新增 endpoint POST /detection-tools/jobs/<job_uid>/cancel，復用 CM-931 已建立的取消鏈路（不另寫一套）。FE 在任務執行抽屜內，每筆 running 狀態紀錄旁加「取消執行」按鈕（confirm → 成功 toast → 刷新，loading 防連點）。

11.4 requires_credentials / requires_target_host 宣告欄位

兩個宣告欄位，共同目的是把「這個工具需要什麼」從程式碼的硬判改成 DB 的宣告。

Notion CM-981。這兩欄與 §11.1 的 credential_group_schema 是同一種手法——平台對具體工具維持零知識，靠工具自己的宣告行事，這正是 FR-056 tool-agnostic 精神的延伸。

11.5 四工具驗收狀態總表