檢測工具整合平台 FR-056 討論稿

FR-056 · 需求討論稿 · 尚未定案

把檢測工具接進稽核任務,讓掃描自己跑、報告自己回。

租戶設定好自家的 OpenVAS 等掃描工具 → 任務指定「檢測工具執行」→ 按下開始 → 透過客戶端 Agent 觸發掃描 → 結果自動回收成該任務的證據 → 通知負責人。目標是把原本 user 要手動跑的整條流程自動化。

母案 FR-056 4 個子需求 · 分階段互不干擾 2026-07-26 狀態:討論中,等你審
01

你要的端到端流程

先把你描述的那條主線畫成時序圖,確認角色與資料流跟你想的一致,這是整個拆分的基準。

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','lineColor':'#5f7274','secondaryColor':'#EEF2F3','tertiaryColor':'#FBFCFC','fontFamily':'ui-monospace, monospace','fontSize':'13px','actorBkg':'#0E7C86','actorTextColor':'#ffffff','actorLineColor':'#0B5E66','signalColor':'#3a4a4c','signalTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#5a4410','noteBorderColor':'#c9a24a'}}}%%
sequenceDiagram
    autonumber
    actor Admin as 租戶管理員
    participant Web as Guidant AI (雲端)
    participant Agent as 客戶端 Agent
    participant Tool as OpenVAS
    actor Owner as 任務負責人

    Note over Admin,Web: 前置一次性設定
    Admin->>Web: ① 設定檢測工具 (url/key/token,加密存 config schema)
    Admin->>Web: ② 安裝 & 註冊 Agent (已有 mTLS 註冊機制)
    Admin->>Web: ③ 任務設為「檢測工具執行」+ 設掃描參數 (IP/網址/設備)

    Note over Owner,Tool: 執行期
    Owner->>Web: ④ 按下「開始執行任務」
    Web->>Web: 建立 agent_task (pending)
    Agent-->>Web: ⑤ 心跳輪詢,領到待辦任務
    Agent->>Tool: ⑥ 依連線型態呼叫 (API / CLI command)
    Tool-->>Agent: ⑦ 掃描完成,回傳報告
    Agent->>Web: ⑧ 回傳結果 + 報告檔
    Web->>Web: ⑨ 報告存回 job_evidences (source=DETECTION_TOOL)
    Web->>Owner: ⑩ 發信通知:掃描完成
    alt 完成模式 = auto
        Web->>Web: ⑪ 系統自動 complete_job → 任務完成
    else 完成模式 = manual
        Note over Owner,Web: 任務留在既有 PROCESSING 狀態(不新增狀態)
        Owner->>Web: ⑪ 看過報告 → 手動按完成,或抽屜內重掃 / 補上傳
    end
      
圖 1 — 端到端時序:設定 → 安裝 → 設任務 → 執行 → 回收 → 轉證據 → 通知 → 完成(auto 自動 / manual 人工按完成)
02

現況盤點:哪些能複用、哪些是空的

動手前先確認地基。這決定了工作量落在哪裡——好消息是認證鏈與「系統自動上傳證據」的 pattern 都已經存在,缺口集中在工具設定儲存與 Agent 派工。

前端頁面 純 mock

檢測工具管理頁 = 假資料

ToolPluginManage.vue 目前 7 個工具全寫死在前端、零 API、啟用只收一個 key 欄位、重整就重置。等於整頁要接真實後端重做。

Agent 認證 已完備

mTLS + JWT + 註冊 + 心跳都在

FR-039 的 Agent(獨立 repo evidence-agent/)自我註冊、憑證簽發、心跳輪詢已可用,agent_type 欄位已預留多型。認證這層不用重做。

Agent 任務下發 完全沒有

Agent 目前只會存取檔案

沒有 command queue / job dispatch 概念,心跳 payload 不夾帶待辦。Agent 端也沒有 executor 模組——「執行掃描」是全新範疇。

任務類型 要擴充

job_type 寫死 enum,真相在 BPMN

GrcJobType 只有 general / survey,任務顯示內容以範本 BPMN userTask 為準(actionType/actionInfo)。新增「檢測工具執行」要同步這條線。

證據自動上傳 有 pattern

DRIVE_SYNC 就是現成模板

job_evidences.source 已區分 SYSTEM_UPLOAD / DRIVE_SYNC,Google Drive handler 用系統帳號自動寫證據。檢測結果轉證據直接照這個 pattern 加一個 DETECTION_TOOL 來源。

config schema 不存在

沒有通用租戶設定表

最接近的是 tenant_drive_integrations(每租戶一筆、加密 token)。你要的 config schema 要新建——正好照它的加密範式做。

03

架構總覽

新增一個 config schema 放租戶設定與工具目錄;Agent 長出執行能力;掃描結果沿既有證據管線回流。DDD 分層與既有規範不變。

%%{init: {'theme':'base','themeVariables':{'fontFamily':'ui-monospace, monospace','fontSize':'12px','lineColor':'#5f7274','clusterBkg':'#FFFFFF','clusterBorder':'#c7d1d2'}}}%%
flowchart TB
    subgraph CLOUD["雲端 · Guidant AI"]
      direction TB
      FE["前端
檢測工具管理頁 · 任務設置頁"] subgraph BE["後端 (DDD)"] SVC["App Service
工具設定 · 派工 · 結果回收"] subgraph CFG["config schema (新)"] T1["detection_tools
工具目錄"] T2["tenant_detection_tool_configs
租戶憑證 (加密)"] T3["detection_tool_param_schemas
動態欄位定義"] end subgraph COMP["compliance schema"] T4["agent_tasks (新)
派工 + 狀態機"] T5["detection_executions (新)
執行歷史"] T6["job_evidences
證據 (既有)"] end end FE --> SVC --> CFG SVC --> COMP end subgraph SITE["客戶端"] AG["Agent (evidence-agent)
+ 新 executor 模組"] OV["OpenVAS
(未來 Nessus / SonarQube)"] AG -->|API / CLI| OV end SVC <-.->|mTLS+JWT 心跳夾帶派工| AG AG -.->|回傳報告| T6 classDef node fill:#E2F0F1,stroke:#0E7C86,stroke-width:1px,color:#14201F; classDef nodeNew fill:#EDE7F5,stroke:#7A5AA8,stroke-width:1px,color:#241938; classDef nodeExt fill:#F6EBD5,stroke:#9C6B12,stroke-width:1px,color:#4a3608; class FE,SVC,T6 node; class T1,T2,T3,T4,T5,AG nodeNew; class OV nodeExt; style CLOUD fill:#FBFCFC,stroke:#c7d1d2,color:#4A5A5C; style SITE fill:#FBFCFC,stroke:#c7d1d2,color:#4A5A5C; style BE fill:#F3F6F6,stroke:#d3dcdc,color:#4A5A5C; style CFG fill:#FFFFFF,stroke:#b9d4d6,color:#0B5E66; style COMP fill:#FFFFFF,stroke:#cdd6d7,color:#4A5A5C;
圖 2 — 架構:新 config schema(工具目錄+加密憑證+動態欄位)+ Agent executor + 沿用證據管線
04

四個子需求,分階段互不干擾

每一階段都能「獨立上線、獨立驗收」——不是切一半才有價值。前一階段沒接下一階段時,交付物本身仍是完整可用的功能。

01

FR-056.1

檢測工具管理(config schema + 工具目錄)

依賴:無
可先開工

交付

  • 新建 config schema + 三張表(工具目錄 / 租戶憑證 / 動態欄位定義)
  • 檢測工具管理頁接真實 API:清單由 DB 提供、不再寫死
  • 依工具不同動態渲染設定欄位(JSONB schema 驅動)
  • 憑證加密存放;啟用 / 停用 / 重置 key
  • 停用或重置時提醒「有任務正被配置」(提醒不擋)
  • 測試連線功能;OpenVAS 可設定,其餘工具灰掉「敬請期待」

獨立驗收

  • 管理員能建立 / 編輯 / 停用 OpenVAS 設定並通過測試連線
  • 重整後設定持久化,憑證在 DB 為密文
  • 不需要 Agent、不需要任務,這頁自己就能用
02

FR-056.2

任務類型「檢測工具執行」+ 參數設定

依賴:FR-056.1
(需工具目錄)

交付

  • 任務設置頁新增任務類型「檢測工具執行」(同步 BPMN userTask)
  • 選定後可選要用哪個工具(清單來自 FR-056.1)
  • 依工具的檢測項目動態呈現參數欄位(掃哪些 IP / 設備 / 網址)
  • 參數 schema 存 config、可版更調整欄位
  • 參數存在任務上(mirror 問卷綁定 pattern)
  • 完成模式 flag:auto 自動完成 / manual 系統不自動完成(掃完先看報告再手動按完成)

獨立驗收

  • 任務能被設為檢測工具執行並存下工具+參數+完成模式
  • 重開任務參數還在;此時「執行」還沒接,屬設定期
  • 不影響既有 general / survey 任務
03

FR-056.3

Agent 執行能力擴充(派工 + executor + OpenVAS connector)

依賴:FR-056.1
可與 .2 並行

交付

  • 雲端:agent_tasks 表 + 派工 service + 結果回收 endpoint
  • 派工機制:心跳夾帶待辦(最小改動,見 §06
  • Agent 端新增 executor 模組:執行 API 呼叫 / CLI command
  • OpenVAS connector(三層 adapter,mirror FR-043/044)
  • Agent capability 標記(能執行掃描的 agent 才派)

獨立驗收

  • 手動塞一筆 agent_task,Agent 領到、跑 OpenVAS、回傳報告
  • 認證沿用既有 mTLS+JWT,不需新設計
  • 可脫離 UI 用測試腳本驗證整條 dispatch → result 鏈
04

FR-056.4

執行編排 + 結果轉證據 + 通知 + 歷史

依賴:.1 / .2 / .3
收尾整合

交付

  • 任務執行抽屜:「開始執行」按鈕串起派工 → 回收全鏈
  • 可手動重新執行:看過報告不滿意 → 抽屜內再觸發一次掃描
  • 報告自動存回 job_evidencessource=DETECTION_TOOL
  • 執行歷史列表detection_executions):每次執行一筆、狀態 + 摘要 + 報告下載連結
  • 發信通知任務負責人(既有 mail 機制)
  • 完成模式=auto → 掃完系統自動 complete_job;=manual → 任務留 PROCESSING,user 手動按完成

獨立驗收

  • 自動模式:按下到證據入庫、收信、任務完成全自動
  • manual 模式:掃完任務留 PROCESSING(非新狀態),user 能看報告、重掃、補上傳、或按既有「完成任務」
  • 執行歷史每次都留、可查可下載;失敗有明確狀態不 silent fail

階段依賴關係

%%{init: {'theme':'base','themeVariables':{'fontFamily':'ui-monospace, monospace','fontSize':'13px','lineColor':'#5f7274'}}}%%
flowchart LR
    A["FR-056.1
工具管理
config schema"] --> B["FR-056.2
任務類型
+ 參數"] A --> C["FR-056.3
Agent 派工
+ executor"] B --> D["FR-056.4
執行編排
證據 · 通知"] C --> D style A fill:#E2F0F1,stroke:#0E7C86,stroke-width:2px,color:#14201F style B fill:#E2F0F1,stroke:#0E7C86,stroke-width:1px,color:#14201F style C fill:#E2F0F1,stroke:#0E7C86,stroke-width:1px,color:#14201F style D fill:#EDE7F5,stroke:#7A5AA8,stroke-width:2px,color:#241938
圖 3 — .1 是地基;.2 與 .3 可並行;.4 收尾整合
04·5

每階段再拆 session 大小的子任務

怕單一 session context 不夠跑完整個階段,也為了分散風險——每個子任務切到「一個 session 跑得完、有明確產出、可獨立 commit」的顆粒。每個子任務對應一張 Notion 子卡,跨 session 從 Notion 就能接上。

怎麼用:一個 session 認領一個子任務(T-x.y),做完 commit + 回寫 Notion 子卡狀態,下個 session 從 Notion 看依賴接續。子任務內若又發現太大,當場再切,別硬塞。
FR-056.1

檢測工具管理 · config schema

子任務範圍產出 / 驗收依賴
T-1.1config schema + 三張表 migration(含 GRANT cm_app、schema_migrations 登記);seed OpenVAS 一筆 detection_toolsmigration 套進 DEV,psql 查得到表與 seed;符合 sql-migration 規範
T-1.2BE:detection_tools 目錄唯讀 API(DDD 全層:domain/app/infra/route);工具清單改由 DB 提供GET 清單回 OpenVAS + coming_soon 工具;有 pytestT-1.1
T-1.3BE:租戶工具設定 CRUD(tenant_detection_tool_configs)+ 憑證加密存放(沿用 drive integration 加密範式)建/改/停用設定;DB 內憑證為密文;有 pytestT-1.1
T-1.4BE:測試連線 endpoint(對 OpenVAS 實際打一次驗證 url/憑證)+ 停用/重置時「引用任務數」提醒查詢(D6)測試連線回成功/失敗;提醒回引用數T-1.3
T-1.5FE:檢測工具管理頁重做——接真 API、動態欄位(config_field_schema 驅動)、啟用/停用/重置、測試連線、coming_soon 灰掉整頁走真後端;重整持久化;mock 全移除T-1.2 / T-1.3 / T-1.4
FR-056.2

任務類型「檢測工具執行」+ 參數

子任務範圍產出 / 驗收依賴
T-2.1BE:GrcJobType 加 detection_tool + BPMN userTask 同步線(actionType/actionInfo 回寫 template xml)任務可存為 detection_tool 類型並同步範本;有 pytest—(可與 P1 並行)
T-2.2BE:detection_tool_param_schemas 版本化參數定義 + 任務綁定工具+參數快照 + 完成模式 flag(mirror 問卷綁定)任務存下工具/參數/完成模式;重開還在;有 pytestT-1.1 / T-2.1
T-2.3FE:任務設置頁——選「檢測工具執行」→ 選工具 → 動態參數欄位(param_schema 驅動)+ 完成模式選擇設定期完整可存;不影響 general/survey 任務T-2.2
FR-056.3

Agent 執行能力擴充

子任務範圍產出 / 驗收依賴
T-3.1BE:agent_tasks 表 + 派工 service + 狀態機(pending→dispatched→running→succeeded/failed);Agent capability 標記能建派工單、查狀態;有 pytestT-1.1
T-3.2BE:心跳夾帶待辦(heartbeat 回應加 pending_tasks)+ ack + 結果回收 endpoint(POST /agents/tasks/{id}/result,沿用 mTLS+JWT)心跳領到任務、result 回收改狀態;有 pytestT-3.1
T-3.3Agent 端(evidence-agent repo):executor 模組骨架——領任務、回報 running、送 result;沙箱/權限邊界能收派工並回報;不含具體工具邏輯T-3.2
T-3.4Agent 端:OpenVAS connector(三層 adapter,API/CLI 兩型;mirror FR-043/044 registry)手塞派工→跑 OpenVAS→回報告全鏈通T-3.3
FR-056.4

執行編排 + 轉證據 + 通知 + 歷史

子任務範圍產出 / 驗收依賴
T-4.1BE:結果轉證據 handler(detection_executions 落一筆 + 報告存 Minio → job_evidences source=DETECTION_TOOL;沿用 DRIVE_SYNC 模板)result 進來自動生執行史 + 證據;有 pytestT-3.2
T-4.2BE:執行編排——「開始執行」串派工、完成模式分岔(auto 呼叫既有 complete_job / manual 不做事任務留 PROCESSING)、失敗狀態、發信通知負責人auto & manual 各驗一次;失敗不 silent;負責人收信T-2.2 / T-3.1 / T-4.1
T-4.3FE:任務執行抽屜——開始執行 / 手動重新執行 / 執行歷史列表(狀態+摘要+報告下載);manual 靠既有「完成任務」按鈕(不新增 UI)auto & manual 全鏈手測通;重掃留歷史可比對T-4.2
總計 15 個子任務(5 / 3 / 4 / 3)。BE 與 FE 子任務可分不同 session;跨 repo(Agent 在 evidence-agent、FE 在 compliance-manager-fe)已標註。每個子任務=一張 Notion 子卡,掛在對應 FR-056.x 子需求下、再掛回母案 FR-056。
05

資料模型草案

config schema 不是通用 key-value blob(那會腐化),而是明確 typed 表。動態欄位用 JSONB schema 承載「每種工具長不一樣」的需求,讓未來加工具 / 調欄位走版更就好。

config.detection_tools — 工具目錄(取代前端寫死清單)
欄位型別說明
id / uidPKbigint / uuid主鍵
codevarcharopenvas / nessus / sonarqube(唯一)
name / descriptionvarchar / text顯示名稱、說明(可 i18n)
connection_typevarcharAPI / CLI——決定 executor 走哪條
config_field_schemajsonb設定頁要填的欄位定義(key/label/type/required/secret)
statusvarcharavailable / coming_soon(灰掉不給設定)
enabledbool平台層總開關
config.tenant_detection_tool_configs — 租戶各自的工具設定與憑證
欄位型別說明
id / uidPKbigint / uuid主鍵
tenant_id / org_unit_iduuid租戶隔離(org_unit 預留部門層級,先以租戶為主)
detection_tool_idFK指向 detection_tools
credentials加密jsonb / texturl / key / token / 帳密——加密存放(mirror drive integration)
field_valuesjsonb對應 config_field_schema 的非機敏值
statusvarcharenabled / disabled
last_tested_at / resulttimestamptz最後一次測試連線的時間與結果
config.detection_tool_param_schemas — 任務執行時要填的掃描參數定義(版更用)
欄位型別說明
idPKbigint主鍵
detection_tool_idFK指向 detection_tools
versionint欄位定義版本——調欄位不覆蓋舊版
param_schemajsonb參數欄位定義(掃 IP 清單 / 網址 / 設備群 / 掃描 profile…)
compliance.agent_tasks — 派工單 + 狀態機(雲端 ↔ Agent 的信箱)
欄位型別說明
uidPKuuid主鍵
tenant_id / agent_iduuid / FK派給哪台 Agent
job_execution_uidFK對應哪個稽核任務
detection_tool_idFK用哪個工具
paramsjsonb本次掃描參數快照
statusvarcharpending → dispatched → running → succeeded / failed
result_ref / errorjsonb / text結果檔參照 / 失敗訊息
compliance.detection_executions — 執行歷史(一次執行一筆,可查可下載)
欄位型別說明
uidPKuuid主鍵
agent_task_uidFK對應派工單
job_execution_uidFK對應任務
started_at / finished_attimestamptz執行區間
status / summaryvarchar / jsonb成敗 + 摘要(如發現幾項)
report_file_idFK原始報告檔(→ upload_files,供下載)
evidence_idFK轉出的證據(→ job_evidences)
命名待定。表名與 schema 名先照直覺草擬,正式建表前會依 sql-migration 規範定案(GRANT cm_app、schema_migrations 登記等)。
06

Agent 怎麼領到任務、怎麼把結果送回來

既有心跳是輪詢式(Agent 每 N 秒主動打雲端)。最小改動是讓心跳回應「順便夾帶待辦任務」,Agent 領走執行、再用獨立 endpoint 回傳結果。認證整條沿用既有 mTLS+JWT,不新設計。

%%{init: {'theme':'base','themeVariables':{'primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86','lineColor':'#5f7274','fontFamily':'ui-monospace, monospace','fontSize':'13px','actorBkg':'#0E7C86','actorTextColor':'#ffffff','signalTextColor':'#14201F','noteBkgColor':'#F6EBD5','noteTextColor':'#5a4410','noteBorderColor':'#c9a24a'}}}%%
sequenceDiagram
    autonumber
    participant Web as 雲端 BE
    participant Agent as Agent (輪詢迴圈)
    participant Tool as OpenVAS
    loop 既有心跳每 N 秒
        Agent->>Web: heartbeat (mTLS+JWT)
        Web-->>Agent: { status:ok, pending_tasks:[...] }
    end
    Note over Agent: 領到 scan 任務
    Agent->>Web: ack (task → dispatched)
    Agent->>Tool: 執行掃描 (API/CLI)
    Agent->>Web: 回報 running
    Tool-->>Agent: 報告產出
    Agent->>Web: POST /agents/tasks/{id}/result + 報告檔
    Web-->>Agent: 200 (task → succeeded)
      
圖 4 — 派工走既有心跳搭便車,結果走獨立 result endpoint
已知取捨:輪詢有心跳間隔延遲(掃描本來就是長工,通常可接受)。若之後要「按下去立刻跑」的即時感,再評估縮短掃描任務的輪詢間隔或加推播——這在待拍板決策 D3。

結果轉證據——沿用 DRIVE_SYNC 模板

Agent 回傳報告後,雲端照 ImportDriveFileHandler 同一套路:檔案存 Minio → 寫 job_evidences,只是 sourceDRIVE_SYNC 換成新的 DETECTION_TOOLcreated_user 用系統帳號(如 detection-agent@system)。既有證據列表、刪除連動邏輯全部自動涵蓋。

執行抽屜、完成模式與重掃

完成模式只是「系統要不要幫忙自動按完成鍵」的 flag,不新增任何任務狀態。掃描完成、證據入庫、發信後,依完成模式:auto 系統自動呼叫既有 complete_job(任務 PROCESSING → COMPLETED);manual(預設)系統什麼都不做,任務留在既有 PROCESSING 狀態,執行人員收信後自行判斷證據可用否——可用就手動按「完成任務」(走既有 complete_job,跟一般任務一樣),不可用就在抽屜再按執行重掃、或補上傳一份證據,再手動完成。零新增 JobStatus、不動 jedi_flow_engine。每次執行都是 detection_executions 一筆獨立紀錄——重掃不覆蓋前一次,歷史完整保留、可下載比對。

%%{init: {'theme':'base','themeVariables':{'fontFamily':'ui-monospace, monospace','fontSize':'13px','lineColor':'#5f7274','primaryColor':'#E2F0F1','primaryTextColor':'#14201F','primaryBorderColor':'#0E7C86'}}}%%
flowchart TB
    A["任務 PROCESSING(既有狀態)"] --> B["按「開始執行」→ 派工 → Agent 掃描 → 回報告"]
    B --> C["證據入庫 + detection_executions 落一筆 + 發信通知負責人"]
    C --> D{"完成模式"}
    D -->|auto| E["系統自動 complete_job → COMPLETED"]
    D -->|manual| F["任務仍 PROCESSING,等人工判斷"]
    F -->|證據可用| G["手動 complete_job → COMPLETED"]
    F -->|不可用| H["抽屜重掃(留歷史)或補上傳證據 → 再手動完成"]
    B -.->|掃描失敗| I["detection_executions 標 failed(不 silent),任務仍 PROCESSING 可重試"]
    classDef ok fill:#E4F1EA,stroke:#2E7D5B,color:#14201F;
    classDef warn fill:#F6EBD5,stroke:#9C6B12,color:#4a3608;
    classDef crit fill:#F6E2DE,stroke:#B93A2B,color:#4a1510;
    classDef base fill:#E2F0F1,stroke:#0E7C86,color:#14201F;
    class A,B,C base
    class E,G ok
    class F,H warn
    class I crit
      
圖 5 — 任務執行流程(沿用既有 JobStatus,零新增狀態):auto 系統自動完成 / manual 任務留 PROCESSING 等人工手動完成
07

要你拍板的決策

這些是會影響拆分與工作量的岔路口。每項附上我的建議,你可以直接點頭或改方向;定案後才寫 design.md 與開 Notion。

D1

config schema 的定位:只放檢測工具,還是「未來所有設定檔」的家?

你提到想當作未來所有設定的存放地。但通用 key-value 設定表長期會腐化成垃圾抽屜。

建議config 作為「設定類 schema 命名空間」,但裡面放明確 typed 表(detection_tools 等),未來別種設定各自開 typed 表進來,而不是塞單一 blob。既滿足「集中放設定」又不失結構。
D2

憑證加密方式?

租戶的 key/token/帳密要加密存放。既有 tenant_drive_integrations 用 app 層加密欄位(refresh_token_encrypted)。

建議沿用同一套 app 層對稱加密(金鑰走環境變數 / 部署密鑰,不進版控)。與既有 Drive 整合一致,不引入新 KMS 依賴。
D3

Agent 派工機制:心跳搭便車 vs 獨立輪詢 vs 推播?

即時性 vs 改動量的取捨。掃描是長工,秒級延遲通常無感。

建議先做心跳夾帶待辦(改動最小、認證零改)。若手測體感需要更即時,再對掃描任務縮短輪詢間隔;推播(SocketIO)列為未來,不進第一版。
D4

掃描報告要不要當場 parse 成結構化 findings?

OpenVAS 產 XML/報告。可以只存原始報告,也可以解析成漏洞條目餵進系統(像 FR-044 的逐條 finding)。

建議第一版只存原始報告當證據(滿足「報告變證據」的核心需求)。parse 成 findings / 自動配對控制項是明顯更大的題目,獨立成未來 FR,不混進來。
D5

工具 connector 架構?

OpenVAS 之後有 Nessus / SonarQube,每種 API/CLI 都不同。

建議三層 adapter(工具 × 連線型態 × 共用 core),沿用 FR-043/044 registry 泛化的成熟 pattern。第一版只實作 OpenVAS,但把介面留好。
D6

停用 / 重置時「有任務正被配置」的提醒——查到什麼程度?

你說「提醒就好,不擋」。要提醒得先查出「哪些任務綁了這個工具設定」。

建議停用 / 重置前查一次「引用此工具設定的任務數」,彈窗提醒數量+放行,不硬擋(比照 FR-051 軟提醒模式)。
D7

部門(org_unit)層級設定:第一版做不做?

你說「有可能到部門先預留,但一開始先以租戶為主」。

建議表結構留 org_unit_id 欄位(預留),但第一版邏輯只做租戶層級。未來要下放部門時不用改 schema。
D8

完成模式的預設值?

你要求任務設定時用 flag 決定掃完是否自動完成,讓 user 可先看報告再決定要不要重掃。新任務建立時,這個 flag 預設哪一邊?

定案預設 manual(系統掃完不自動按完成,任務留 PROCESSING 等人工)。掃描結果通常需人確認才算數;auto 則掃完自動 complete_job。注意 manual 不是新狀態,只是系統不主動呼叫既有 complete_job——零 JobStatus 新增、不動 jedi_flow_engine。
D9

憑證怎麼到 Agent?

Agent 要連客戶端 OpenVAS 需要帳密,憑證怎麼給?

定案雲端解密後隨派工下發(走既有 mTLS 通道,Agent 用完即丟不落地)。雲端仍是憑證唯一保管處(加密存放)。不採 Agent 自持——要客戶在 Agent 端自設不實際,雲端 UI 統一設定才符合產品體驗。
D10

OpenVAS 整合方式?

連 OpenVAS 走 API 還是 CLI?

定案走 API(python-gvm,GVM protocol),非 CLI。程式化控制掃描比解析 CLI 輸出穩定;與工具目錄 seed 的 connection_type=API 一致。
D11

掃描報告的 evidence_type?

報告轉證據時 evidence_type 用哪個值?

定案用既有 FILE,不用 REPORT。REPORT 型別會牽動其他判斷證據檔案的地方、改動面大;第一版 FILE 最安全,要區分檢測報告類證據未來另開需求。
08

Notion 追蹤結構(定案後建立)

你這次特別要求:交接不能再歪掉,Notion 上要留完整脈絡。規劃母案+四子項的關聯結構,每項都掛需求編號、狀態、依賴。

  • 第 1 層 · 母案 FR-056「檢測工具整合平台」——總體目標、四階段索引、本討論稿連結、D1–D8 決策定案結果
  • 第 2 層 · FR-056.1 ~ .4 四個子需求各一張卡,關聯回母案,帶交付 / 依賴 / 獨立驗收
  • 第 3 層 · T-x.y 子任務 15 張子卡,各掛在對應 FR-056.x 下——這是 session 認領的顆粒,帶範圍 / 產出驗收 / 依賴 / 跨哪個 repo
  • 每張卡填「需求編號」欄位(照最近 commit 落地的填寫規則)
  • session 做完子任務:commit + 回寫該 T-x.y 子卡狀態,下個 session 從 Notion 看依賴接續,交接不歪
  • 本 HTML 討論稿定稿後轉存 docs/features/FR-056-2607-detection-tool-integration/design.md
下一步:(本討論稿已完成審閱,D1–D8 全數拍板、design.md 與 Notion 母子卡已建、四份實作計畫已產出——見下方第 09 節。)
09

實作計畫(runner 導向)

四階段各一份 implementation-plan,已寫成 runner 拿了就能照跑的顆粒:實際 SQL migration、DDD 九層照抄範本、TDD bite-sized 步驟、psql/curl/pytest 驗收指令。點卡片進各份計畫,每頁頂端可切換階段或返回這份討論稿。

完成模式已澄清:manual 只是「系統掃完不自動按完成」的 flag——任務留在既有 PROCESSING 狀態,執行人員自判證據可用否,手動按既有「完成任務」;不可用就重掃或補上傳。零新增 JobStatus、不動 jedi_flow_engine