FR-177 總結報告：Guidant AI Agent 本體資安掃描

掃描時間 2026-11-05 23:30 ～ 11-06 05:00，25 棒全部完成。掃描對象：Agent repo evidence-agent 釘 commit bab2aa3（第二、三期因報告合回而落在 3813abd／749d3b4／63334f4，程式碼與 bab2aa3 相同）。工具：Claude Code 官方 claude-security plugin 0.12.0，每棒一位研究員讀全範圍、三位獨立檢查員對每條候選投票。首腦對每條通過的發現都開檔核對過行號與呼叫路徑；高風險那條四段逐行核對攻擊路徑。

這是 PM 版：講有什麼問題、多嚴重、為什麼、怎麼修的方向、先修哪些。不含程式檔名與行號（漏洞還沒修，位置不公開）。要看每條的確切位置與函式級修法，請看 Agent repo 內的工程師版 docs/security-scan/FR-177/SUMMARY-engineering.md。跨六輪掃描的累積總表在 security-scan-consolidated/。

🔴 結論：要修 1 件急的、12 件中等的，修法方向已定

Agent 是我們裝在客戶自己機器上的程式。前六輪資安掃描（2026-09，140 輪）掃的全是主系統與套件，Agent 本體一個檔都沒掃過；這一次補上。

核實乾淨的部分，每一塊至少兩棒從不同角度看過：自動更新鏈（下載→驗指紋→用現行版驗新版原廠簽章→擋降版，新版程式在驗章前一行都沒執行）、Ed25519 簽章核心與啟動完整性閘、8443 的身分驗證守門殼、Agent 對外連線的 TLS 驗證沒有任何關閉的路、瀏覽器直傳的一次性票券、本機登入的密碼雜湊與鎖定、祕密保管的加密。

這一輪的方法論結果：25 棒全部面板完整跑完、無一棒中斷、runner 無一棒缺交。這是六輪掃描以來第一次，原因是每棒壓在 1,000 行上下、且用工作坊的開場 prompt 自動啟動。

Agent 本體 237 支 Python、約 27,400 行，加 3 支主機端升級腳本（bash）。按「客戶內網直接打得到的入口」優先，分三期：

沒掃、首腦用 grep 補查的：設定檔、依賴注入接線、錯誤碼表、各 port 介面、migration。

每棒的 scope 寫死在 Notion 卡上，研究員越界讀到的東西驗收時挑掉。

嚴重度判準：高＝不需要特殊前提就能拿到不該拿的控制權或資料；中＝要先有某個前提（已登入、特定權限、在內網特定位置）；低＝只能讓已經在裡面的人多留一會、或多看到一點。每條的「出處」指向逐棒報告與跨 arc 總表的項次。

🔴 高（1 條）

#223 主控台手動掃描可手填任意 InSpec 規則包，Agent 原樣執行

• 這是什麼問題：主控台「手動掃描」頁選 CINC Auditor／InSpec 工具時，profile 欄位可以填任何路徑或網址。這個值一路傳到執行點都沒有人擋，Agent 就用它跑 cinc-auditor exec <你填的東西>。規則包本質是 Ruby 程式碼。
• 出事會怎樣：填一個攻擊者自己寫的規則包網址，Agent 主機就執行了攻擊者的程式。Agent 主機上存著客戶所有掃描工具的帳密（SonarQube token、SSH／WinRM 帳密）、Agent 自己的私鑰、本機資料庫，全部讀得走。
• 要先有什麼才打得到：主控台帳號有「發動本機掃描」權限、Agent 設好了 InSpec 帳密、目標清冊至少有一台主機。任何正常使用中的 Agent 都滿足。
• 在哪裡：主控台路由層 → 本機掃描排程 → InSpec 接頭，四段都沒有擋，首腦逐行核對過。
• 怎麼修：手動掃描只准選「主系統同步下來的規則包」，手填路徑一律拒收；同時把主控台的參數過濾改成「每個工具列舉可以收哪些欄位」，而不是現在的「只擋底線開頭」。
• 出處：B5 F1（3:0）、B2 M1（3:0）、C2 F1 再確認。

中（12 條）

低（9 條）

人工查到、判定不開卡的觀察（記錄用）

各棒 runner 照卡上「重點看什麼」逐條人工補查，另記下約 15 條「設計取捨」或「縱深防禦建議」，都不算漏洞：清冊接受 0.0.0.0/0 萬用網段（主系統本來就能列任何 IP）、舊清冊可回放（版本只比相同不比大小）、啟動閘不擋清單外多出的檔（要先有 root）、裝置指紋兩來源都讀不到時退化成固定值（靠主系統撞號偵測）、SonarQube 源碼包內的 sonar-project.properties 沒刪、ZAP 逾時使用者可改到沒上限、ZAP 報告原樣上傳不遮蔽、票券重放紀錄只在記憶體（重啟即忘，註解寫明刻意接受）等。全部列在各棒報告的「重點看什麼逐條人工查證」表與總表 §3.1 各項尾註。

① 路由層把使用者輸入原樣交下去，沒有每工具／每欄位的白名單。#223、#224、#229、#232、#233 五條根因相同：主控台路由只擋底線開頭的參數鍵、清冊只比對固定幾個鍵名，其餘什麼都放。第三期 C1～C4 從 connector 內部再看，確認 connector 自己也沒有再擋一層。修一處（路由層改成每工具列舉可收的鍵）就能一次關掉五條。

② 「位址可以改，但沒有要求重填祕密或提升權限」。#227 LDAP 來源與 #232 工具位址都是同一件事：改了連線對象，舊的祕密會自動送到新對象。我們的資安需求 SR-06.3 明寫要擋，LDAP 設定頁有擋、工具設定頁沒有，是同一個人寫的兩頁行為不一致。

③ 「該踢的時機沒踢」。#220、#221、#228 三條都是登入狀態的生命週期：沒有絕對上限、改密碼不撤銷、縮權不撤銷。同一支 改三處。

④ 「連外部工具時不驗對方身分」。C2-F2 InSpec SSH 不驗主機指紋、C4-F1 連 ZAP 明文且不驗憑證、#238 連 OpenVAS 不驗憑證，三條都是 Agent 對客戶自備掃描工具的連線沒有「確認對方真的是那台」。Agent 對主系統的連線這點做得很嚴（A1／B6b 核實無任何關閉驗證的路），對掃描工具卻全漏，是同一支程式裡兩套標準。

另外兩個單點但要特別講：#234 手動升級路徑與自動路徑的防線不對稱，自動路徑三道鎖都在、手動路徑漏了驗章那一道；C2-F2 InSpec 不驗主機指紋與 OpenSCAP／Nmap 不對稱，三支同型接頭只有一支漏。這兩條都是「同一件事做了兩遍、一遍對一遍錯」，修法是對齊到對的那一邊。

併卡原則：同一根因併一張、同一支程式併一張；嚴重度高的先。每張的函式級修法在工程師版。

零碎：#219 私鑰建檔權限併進 ①或 ⑤。

要寫測試：卡 ①、②、⑥ 屬認證／授權核心，要寫單元測試並附突變測試（把修法註解掉要紅）。手測：卡 ① 在 DEV Agent 主控台填外部網址當規則包要被擋；卡 ④ 在 190 測試機用改過一個 byte 的假交付包跑升級要被擋。

1. 卡 ①（含 #223 高）先做。它是唯一不需要特殊位置、只要一個正常權限的帳號就能拿到 Agent 主機控制權的；而且一張卡關掉六條。
2. 卡 ④ 與卡 ⑥ 次之。#234 與 C2-F2 都是「同型的三條路，兩條對一條錯」，修法是抄對的那一邊，工作量小、風險低，但後果（主機 root、客戶稽核帳密）大。
3. 卡 ② 要先問產品：LDAP 設定收到只准本機管理員，會不會擋到客戶正常的 IT 管理流程。
4. 卡 ③、卡 ⑤ 可排一般迭代。

落地版判準：上面全部是落地版客戶內網打得到的，沒有「只影響 SaaS 可暫緩」的項目。

第一層：「這些問題是真的嗎」→ ✅ 可信

• 每條通過的發現都經三位獨立檢查員從「打不打得到」「後果多大」「有沒有別的防線」三個角度投票；25 棒 32 條候選、96 張票全部投出、零漏投。通過 22 條（3:0 為主，三條 2:1）、否決 10 條。
• 首腦對每條通過的發現開檔核對；#223 四段逐行核對攻擊路徑；#234 核對手動路徑與自動路徑的時序對照。
• 唯一例外：#219 是 runner 人工發現、未經面板，首腦核對程式邏輯屬實，但實際風險取決於安裝腳本有沒有先鎖目錄（沒查）。
• 兩處「採信檢查員讀第三方套件原始碼」：C2 train-core 預設不驗 host key、C4 zapv2 寫死 verify=False，首腦沒有重讀 gem／site-packages。

第二層：「是不是只有這些」→ ⚠️ 中等，不能說「掃乾淨了」

• 用的是 low effort：每棒一位研究員讀全範圍、不做威脅建模、不做廣度掃描。工具有隨機性，同一份程式再掃可能找到不同的東西。
• 六棒工具零候選（A1、A3、B6b、B8、C6，與否決後歸零的 A5、A8、C3）：verified 在那裡的意思是「沒東西可投」，不是「有人確認乾淨」。這五棒靠 runner 照「重點看什麼」逐條人工補查，每棒補查 6～8 項並寫下結論。
• 全部結論來自讀程式碼，沒有執行任何程式、沒有實際打過。#225（8443 握手卡住）、#226（tar 計數吃記憶體）這類 DoS 是讀 werkzeug／tarfile 原始碼推論的，沒有實測。

比前六輪可信的地方

• 25 棒全部跑完，無一棒面板中斷、無一棒 runner 缺交，首腦不必補寫任何一份報告（前六輪首腦補了十一次）。
• 每棒都有「重點看什麼逐條人工查證」表，「讀過但沒報」與「根本沒讀到」分得開。

① 工作坊可以跑掃描卡。claude-security 只接受使用者回合的啟動句，前六輪都要決策者親手打；這次工作坊加了「每張卡一支開場 prompt 覆寫檔」，把啟動句當小弟 session 第一句送進去，25 棒全部自動啟動。工作坊的停滯判定（session busy 就不判卡死）也在真掃描上驗過。

② 全中文 docstring 的程式，安全線是 1,000 行不是 2,000。Agent 的註解密度是英文碼的兩三倍 token，第一期按 1,000 行切，25 棒零看門狗誤殺；第三期 C1 單檔 1,711 行、10,364 個中文字也跑完了（研究員 2/2、零 failed），C2 單檔 1,050 行、C8 十檔 1,291 行也都零 failed，表示「單檔一次讀完不追接縫」比行數更關鍵，並行四棒也沒影響。

③ 人工補查抓到的不比工具少。工具通過 19 條，runner 照首腦列的重點人工補查另抓到 #219 一條中、約 15 條觀察，並且把五棒工具零候選的範圍填上了「讀過」的證據。「重點看什麼」是這套方法裡成本最低、回報最高的一段。

第三期掃的是 Agent 組參數去跑外部工具的地方。首腦開卡前最擔心的三件事，結果如下：

真正找到的是另一族：三支接頭連客戶自備的掃描工具時不驗對方身分（InSpec 主機指紋、ZAP 明文、OpenVAS 憑證），加上兩條低風險的可用性問題（DNS 探測可被卡死、代理帳密沒遮）。C1 SonarQube 與 C6 SBOM 在工具層淨新增零，人工補查各記了三條不開卡的觀察。

Semgrep 事前掃整個第三期範圍只命中一條（程式 subprocess 吃 env），第三期六條發現沒有一條是規則掃描器抓得到的，全部是「程式寫法正確（list argv、quote 過）但對象錯或少一道驗證」這類要靠讀程式才看得出的問題。

等決策者裁的事

1. #223 要不要在第三期驗完前就開修正卡（建議：要，它不等其他條）。
2. 第四節六張修正卡的併法與第五節順序，裁了首腦開卡進工作坊。
3. 卡 ② LDAP 設定收到只准本機管理員是否符合客戶 IT 流程。
4. 逐棒報告 25 份含未修漏洞的檔名與行號，複本目前在 feature/FR-172 分支的 docs/features/FR-177/reports/，合回 main 會隨需求文件站上線。總結報告已拆成 PM 版（上站、無行號）與工程師版（Agent repo、不上站）；逐棒報告複本要不要也從 docs/features/ 拿掉、只留 Agent repo 正本，請裁。