本卡屬 FR-186（Agent 本體資安掃描第二輪），第 1 批 S5：線上更新鏈（Agent repo，4 檔／約 1014 行）。只掃不修。工作坊用 .claude/workshop-prompts/dispatch-<本卡號>.md 當開場 prompt 直接啟動掃描。

這一棒在做什麼（白話）

用 Claude Code 官方 claude-security plugin 掃 Guidant AI Agent（repo evidence-agent）的「線上更新鏈」，找出資安問題，寫成 PM 與新手工程師都看得懂的報告。只找問題、不修問題。

為什麼切這一塊

FR-177 掃過（舊卡 CM-3510），之後有改動；這次重掃要回答兩件事：上次修的有沒有守住、新改的程式有沒有新洞。 範圍按業務模組垂直切（入口→流程→資料），權限漏洞常在層與層的接縫上。

掃描範圍（scope，與開場 prompt 的 --scope 一致）

guidant_agent/sync/app/update_sync.py
guidant_agent/sync/app/update_events.py
guidant_agent/sync/app/update_log_upload.py
guidant_agent/console/api/update_routes.py

檔數 4、約 1014 行。驗檔數：git ls-files -- guidant_agent/sync/app/update_sync.py guidant_agent/sync/app/update_events.py guidant_agent/sync/app/update_log_upload.py guidant_agent/console/api/update_routes.py | grep -v /tests/ | wc -l 應為 4。scope 外的檔不要當發現報；為核對呼叫端翻範圍外的檔可以，報告標「只為查證」。

重點看什麼

首腦標的思考起點，不是檢查清單。掃完後 runner 逐條對一遍：工具沒報的，開檔看一眼寫「人工查過：成立／不成立／為什麼」。FR-177 的人工補查抓到的問題不比工具少。（以下沿用 FR-177 舊卡的重點，行號是舊版、以檔名與函式名為準。）

• update_sync.py:121-129 解更新命令：target_version、bundle_sha256、size 來自主系統——但主系統送來的 sha256 本身有沒有經過簽章？若命令只靠 8443 的 JWT 保護，拿到 JWT 的人就能指定任意 sha 配任意包。對照 A5 的 verify_payload（Ed25519 信封）有沒有用在這裡。
• update_sync.py:234 下載完驗 size 與 sha256 的時機：是驗完才改名成正式檔，還是先落正式檔名再驗（中間那段時間主機腳本會不會撿走）。.part 續傳時 Range 拼接後有沒有重新整檔驗。
• update_sync.py:137 allow_same_version() 與 :174-178 降級判定：能不能更新到比現在舊的版本（降級攻擊：把有洞的舊版裝回去）。compatible／requires_host 誰驗。
• 更新包從哪下載：網址是命令裡給的還是設定裡釘死的；是不是只准 https；下載用的 client 走 cloud_tls_verify 嗎。
• Agent 把驗過的包放在哪、主機端腳本怎麼知道要安裝（order 檔 :218-226 0644）——主機與容器的交界：容器內能寫的目錄，主機腳本會以 root 跑裡面的東西嗎？order 檔被改 bundle 欄位指到別的檔會怎樣。
• update_routes.py＋update_console.py：主控台觸發更新要什麼 scope；能不能指定版本與 sha（若能，等於繞過主系統的簽發）。update_log_upload.py 上傳的 log 會不會帶出主機敏感資訊。
• update_events.py：回報結果的事件有沒有可能被偽造成「已更新成功」讓主系統停止重試。

已知背景

FR-177 25 棒報告在 Agent repo docs/security-scan/FR-177/scan-*.md，已登記的 22 條在主系統 repo docs/features/security-scan-consolidated/README.md §3.1 第 219～240 項（全部已修）。已修而且修法成立的不重報；修法不完整、或同一族換個欄位又出現，才報並註明對應項次。

怎麼做