母案：FR-058 檢測工具擴充（四工具接入）— FR-058 檢測工具擴充（四工具接入）（母案）

起源子需求：FR-058.3 GCB（政府組態基準，引擎複用 .2）— FR-058.3 GCB（政府組態基準，引擎複用 FR-058.2）

本案為 FR-058 之後的獨立需求（性質同 FR-058 後續：ZAP 登入後掃描支援 SPA（json 認證 + token session 管理））｜Repo：BE + FE + evidence-agent

背景

FR-058.3 已完成 GCB 的引擎層——依 D7 定案，GCB 不另立引擎、不另寫 connector，直接複用 FR-058.2 的 CINC Auditor connector；FR-058.3 本身只做一份 Windows 最小 Demo profile，驗收條件是「鏈路可運作」而非「涵蓋多少規則」。

content 產製與後台 content 管理機制已由 D7 明確排除出 FR-058 範圍，當時記錄的排除理由是「那是持續性人力投入，且是最沒有技術風險的部分」。本卡就是這兩件事的歸屬。

為什麼兩件事要合成一案

GPO 解析器產出的 profile 需要有地方存放、版更、套用——沒有管理機制，parser 產出的東西無處安放；反之管理機制沒有 content 也是空的。兩者天生綁在一起，拆成兩案會出現「做完一半但誰都用不了」的狀態。

官方資源實況（2026-07-31 更新：原結論已被推翻）

<aside> 🔄

下面這張表是 2026-07-30 當時的評估，保留為歷史記錄，不要照它排期。

當時結論是「Windows 約七成可自動化、Linux / macOS 幾乎零」。2026-07-31 這個結論被實作推翻——決策者自行寫的 twgcb2inspec.py 直接吃官方 .docx，Windows / Linux / macOS 三平台都產得出 profile。推翻後的實況見本節末的「2026-07-31 實際發生」與下一節。

</aside>

2026-07-30 當時的評估（歷史記錄，勿據此排期）

關鍵發現：說明文件頁有完整的 RHEL 8 / RHEL 9 / Ubuntu 22.04 / macOS 15 基準文件，但部署資源頁對這些平台沒有任何機器可讀檔案，連 shell script 都沒有。這印證了 NICS FAQ v1.6 §7.1「未提供 RHEL8 等平台自動化檢測工具」。

2026-07-31 實際發生：DOCX 本身就是可解析的來源

上表「只有 DOCX / PDF ＝ 幾乎零自動化」這個推論不成立。決策者自行撰寫的 twgcb2inspec.py 直接讀官方 .docx 產出 InSpec profile，三個平台都產得出來。

「NICS 沒給機器可讀檔案」這件事仍然是真的，但它不再等於不能自動化——.docx 是結構化文件，欄位（含「設定方法」欄的 shell 指令）本身就可解析。實際產出數字見下一節。

2026-07-31 實際進度

① 決策者已產出 23 支 profile（4,351 控制項 / 1,967 項可自動檢查，45%）

全部由 tools/twgcb2inspec.py 從官方 .docx 自動產生：