Guidant AI 資安檢視 · 模組報告
裝在客戶機房、代替我們去執行檢測工作的程式。全案唯一一件「最嚴重」等級的問題在這裡——而且它是整份報告中唯一一件不需要任何帳號就能得手的。這一條已修好、隨 1.21.0 出貨；本塊另外兩條中風險（第 2、3 條）與範圍外的第 4 條仍未修，目前沒有修正卡。
客戶要做資安檢測，得有東西去實際連上他們自己機房裡的主機——跑掃描工具、抓設定檔、取回檢測結果。但那些主機在客戶內網，我們的雲端碰不到。
所以我們發一支代理程式給客戶，裝在他們機房裡。它像一個派駐在客戶端的員工：
為了做事，它手上握有客戶主機的帳號密碼——遠端登入用的、Windows 管理用的、掃描工具的權杖。
這點是理解後面問題的關鍵。
檢視期間：2026-09-07 ～ 2026-09-17｜範圍：99 個檔案（模組本體 72、接線 16、借用的檢測模組 11）｜共 5 輪
原始技術報告放在需求中心的 FR-077 站，檔名見下表最後一欄。那裡有每一輪的完整技術細節、檔案清單與逐條推理，供需要深究或稽核抽查時查閱。
| 輪次 | 查什麼 | 檔數 | 覆核投票 | 結果 | 原始報告檔名 |
|---|---|---|---|---|---|
| R1 | 代理程式的身分與註冊——它怎麼證明「我是誰」 | 42 | 覆核未完整跑成（見下方說明） | 通過 7 條，開出 4 張修正工單 | scan-R1-agent-identity |
| R1b | 加密與簽章核心——簽憑證、簽通行證、連線加密 | 10 | 15 票全投完 | 通過 2 條，範圍內零新問題 | scan-R1b-crypto-core |
| R2a | 工作怎麼派下去、狀態怎麼流轉 | 30 | 15 票全投完，五條全部三票一致 | 通過 5 條，範圍內零新問題 | scan-R2a-task-dispatch |
| R2b | 代理程式來拿檔案、雲端連回代理程式 | 13 | 15 票全投完 | 通過 4 條，範圍內零新問題 | scan-R2b-file-access |
| R3 | 我們主系統這端怎麼把它接上來 | 16 | 21 票全投完 | 通過 6 條，範圍內零新問題 | scan-R3-host-wiring |
後面四輪「範圍內零新問題」不是白跑——那是好消息
四輪從四個不同角度切進去，都撞到同一個結論。這代表問題不是散落各處，是集中在同一件事上，而且那件事被反覆驗證了四遍。
五輪一共通過 24 條發現，去重之後：22 條反覆指向同一件事，2 條是檢視範圍外順手撈到的密碼外洩。
第一輪（R1）的覆核沒有完整跑成，這裡要說清楚
那一輪放了 42 個檔案，超過負荷——負責覆核的程序全部超過用量上限被中斷，票沒投出來。所以那一輪的結論是靠人工逐條開檔核對的，不是靠自動覆核。
我們沒有因此重跑，而是改用更小的範圍分四輪再查一遍（就是 R1b／R2a／R2b／R3）。那四輪的覆核都完整跑完，而且都指向同一個結論——等於用四輪完整的覆核，補回了第一輪缺的那一次。
這也是「每輪不超過 15 個檔案」這條規矩的由來，詳見檢視方法與工具。
這一頁在 2026-09-20 做過一次人工複查，推翻了幾條原本的寫法
檢視工具產出的原始報告寫好之後，我們回到程式碼、版本紀錄與實機上逐條核對。結果有四條描述必須更正，另外查出一條工具完全沒抓到的問題（撤銷只擋住一半）。
會更正的部分都在下面各條裡直接寫明「原本怎麼寫、實際是什麼」。保留這些更正痕跡是刻意的——稽核方要看得出我們核對過，而不是照單全收。
排序按風險，同風險的同一類排在一起。「出事會怎樣」那欄講的是業務影響——誰受影響、損失什麼，不是技術現象。
讀這張表之前要先知道一件事：產品還沒有出貨給任何真實客戶。
下面每一條講的「客戶會怎樣」，都是產品上線之後會發生的事，不是已經發生過的事。目前系統裡的資料全部是我們自己的測試資料。
這不會讓任何一條變得比較不嚴重——問題都是真的，只是還沒有人受害。這一輪檢視正是為了在出貨前把它們處理掉。
（一個例外：表裡凡是講「我們自己的文件網站／程式碼倉庫／測試機」的條目，與產品出不出貨無關——那些曝光是真的發生過的，已在各條裡標明。）
| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
|---|---|---|---|---|---|---|
| 1 | 五條通訊管道全部不檢查對方是誰 | 🔴 最嚴重 | 身分驗證缺失 | 客戶會失去對自己機房主機的控制權——取走的是客戶自己的伺服器帳密，不只是我們系統的資料。且可冒充任一家客戶，一家出事等於全部客戶暴露；稽核證據可被偽造或抹除，整份稽核報告的可信度會被質疑 | 呼叫者身分改由簽章證明，五條管道一起修，歸屬比對做進核心層；同一批順便補上「這台是不是已被撤銷」 | ✅ 已修（CM-2052） |
| 2 | 有一個入口會照著送進來的網址去打，不檢查那是不是自己人 | 🟡 中 | 身分驗證缺失 | 我們的系統可被當成探測客戶內網的跳板——藉它試出客戶內網有哪些機器、哪些連得上。客戶的防火牆擋不住，因為流量是從他們自己信任的代理程式那一側發出的。但要先有一個管理員帳號，所以這是內部人越權，不是外人；而且只摸得到「機器在不在」，摸不到內容 | 那個入口改成只收代理程式編號，網址由後端自己查，不接受外部送網址 | ⬜ 未修（原工單 CM-1596 已隨 09-21 統一派工作廢，目前沒有修正卡，待決策者裁定是否排入） |
| 3 | 裝機啟用碼不會過期、也不限次數 | 🟡 中 | 憑證管理 | 外流的安裝文件或離職員工手上那組碼，永久有效——整家客戶共用同一組，撿到的人隨時能登記一台自己的代理程式進來。第 1 條已修好之後，報到成了冒充代理程式唯一的入口，這組碼就是那道門的鑰匙——所以它看不看得見、有沒有被濫用，現在是真正有意義的問題 | 已拍板：碼本身維持現狀，改成看得見——管理頁面顯示這組碼發出多久、用過幾次、上次何時被使用，見下方 | ⬜ 未修（原工單 CM-1597 已隨 09-21 統一派工作廢，目前沒有修正卡，待決策者裁定是否排入；修法已定） |
這三條跟遠端代理程式沒有關係——是工具在檢視時順手做了一次密碼掃描撈到的，掃描範圍涵蓋整個套件庫與文件站。列在這裡是為了完整，詳細歸在它們各自所屬的地方。
| # | 問題 | 風險 | 分類 | 出事會怎樣（誰受影響） | 怎麼修 | 狀態 |
|---|---|---|---|---|---|---|
| 4 | 共用基礎模組的一支設定檔（含一組資料庫帳密）被存進版本控制 | ⚪ 低 | 密碼外流 | 接觸過程式碼的人（含離職者、外包）都看得到那組帳密。但實際可用性很低——那組帳密的主機值是「本機」，拿到的人只能拿它去連自己的電腦 | 從版本控制移除；確認沒有人在別處用同一組密碼 | ⬜ 未修（原工單 CM-1598 已隨 09-21 統一派工作廢，目前沒有修正卡，待決策者裁定是否排入） |
| 5 | 需求文件裡的資料庫超管密碼，曾自動發佈到公開網站 | 🟠 高 | 密碼外流 | 在擋住之前，網際網路上任何人開網址就看得到（統籌者親自開網址確認過）。那組帳號可繞過所有客戶隔離、讀寫每一家的資料 | 已擋住公開存取；密碼已裁定不換（只有測試機在用）；並在出貨流程加密碼檢查 | ✅ 已處理（文件站已擋住公開存取、須先通過身分驗證；文件裡的密碼已全部改成指路文字，文件站建置時會自動擋下密碼字串（CM-2207）；三組帳密決策者裁定屬測試用、不換） |
| 6 | 舊版程式裡一把外部服務權杖從未撤銷 | 🟡 中 | 密碼外流 | 可用我們公司帳號的身分，讀寫外部平台上的專案與問題單。拿得到程式庫歷史或舊版套件檔的人，一行指令就撈得出來 | 到該服務後台撤銷 | ✅ 已處置（該權杖已撤銷，2026-09-20 確認） |
這是整份報告唯一一件「最嚴重」等級的問題。
其他所有問題至少都要「先有一個有效帳號」。這一件不用。
代理程式跟雲端之間有五條通訊管道。五條都不問「你是誰」。
程式碼裡有一行註解寫著「這裡不用檢查，因為外層的網頁伺服器會確認對方的身分憑證」。但那道確認從來就沒有做出來過。
這裡要更正原本的寫法
原始報告寫的是「設定檔裡少了那一行」，會讓人以為是一時漏填、補上就好。實際更根本：
真正發生的事：寫程式的人假設「基礎設施那層會把關」，架基礎設施的人不知道有這個要求。中間那道門，沒有人蓋。
註解不會被執行，所以它永遠不會報錯。沒有任何機制會去檢查「註解裡寫的那個假設，到底有沒有成真」。
而且那段註解現在已經過期了：它提到的那個把關元件，在 2026-08-20 就整個退役了（代理程式外層的網頁伺服器被拿掉，相關邏輯收回代理程式自己承接）。註解卻還留在原地，一共四處。
這不是資安漏洞本身，但它是漏洞能長期存在的原因——下一個接手的工程師會照著這句話判斷「已經有人在把關了」，跟這次一樣。修的時候要一併改掉。
| 管道 | 它原本的用途 | 打進去能拿到 |
|---|---|---|
| 報到 | 代理程式第一次安裝時登記 | 一張身分憑證 |
| 領工作 | 定期回來問「有工作嗎」 | 🔴 整套稽核用的高權限通行鑰匙（見下） |
| 確認收到 | 回報「我收到這份工作了」 | 搶走別台機器的工作 |
| 回報結果 | 回報「我做完了」 | 🔴 偽造或抹掉稽核證據 |
| 下載檔案 | 來拿要掃描的源碼 | 🔴 客戶上傳來掃描的源碼 |
「客戶自己機器的密碼」這句話講得太輕了——實際上不只是一組密碼
代理程式回來領工作時，雲端會把這家客戶全部七套檢測工具的連線設定一併送過去。那裡面裝的是：
| 拿到什麼 | 能做什麼 |
|---|---|
| Linux 主機的私鑰檔 | 免密碼直接登入被稽核的主機 |
| Windows 的網域帳號 | 不是單一一台機器，是整個網域都認的帳號 |
| 掃描工具的存取金鑰 | 讀得到客戶交上來的原始碼、弱點掃描主機的管理權限、受測網站的登入身分 |
| 內部網路位址 | 連帶送出一份客戶的內網地圖 |
三件事讓它比「一組密碼」嚴重得多：
這些是稽核用的高權限帳號，能登入被稽核的每一台主機。
系統怎麼決定「這次動作算在哪一家客戶頭上」？
它拿請求自己送上來的編號去查，查到是誰就切換成誰。
可以用來冒充的編號有三種，全部由對方自己填：
| 編號 | 從哪裡取得 |
|---|---|
| 代理程式編號 | 任何登入的人在管理頁面上就看得到 |
| 機器編號 | 同一份範本複製出來的機器，這個值一模一樣 |
| 工作編號 | 那個不檢查身分的「領工作」管道，回應裡就會送給你 |
三種都要堵，只堵一種等於沒堵。
這一條是 2026-09-20 人工複查時查出來的，原始報告與跨模組總表都沒有。
它沒有另開工單——併進第 1 條一起修，因為是同一套修法、同一層要補的東西。已隨第 1 條修好（CM-2052，1.21.0 出貨）：現在每一次請求都會查這台代理程式是否已撤銷、已停用。
管理頁面上有一顆「撤銷」，管理員按下去之後那台代理程式會標成紅色的「已撤銷」。但實際上只斷了一條管道。
| 管道 | 撤銷後還進得來嗎 |
|---|---|
| 領工作 | ❌ 擋住了（有檢查「這台是不是已撤銷」） |
| 確認收到 | ✅ 照樣進得來（完全沒有檢查） |
| 回報結果 | ✅ 照樣進得來（完全沒有檢查） |
所以被撤銷的那台機器，仍然可以：
為什麼這比「根本沒有這顆按鈕」更糟
管理員按下撤銷、看到紅色標籤，會合理認為「這台已經斷了」。實際上它還能偽造稽核證據。
沒有那顆按鈕，反而比有一顆只做一半的按鈕安全——前者不會讓人誤以為問題已經解決。
程式裡的註解寫撤銷之後「雲端所有資料面呼叫即拒」。這句只對了一半——它講的是「我們打去代理程式」那個方向；「代理程式打進來」這個方向只有領工作那一條補了檢查。
這與第 1 條是同一個模式：想到了，只做了一部分就停了。
這是五輪檢視陸續補上的，每一個都讓影響再擴大一層：
系統有個「授權過期就轉成唯讀」的保護機制，但它的白名單直接放行了整個代理程式的路徑。授權過期的環境不會因此變安全。
回報結果時可以附一個檔案編號，雲端會照著去把檔案抓回來、存成這次檢測的稽核證據。等於可以把自己準備的任何檔案，塞進客戶的稽核案卷。
等於免費奉送冒充用的第二把鑰匙。
整家客戶共用同一組、不會過期。（這一條同時是上表第 3 條。）
| 判斷依據 | 這件事 |
|---|---|
| 要先有帳號嗎 | 不用，完全不需要登入 |
| 拿得到什麼 | 客戶主機的高權限登入鑰匙（整套，不是一組密碼） |
| 只影響一家客戶嗎 | 不是，可以冒充任何一家 |
| 能破壞稽核可信度嗎 | 能，可以偽造、抹除、塞入假證據 |
四項全中。
而且拿走的不是某一台機器的密碼，是客戶為了配合稽核而開給我們的高權限通行鑰匙。客戶把鑰匙交給我們，是因為信任我們保管得住——這條要是被人用上了，失去的不只是資料，是這份信任本身。
這件事會直接影響「該不該現在修」的判斷，所以要寫出來。
原始報告只講了缺什麼，沒講已經有什麼。我們登入唯一一台有真代理程式在跑的機器（我們自己的測試機——產品尚未出貨，客戶端一台都還沒有），把它手上的憑證撈出來看：
| 查到什麼 | 內容 |
|---|---|
| 憑證齊不齊 | 三件套都在——自己的憑證、私鑰、以及用來驗對方的根憑證 |
| 誰簽的 | 我們自己的簽發中心（Guidant Agent CA） |
| 有效期 | 2026-09-03 ～ 2036-08-31（十年） |
| 代理程式那端的設定 | 已經設成「完整驗證」模式——客戶端那一半早就準備好了 |
這代表什麼：
這是兩個不同的問題，雙向驗證只解得了一半。
| 問題 | 雙向憑證驗證解得了嗎 |
|---|---|
| 你是不是一台合法的代理程式 | ✅ 解得了 |
| 你是哪一台、這份工作是你的嗎 | ❌ 解不了 |
它只確認「這條連線的另一端，手上有一張我們認可的憑證」。它不會去比對「憑證上的名字，跟這個請求裡自己填的編號，是不是同一個」。
所以補完之後還剩下這個：A 客戶的代理程式（憑證合法、驗證通過），在請求裡填上 B 客戶的代理程式編號，系統照樣切換成 B、把 B 客戶主機的帳號密碼交給它。
攻擊面從「網際網路上任何人」縮小到「任何一個有代理程式的客戶」，但跨客戶偷資料仍然成立。而落地版客戶的代理程式就裝在他們自己機房、憑證檔案在他們自己的硬碟上——所以「客戶之間互相冒充」不是理論風險。
一個比喻：雙向憑證驗證是大門，不是房門鎖。只裝大門不裝房門鎖，結果是外人進不來了，但任何一個住戶可以進任何一間房。
現況：已修好（CM-2052，1.21.0 出貨）
實際採用的身分證明是雲端在代理程式報到時另發一張控制面通行證（用平台既有的簽章金鑰簽，效期與代理程式憑證一致），代理程式之後每一條出站請求都帶著它；雲端每次驗簽、只認通行證裡的代理程式編號當身分（不再讀請求自報的編號），並且每次請求都查資料庫確認這台沒被撤銷或停用——撤銷靠資料庫，通行證本身不必撤。不動資料表結構、不動客戶機房的設定。
這和下面分析時建議的「短效通行證」方向相同（由產品自己簽、自己驗，不碰客戶的基礎設施），差別在效期：代理程式在客戶機房的時鐘可能偏差很大，短效票會讓整批代理程式因時間對不上而全部失效，所以改成與憑證同效期、靠每次查資料庫來撤銷。下面保留的是當時的分析與取捨。
第一步要決策者拍板：用哪一種身分證明
兩條路，選一條當主軸、另一條最多當輔助：
| 方案 | 怎麼運作 | 優點 | 代價 |
|---|---|---|---|
| 短效通行證 （建議） |
平台本來就會簽發這種通行證，讓代理程式每次呼叫都帶上 | 產品本身就有這個機制，不必動客戶的基礎設施；我們自己驗得了，客戶怎麼架都不受影響 | 要處理通行證的發放與更新 |
| 客戶端憑證 | 由最外層的網頁伺服器確認對方憑證，驗過的身分往後傳 | 連線層就擋掉；而且憑證早就備齊，接上的成本比原先估的低 | 要改客戶機房的設定，落地版客戶各自裝機、改動成本高；而且它只解一半——證明「你是一台登記過的機器」，不證明「這張工單是你的」 |
建議走短效通行證——不用碰客戶端的設備。客戶端憑證可以之後再補，但不能拿它當唯一手段。
後續四步：
| 步驟 | 做什麼 | 為什麼不能省 |
|---|---|---|
| 二 | 五條管道一起掛上驗證，身分從驗過的通行證推出來，不再讀請求裡自報的編號 | 只修其中幾條，剩下的還是門戶洞開 |
| 三 | 「這張工單是不是你的」做成核心層的必要條件 | 只在最外層加一道檢查，日後多一條呼叫路徑（批次補登、維運工具、修復腳本）就會再繞過一次 |
| 四 | 同一層順便補上「這台是不是已被撤銷」 | 檢視當時三條管道只有一條有查，撤銷等於只做了一半。既然要動這一層，一起補的邊際成本接近零 |
| 五 | 最外層補上客戶端憑證確認 | 只是連帶，不能取代第三步 |
上面五步做完，不是「從此安全」，也不是「做了也沒用」。擋得到的和擋不到的，要先講清楚，免得事後有落差。
| 誰 | 修完後 |
|---|---|
| 網路上的外人 | ✅ 擋掉 |
| A 客戶冒充 B 客戶 | ✅ 擋掉 |
| 被按過「撤銷」的那台機器 | ✅ 擋掉——第四步已一併補上，每次請求都查撤銷狀態（CM-2052） |
| 客戶機房裡那台機器本身 | ❌ 照樣拿得到——這是設計本身，不是缺陷 |
最後一列要特別說明：那不是沒修好，是本來就該這樣
代理程式要去登入客戶的主機做掃描，就一定得拿到那些登入鑰匙——不給它，它什麼事都做不了。所以這些鑰匙送到代理程式手上，是這套設計的必要前提。
補完之後的差別在於：從「網路上任何人打得到就拿得到」，變成「只有真的那台代理程式拿得到」——而那正是設計原本想要的樣子。
但那台代理程式就裝在客戶自己的機房裡。能實際碰到那台機器的人，仍然撈得出裡面的東西。
所以結論是：補完之後，風險範圍從「網路上任何人」縮小到「能實際碰到那台機器的人」。後者客戶本來就承擔著——那些鑰匙是客戶自己提供給我們的，也存在他們自己的機房裡。前者才是我們必須負責關掉的那一半。
這裡要更正原本的寫法
原始報告寫的是「產品有個測試連線功能，讓管理員確認能不能連上某台主機，但它沒有限制可以連去哪裡」——這會讓人以為畫面上有個表單讓管理員自己填網址。實際查前端，沒有那個表單。
畫面上是「遠端代理程式管理」清單裡的一欄，標題叫「健康檢查」，顯示上線／離線。頁面一載入就自動對清單上每一台探測一次（旁邊另有一顆重新探測的按鈕）。網址一律是從資料庫讀出來的，所以照畫面正常使用完全安全。
問題不在畫面，在後端那個入口本身：它收到什麼網址就打什麼，不檢查那是不是自己人的機器。
不必透過我們的畫面——用工具直接對那個入口送一個自訂網址，它照樣會打過去。
「畫面上不能填」不構成防護
前端跑在使用者自己的瀏覽器裡。任何人打開瀏覽器的開發工具，就看得到我們的畫面送了什麼請求；複製下來改掉網址重送即可。
前端擋不住任何東西。真正的守門一定要在後端。
這是它與第 1 條最關鍵的差別，必須講清楚，否則讀者會以為兩條一樣嚴重。
| 第 1 條 | 第 2 條 | |
|---|---|---|
| 要先有帳號嗎 | 不用 | 要——而且要登入、有授權、有管理能力，三關都過 |
| 拿得到什麼 | 客戶主機的明文帳密 | 只有「那台機器在不在、連不連得上」，拿不到內容 |
| 誰會是那個人 | 網際網路上任何人 | 有管理員帳號的內部人或外包 |
所以這是「內部人越權」，不是「外人闖入」。 這也是它從原本的「高」調整為「中」的理由（與工單 CM-1596 的評級一致）。
決策者已拍板：不是「檢查網址」，是「不收網址」。
原本的修法寫的是「限制可連線的目標範圍，只允許連向已登記的檢測目標」。改成更徹底的做法：
那個入口改成只收代理程式編號，網址由後端自己從資料庫查出來。完全不接受外部送網址。
| 為什麼比「檢查網址」好 | |
|---|---|
| 檢查有可能寫漏寫錯 | 網址的寫法變化很多，只要比對規則有一點沒想到就會被繞過（例如只比對開頭，https://好的網址@壞的網址 這種寫法就過了） |
| 不收就沒得騙 | 這是消除選擇，不是增加檢查。沒有可以被寫錯的比對規則，就沒有可以被繞過的比對規則 |
更深一層的理由：現在的形狀是「前端送什麼、後端打什麼」，等於「決定要打去哪」這個權力落在前端手上。而前端跑在使用者的瀏覽器裡——等於落在任何一個會用開發工具的人手上。改成收編號之後，這個決定權整個收回後端。
施工牽動：前端要跟著改成送編號，是前後端一起動的小工程。開工前要先確認沒有別的地方在用這個入口。
這裡要更正原本的寫法
原始報告把它寫成「報到用的通行碼」，容易讓人以為它是一組長期有效的存取金鑰（像某些平台給的個人金鑰那樣）。它不是。它是「裝機啟用碼」，只在安裝當下用一次。
完整的生命週期是：
| 步驟 | 發生什麼 |
|---|---|
| 1 | 裝機時把啟用碼填進去 |
| 2 | 代理程式拿它去報到——這一步只發生一次 |
| 3 | 雲端當場簽發一張身分憑證給它 |
| 4 | 之後一律用憑證，啟用碼再也不會出現 |
實查代理程式後續每次報到送出的內容，確實完全沒有帶啟用碼——只帶自己的編號、機器編號、狀態、版本與能力。
所以它是入場券，憑證才是員工證。啟用碼外流，不影響已經裝好的代理程式。
四條進得來的管道裡，只有「報到」這一條在檢查東西（檢查啟用碼）。
而報到，正是攻擊者唯一不需要走的那一條——因為第 1 條讓他可以直接打「領工作」。
這解釋了為什麼這條在檢視當時看起來怪：防護做了，但做在唯一沒人經過的門上。第 1 條修好之後情況反過來了——其他管道都要先出示報到時拿到的通行證，報到成了唯一的入口，啟用碼就是那道門的鑰匙。這條的實際份量因此上升。
查版本紀錄與當初的設計文件（2026-06）：
| 當初要解決什麼 | 自動化裝機——把「管理員在網頁上一台一台手打代理程式網址」那一步拿掉，改成機器自己來登記，報到時當場簽發憑證 |
| 為什麼還需要這組碼 | 機器自己來登記，總得有東西告訴系統「它是哪一家客戶的」。這組碼真正承擔的是歸屬判定，不只是門票——所以不能直接拿掉 |
| 當初知不知道有上限 | 知道。 設計文件裡有一節標題就叫「安全上限（誠實）」，自己寫明：機器指紋是代理程式自己回報的，擋得住一般的憑證盜用，擋不住「完全控制那台機器又改掉程式來偽造指紋」 |
| 「不審核」是誰決定的 | 設計文件明寫「新設備自動登記不審核」——這是當時刻意的取捨 |
決策者 2026-09-20 拍板：碼本身不動，加上「看得見」。
定案內容：
為什麼這樣選：
| 理由 | 說明 |
|---|---|
| 保管責任在客戶身上 | 跟某些開發平台把個人金鑰交給使用者自己保管是同一個模式。決策者 2026-09-17 已就此推翻過「加期限」的建議，這次的判斷一致 |
| 加期限會卡住兩個真實情境 | 「碼發出去了但客戶還沒去裝機」、「一次要裝好幾台」——兩種都是正常用法，不該被擋 |
| 另外兩個方向會推翻當初的設計目標 | 後台審核與一機一碼都會把裝機流程變麻煩，而自動化裝機正是 2026-06 當初要解決的問題。選它們等於把當初解掉的麻煩再帶回來 |
考慮過但沒有選的兩個方向（留著，供日後回頭檢視）：
| 做法 | 好處 | 為什麼沒選 | |
|---|---|---|---|
| ② 後台審核 | 機器來登記後先進待審清單，管理員核准才發憑證 | 把「這台是不是我們家的」這個判斷，交回給看得到全局的人 | 等於推翻 2026-06「不審核」那個決定，把當初想解決的裝機麻煩帶回來 |
| ③ 一機一碼 | 管理員先在後台建一台，系統產生只屬於那一台的碼 | 碼外流只影響一台 | 一次要裝很多台時會非常煩 |
「2026-06 那個『不審核』的取捨，現在還成立嗎」——已答：維持成立。 自動化裝機的需求沒有改變，這次的拍板就是對這個問題的回答。
要提醒的一點：選①的代價是「要有人去看才有用」。顯示出來之後，還得有人定期去看那三個數字，否則等於沒做。這一點在排期時要一起想清楚由誰負責。
修法定了，但還沒有人做。
這條原本排在第 1 條之後，理由是第 1 條沒修之前攻擊者根本不必走報到這條路。第 1 條已修好（CM-2052），這個前提已經滿足——現在攻擊者想冒充代理程式，只剩拿到啟用碼去報到這一條路。原工單 CM-1597 已隨 09-21 統一派工作廢，目前沒有修正卡，待決策者裁定是否排入。
這裡要更正原本的寫法
原始報告寫「模組的設定檔（含密碼）被存進版本控制」，讀者會以為是遠端代理程式自己的設定檔。不是。
那是套件庫裡一支共用基礎模組的設定檔（jedi-common/.env），跟遠端代理程式沒有任何關係。它會出現在這一頁，純粹是因為檢視那一輪時工具順手做了一次密碼掃描，掃描範圍涵蓋整個套件庫。
所以它歸到上面的「檢視範圍外另外撈到」那張表，詳細歸屬於該模組。
| 查證項目 | 結果 |
|---|---|
| 什麼時候進去的 | 2025-04-16，建立那個套件時一起放進去的，之後沒有再改過 |
| 有程式在讀它嗎 | 沒有。 整個套件庫搜過，沒有任何程式載入這支檔——它不在任何執行路徑上 |
| 那組帳密能連到哪 | 主機值是「本機」。拿到的人只能拿它去連自己電腦上的資料庫 |
| 忽略清單有設嗎 | 有。 規則早就在了，只是這支檔在規則生效前就已經進去了 |
| 還有別的嗎 | 整個套件庫只有這一支，其他同類檔案都被規則擋掉了 |
所以建議由「中」降為「低」（與工單 CM-1598 的評級一致）。
| 步驟 | 做什麼 |
|---|---|
| 一 | 從版本控制移除這支檔 |
| 二 | 確認沒有人在別的地方用同一組密碼 |
不必做的兩件事，以及為什麼：
這支檔躺了一年半沒人發現，是這次的密碼掃描把它撈出來的。
真正的問題不是這支檔，是我們過去沒有在出貨流程裡自動檢查「有沒有密碼被上傳」。
這一點與第 5 條（發到公開網站的資料庫密碼）是同一個根因——兩次都是靠人工掃描才發現，而不是流程自動擋下來。
狀態：已處理。
先講清楚一件事：這一條與「產品有沒有出貨」完全無關。曝光的是我們自己的文件網站，不是隨產品交出去的東西——曝光是真的發生過，統籌者親自開網址確認過。嚴重性維持原評級，不因任何後續裁定而降低。
緩解方式：已用 Cloudflare Zero Trust 擋住那個文件站的公開存取——現在要先通過身分驗證才進得去，網際網路上的任何人不再開網址就看得到。決策者裁定：不列為緊急項目。
密碼要不要換——已裁定：不換。
| 裁定 | 決策者 2026-09-20 裁定不更換這組密碼 |
| 理由 | 那組帳密只有測試機在用，不是隨產品出給客戶的東西，換發的收益極低 |
| 不是新決定 | 跨模組總表早就寫著「測試機專用的資料庫與系統管理帳號密碼不需要更換（因為只有測試機在用）」——這次是同一裁定的再次確認。之前口頭講過多次但沒有落進文件，這次固化下來 |
根因那件事也已經處理：
| 根因那件事 | 現況 | |
|---|---|---|
| 一 | 出貨流程要加自動密碼檢查——這次的出口是文件站，下次可能是別的出口，擋住一個出口不等於解決根因 | ✅ 已做（CM-2207）：文件與腳本裡的測試帳密已改成指路文字、公開文件站重建，文件站建置時會自動擋下密碼字串；決策者 2026-09-26 再次確認三組帳密屬測試用、不換 |
狀態已從「未修」改為「已處置」。決策者確認該權杖已撤銷。
查證過程留個痕，供日後追溯：逐一掃過版本紀錄後確認有兩把不同的權杖——一把在另一個套件的設定檔裡（已在工單 CM-1573 處理完畢），另一把是寫死在三支程式碼裡的，最早出現在 2025-06-10。原始報告指出的「從未撤銷」是後面這一把，已確認撤銷。
這些本頁不下結論，列出來等決策。
| 待決的事 | 目前手上的判斷依據 | |
|---|---|---|
| 一 | 出貨流程加自動密碼檢查，排在什麼時候 | 這與第 4、5 條是同一個根因——兩次都是靠人工掃描才發現，不是流程自動擋下來的。待決策者與 PM |
| 二 | 第 2、3、4 條要不要排入修正 | 三條的原工單（CM-1596～1598）已隨 09-21 統一派工作廢，目前沒有修正卡。第 2、3 條修法已拍板（收編號、改成看得見），第 4 條是從版本控制移除一支檔。待決策者裁定 |
原本列在這裡待決、已拍板的三件，記錄在此供稽核對照——不是憑空消失。
一句話：這塊只有一件大事，那一件是全案最嚴重的——已修好，隨 1.21.0 出貨（CM-2052）。剩下的第 2～4 條都是中、低風險，仍未修，而且目前沒有修正卡。
現況：
要提醒的一件事：第 6 條已處置、第 5 條已處理，但這兩條都是檢視範圍外順手撈到的、屬於我們自己的基礎設施，不是這塊的核心問題。這塊真正的四條（第 1～4 條）修好的是第 1 條，第 2～4 條還沒動。
最後一句話要講清楚：產品還沒出貨，代表這些問題還沒有傷害到任何人——但不代表它們不嚴重。每一條都是真的，出貨之後就會是真實客戶的風險。這一輪正是為了在那之前把它們處理掉。
| 統計 | |
|---|---|
| 檢視輪數 | 5 輪、99 個檔案 |
| 通過的發現 | 24 條（去重後 3 條屬於本模組、3 條屬於範圍外） |
| 人工複查新增 | 1 條（撤銷只擋一半，併入第 1 條一起修好） |
| 最嚴重 | 1 條 |
| 已處置 | 1 條（第 6 條） |
| 已處理 | 1 條（第 5 條：文件已清、建置加密碼檢查；密碼經裁定不換） |
| 已修 | 1 條（第 1 條，CM-2052） |
| 未修 | 3 條（第 2～4 條，目前沒有修正卡；原工單 CM-1596～1598 已隨 09-21 統一派工作廢） |
| 修法已拍板 | 2 條（第 2 條收編號、第 3 條改成看得見） |
| 仍待決策 | 2 件（見上方） |