FR-187.H 掃主系統「出版管線與發布簽章」（10 檔／1055 行，Opus 1M effort low，只掃不修）

本卡屬 FR-187（母卡 CM-3711），第 4 批 H：出版管線與發布簽章（主系統 repo compliance-manager-be，10 檔／約 1055 行）。只掃不修。工作坊會用 .claude/workshop-prompts/dispatch-<本卡號>.md 當開場 prompt 直接啟動掃描，小弟不必自己打指令。

這一棒在做什麼（白話）

用 Claude Code 官方 claude-security plugin 掃「出版管線與發布簽章」這一塊，找出資安問題，寫成 PM 與新手工程師都看得懂的報告。只找問題、不修問題，修是另外開卡的事。

FR-173 把 CI 拆成五支，正式發版由 Vault（集中保管密碼與簽章鑰匙的伺服器）簽章，再推到 Harbor（映像倉庫）與原廠更新站。這一棒看 CI 定義與幾支碰到祕密的腳本：誰能觸發正式發版、祕密怎麼拿、會不會被印出來、簽的是什麼。

為什麼切這一塊

簽章鑰匙是客戶機器信任新版的唯一依據。任何一條路讓非正式分支拿到簽章權限、或讓別人改過的腳本在拿到祕密之後執行，就等於能對全部客戶發布惡意更新。

背景：這一輪掃的是 2026-11-01（FR-172 開案）到 11-09 之間主專案與 jedi-remote-agent 新寫或大改的程式（FR-171／172／178／179／180／181／182），這些程式都沒掃過。

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

.gitlab/ci/common.yml
.gitlab/ci/deploy.yml
.gitlab/ci/release.yml
.gitlab/ci/test-release.yml
.gitlab/ci/vulndb.yml
.gitlab-ci.yml
scripts/build/sign_release.sh
scripts/build/vault_login.sh
scripts/build/harbor_auth.sh
scripts/build/publish_draft.sh

檔數 10、約 1055 行。驗檔數：git -C <工作目錄> ls-files -- .gitlab/ci/common.yml .gitlab/ci/deploy.yml .gitlab/ci/release.yml .gitlab/ci/test-release.yml .gitlab/ci/vulndb.yml .gitlab-ci.yml scripts/build/sign_release.sh scripts/build/vault_login.sh scripts/build/harbor_auth.sh scripts/build/publish_draft.sh | wc -l 應為 10。scope 外的檔不要讀，除非下面「重點看什麼」明寫「只追這幾行」；越界的發現首腦驗收時會挑掉。

重點看什麼

首腦讀過程式碼後認為最容易出事的地方，是思考起點不是檢查清單，行號以 2026-11-09 的主線為準，對不上就以內容為準。工具不會照這份走，掃完後你要自己逐條對一遍：工具沒報的，開檔看一眼，寫「人工查過：成立／不成立／為什麼」。

release.yml:28-45 正式發版只認受保護的 v* tag；deploy.yml、test-release.yml 的 rules——有沒有路徑讓一般分支的 job 拿到 release-ci 這個 Vault 角色（Vault 那頭的綁定條件不在 repo，只判斷 repo 這邊的 id_tokens 與 rules）。
vault_login.sh：拿到的 kv 值 export 給子指令；有沒有 set -x、錯誤訊息把值印出來；收尾有沒有 revoke-self；VAULT_ADDR 是 https 內網 IP、靠系統信任 CA。
sign_release.sh：簽的是哪一份 json，簽之前有沒有確認那份是這次 build 產的。
release.yml:192-200 刻意從 git archive $CI_COMMIT_SHA 取腳本（避免被前面的 job 改掉）——其他拿祕密的 job 有沒有直接執行工作區裡可能被改過的腳本。
188 是 shell runner、job 之間共用目錄：一般分支的 deploy job 留下的檔，會不會被下一個正式發版 job 拿去用。
harbor_auth.sh 用 --password-stdin（對）；publish_draft.sh 發布用的 token 怎麼傳、有沒有進命令列。

已知背景

FR-077（2026-09）掃過 jedi-remote-agent 與主系統接線的舊版，FR-086 掃過檔案上傳下載，FR-177（2026-11-05～07）掃過 Agent 本體；結論在主系統 repo docs/features/security-scan-consolidated/README.md，只是參照，沒有經過本棒的三人投票。