本卡屬 FR-177(母卡 CM-3507),第 3 棒 A3:線上更新鏈(FR-172 新程式)(Agent repo,5 檔/約 1235 行)。只掃不修。工作坊會用
.claude/workshop-prompts/dispatch-<本卡號>.md當開場 prompt 直接啟動掃描,小弟不必自己打指令。
用 Claude Code 官方 claude-security plugin 掃 Guidant AI Agent(裝在客戶機器上的那支程式,repo evidence-agent)的「線上更新鏈(FR-172 新程式)」這一塊,找出資安問題並寫成 PM 與新手工程師都看得懂的報告。只找問題、不修問題,修是另外開卡的事。
Agent 收到「更新到某版」的命令後,怎麼下載更新包、怎麼確認包沒被換過、怎麼交給主機端腳本安裝、安裝結果怎麼回報;主控台那頁發動更新的路徑。
這是 FR-172 一個月內剛寫的新程式,沒有任何一輪掃過。更新鏈是最高價值的攻擊面:騙過它等於在客戶所有 Agent 上執行任意程式。而且更新包是 tar.gz,解壓與安裝都在主機層跑。
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/app/update_console.py
guidant_agent/console/api/update_routes.py
檔數 5、約 1235 行。驗檔數:cd <工作目錄> && 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/app/update_console.py guidant_agent/console/api/update_routes.py | grep '\.py$' | wc -l 應為 5。scope 外的檔不要讀(研究員會越界,越界的發現首腦驗收時會挑掉)。
首腦讀過程式碼後認為最容易出事的地方,是思考起點不是檢查清單。工具不會照這份走,掃完後 runner 要自己逐條對一遍:工具沒報的,開檔看一眼寫「人工查過:成立/不成立/為什麼」。前幾輪最嚴重的發現(FR-076 L2 的 HIGH)都是 runner 照這清單追出來的,不是工具報的。
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 誰驗。cloud_tls_verify 嗎。:218-226 0644)——主機與容器的交界:容器內能寫的目錄,主機腳本會以 root 跑裡面的東西嗎?order 檔被改 bundle 欄位指到別的檔會怎樣。update_routes.py+update_console.py:主控台觸發更新要什麼 scope;能不能指定版本與 sha(若能,等於繞過主系統的簽發)。update_log_upload.py 上傳的 log 會不會帶出主機敏感資訊。update_events.py:回報結果的事件有沒有可能被偽造成「已更新成功」讓主系統停止重試。本範圍從未掃過。FR-167/172 設計文件在主系統 repo docs/features/FR-172-2611-agent-independent-update/,研究員不必讀,runner 核 HIGH 時可查對設計意圖。