本卡屬 FR-177(母卡 CM-3507),第 5 棒 A5:簽章驗證核心、啟動完整性閘、漏洞庫同步(Agent repo,6 檔/約 946 行)。只掃不修。工作坊會用
.claude/workshop-prompts/dispatch-<本卡號>.md當開場 prompt 直接啟動掃描,小弟不必自己打指令。
用 Claude Code 官方 claude-security plugin 掃 Guidant AI Agent(裝在客戶機器上的那支程式,repo evidence-agent)的「簽章驗證核心、啟動完整性閘、漏洞庫同步」這一塊,找出資安問題並寫成 PM 與新手工程師都看得懂的報告。只找問題、不修問題,修是另外開卡的事。
Agent 怎麼確認「這份東西是原廠簽的」:Ed25519 信封驗章(更新清單、漏洞庫清單都靠它)、Agent 啟動時檢查自己的程式有沒有被改過(startup gate)、以及漏洞庫怎麼下載解壓。
common/integrity/verify.py 是整個 Agent 信任鏈的根:A3 更新包、本棒漏洞庫、啟動閘都靠它。這裡錯一行,前面所有驗章都是裝飾。FR-084 掃過主系統側的 jedi-integrity(T1-2 驗章器掉包 PoC 成立),Agent 這份是獨立實作(vulndb_bundle.py:4 註明不依賴主系統套件),兩邊規則要一致。
guidant_agent/sync/app/vulndb_sync.py
guidant_agent/sync/app/vulndb_bundle.py
common/integrity
檔數 6、約 946 行。驗檔數:cd <工作目錄> && git ls-files -- guidant_agent/sync/app/vulndb_sync.py guidant_agent/sync/app/vulndb_bundle.py common/integrity | grep '\.py$' | wc -l 應為 6。scope 外的檔不要讀(研究員會越界,越界的發現首腦驗收時會挑掉)。
首腦讀過程式碼後認為最容易出事的地方,是思考起點不是檢查清單。工具不會照這份走,掃完後 runner 要自己逐條對一遍:工具沒報的,開檔看一眼寫「人工查過:成立/不成立/為什麼」。前幾輪最嚴重的發現(FR-076 L2 的 HIGH)都是 runner 照這清單追出來的,不是工具報的。
verify.py:61-81 _lookup_public_key:公鑰除了編譯進 binary 的 PUBLIC_KEYS,:81 還會從檔案 load_pem_public_key——哪個目錄、誰能寫?能放一把自己的公鑰進去就能簽任何東西。對照 FR-076 L1「三環境硬編公鑰」與 FR-084 T1-2。verify.py:114-152 verify_payload:alg 欄位是信封自帶的——有沒有限定只能是 Ed25519;canonical 怎麼序列化(JSON key 排序、浮點、Unicode),簽章前後兩邊算法一致嗎;expected_type 不符時是拒絕還是警告。startup_gate.py:105 環境變數 _ENV_FORCE 與 :55-58 的覆寫路徑:測試用的「指向 /tmp 假產物」覆寫在正式包裡關掉了沒;:24 寫「刪掉 manifest 是最便宜的繞法,不擋等於整道 gate 不存在」——實際有擋嗎。gate 失敗是拒啟還是記 log 繼續。vulndb_bundle.py:79-94 _extract_stream 自己寫的 tar 解壓(沒用 archive_safety):member 路徑有沒有擋 ../絕對路徑/symlink;member.size 與實際寫入量對不對(tar 標頭可以說謊)。vulndb_bundle.py:135-172:先驗 manifest 簽章、再逐檔對 sha256——manifest 裡沒列到的多餘檔案會不會也落地;staging 目錄換正式目錄是不是原子的。vulndb_sync.py:從哪下載、多久拉一次、版本倒退要不要擋;下載失敗時會不會把舊庫刪了(可用性)。public_keys.py:幾把、對應哪些環境(dev/stg/prod);dev 鑰有沒有跟著正式包出貨。FR-084 T1/T1b(主系統 jedi-integrity):驗章器掉包 PoC 成立(HIGH,決策者裁不開卡登記總表第 13~18 項)。FR-076 L1:三環境硬編公鑰並列。皆未經本棒面板驗證、只是參照。本範圍 Agent 側從未掃過。