🔴 一頁看完

前兩棒（P1 系統設定表、H1 主專案接線）都掃完並驗收通過，一共找到 3 個問題（2 個高、1 個低）。第 3 棒 P2 也已掃完，零發現，三棒收口。

第 2 棒最嚴重的那個，一句話：一個客戶的管理員，可以改掉全公司所有人的登入規則——包含平台管理員自己。他可以關掉全公司的雙因子驗證、把登入失敗鎖定次數改成極大值（等於永遠不會鎖定、可以無限次猜密碼）、把登入憑證有效期從五分鐘延長到一個月。原因是「修改登入安全政策」這個權限被標成客戶層級，每開一個新客戶就自動發給那個客戶的管理員，但這支功能寫入的不是該客戶自己的設定，而是全系統共用的那一列。更嚴重的另一半：完全相同的形狀也套在 LDAP（員工帳號目錄）與寄信伺服器設定上——一個客戶的管理員可以把全公司的登入驗證來源，指到他自己的機器上。登入政策被改壞還看得出來，驗證來源被掉包是直接接管所有人的登入，這一半比上面那半更該先修。

完整結果見 H1 報告，驗收過程見下方「H1 驗收」段。

最嚴重的那個，一句話：讀取系統設定的三個入口只檢查「你有沒有登入」、完全不檢查權限。任何一個最低權限的員工帳號——不必是管理員、不必有任何權限、不必知道任何編號——打一個請求就拿得到物件儲存的帳號密碼。物件儲存是放所有客戶上傳檔案的地方，拿到那組帳密等於所有客戶的檔案可讀可寫。同一支檔案裡，新增／修改／刪除三個入口每一個都有權限檢查，證明讀取這裡是漏掉的，不是刻意設計。

為什麼「每個客戶的資料庫隔離」擋不住：隔離擋的是「看到別的客戶那一列」，可是每個客戶自己那一列裡裝的是同一把鑰匙——安裝時產生一組，之後每建一個新客戶就把它原封不動複製一份過去。首腦 2026-09-15 對開發環境資料庫實際查證（只比對雜湊值、沒有印出明文），確認租戶 1 與租戶 102 手上的密鑰完全相同——「複製給新客戶」從推測變成實證。

第二個問題（低）是：就算權限補好了，回傳設定時的密碼遮罩名單漏掉了物件儲存那一組，所以有正當權限的管理員打開頁面時，瀏覽器裡仍會收到明文密鑰。

完整結果與可信度說明見 P1 報告，驗收過程見下方「P1 驗收」段。

這一支跟前面幾支不一樣。前面掃的是「誰能看到誰的資料」——客戶 A 撈得到客戶 B 的名冊、任務、檔案。這一支存的不是客戶資料，是系統自己的鑰匙：寄信伺服器、LDAP 目錄服務、物件儲存的連線設定，裡面有帳號和密碼。一把寄信密碼外流，攻擊者能用公司名義寄釣魚信；一把物件儲存密碼外流，所有客戶上傳的檔案都在他手上。而且改設定是全站生效的總開關——改掉 LDAP 伺服器位址，等於把全公司的登入驗證導去攻擊者的機器。

首腦開卡時已經開檔核出三件事（未經三人檢查員面板驗證，寫進卡當錨點）：

1. 四個地方繞過了「守門版」服務。 主專案本來把兩條產品規則（出廠快照要藏起來、共用設定要落在總部那一列）包成一支守門版服務，設計意圖寫得很明白：「單一收口點，所有使用者拿到同一個過濾後的視圖」。但另外四支組裝檔用的是未包裝的原版（auth_containers.py:180、notification_containers.py:20、user_change_password_containers.py:46，加上 login_containers.py 直接接底層）。這四條路徑是登入、寄信、改密碼——全都會碰到寄信伺服器的密碼。
2. 讀設定會把整列內容（含密碼原文）寫進日誌檔。 system_config_service.py:20 一行把整包塞進 log，而設定列的內容是 JSON，寄信那列裡面就是「密碼欄位：真密碼」。這是總表已登記的「密碼寫進日誌」那幾條（FR-085 C2 HIGH）的源頭表。
3. 遮罩名單漏掉物件儲存那一組。 套件 plugin/contract.py:61 的名單有四組、沒有儲存設定；:65 的機密欄位名只有兩個、沒有物件儲存帳密用的那兩個欄位名。FR-086 B2-A 已從上傳那一側報過這件事（HIGH），這次要從名單這一側確認是不是同一個根因。

資料庫實查（首腦 2026-09-15 對 DEV 唯讀）：設定表有隔離（4 條規則），23 筆分佈在 6 個客戶，其中 6 筆的密碼欄位是有值的——不是空表，真的有東西可偷。

總進度表

一次只派一棒，每棒獨立驗收完才派下一棒。合理停損點在第 2 棒之後（P1+H1 共 49 檔已涵蓋全部的密碼與權限風險面），但沒跑完三棒不能宣稱「這支套件掃過了」。

P1 驗收（首腦，2026-09-15）

結論：兩條發現全部屬實，無改判。可以派第 2 棒。

掃描工具跑完會蓋一個「驗證章」，記錄這一輪自己有沒有跑完整。首腦親自打開那份章檔核對（不是聽掃描的 session 轉述），數字如下：

否決率一半這件事值得講：檢查員不是橡皮圖章。被否決的兩條，否決理由具體到打開檔案指出「這個資料結構只有六個欄位、多送會直接報錯」「同一個數值在另外兩個地方也是內建預設值」。願意否決，通過的那兩條才有份量。

F1 為什麼維持「高」（照決策者的「可利用門檻」判準）：只要一個能登入的帳號，不需要任何權限、不需要知道任何編號，一個請求就拿到可直接讀寫所有客戶上傳檔案的鑰匙。這與 FR-086 的「登入即可跨客戶取檔」是同一級別。

報告寫「每建一個新客戶就原封不動複製一份，所以全部客戶共用同一把」——這句話推論方向對，但當時是從程式碼推的，沒有實際資料佐證。首腦 2026-09-15 對開發環境資料庫做唯讀查詢（只比對雜湊值、沒有印出任何明文密鑰），結果：

• 設定表已開客戶隔離，4 條規則。
• 物件儲存那一組共 7 筆：租戶 1 的出廠預設列（有密鑰，48 字元）、租戶 102 的設定列（有密鑰，48 字元），其餘租戶 1／131／162／163／164 的設定列密鑰欄位是空的。
• 租戶 1 與租戶 102 的密鑰雜湊值完全相同 → 「複製給新客戶」已有實證，不再是推測。

那為什麼還有四個客戶是空的？ 因為負責複製的那支程式「失敗不擋建立」——開發環境沒有真的接物件儲存，它就靜靜跳過了。正式環境每一套安裝都會跑寫入程序，客戶那邊的欄位會是滿的。

這個修正不會降低嚴重度，反而讓它更明確：從「推測會共用」變成「已實測到兩個客戶手上拿著同一把」。

分兩層，答案不一樣：

• 「這兩條是真的嗎」→ ✅ 可信。 面板三票全過、首腦逐條開檔核對、否決率一半證明面板會認真擋。
• 「是不是只有這兩條」→ ❌ 不可信。 三個理由：①這是快篩模式（只派一個研究員讀完全部 24 檔，不做盤點也不做威脅建模），找的是「最明顯的」不是「窮舉所有」；②卡上八項有三項工具根本沒碰；③範圍只有套件設定那一半，主專案接線（第 2 棒）與選單字典（第 3 棒）都不在內。而且 F1 已經證明主專案那支入口有同樣的洞，暗示第 2 棒很可能還有同類問題。

H1 驗收（首腦，2026-09-15）

結論：兩條發現都成立，但淨新增只有 1 條。可以派第 3 棒。

首腦親自打開那份章檔核對（不是聽掃描的 session 轉述）：

為什麼只跑 13 分鐘：P1 跑了 2 小時 39 分，差一個數量級。原因是投票成本＝候選數×3 位檢查員，P1 有 4 條候選、這棒只有 2 條。流程一步沒跳，驗證章完整。且掃描後這 25 檔至今一字未改（首腦比對掃描版本到 HEAD 的差異為空），結果沒有過期。

F1 的一處行號更正：工具報告寫 :134（函式內呼叫服務那一行），真正缺守門的是 :131 的函式本身。報告與總表第 72 項一律以 :131 為準，開工單時兩份文件才不會各指一處。

三位檢查員一致認為 F2 成立，但把可信度停在 中等，卡在一個光讀程式碼答不出的問題：「新開的客戶，預設管理員角色到底有沒有拿到這個權限？」 沒拿到的話這條就打不出來。這只有查資料庫能定案，首腦對開發環境做唯讀查詢：

• 誰實際持有：security-policy.update 標記為非平台層，9 個客戶裡有 8 個非總部客戶的管理員角色實際持有它（Billows Admin、歐洲航空系統管理員、以及五個 System Manager）。
• 全域那一份真的只有一份：登入政策設定共 7 筆、全部屬於總部（編號 1）。
• 為什麼每個新客戶都自動拿到：租戶開通時的邏輯是「把權限全集扣掉平台層的，其餘全部發給該客戶的預設管理員角色」（jedi_iam/app/service/tenant_provisioning_service.py:120-131）——不需要有人手動指派，開一個新客戶就自動多一個能改全公司登入規則的人。

→ 檢查員唯一不確定的前提，在開發環境成立。可信度中等 → 高，嚴重度維持高風險。

🔴 ⬜ 是「沒被提出」，不是「查過沒問題」。 尤其第 ① 點完全沒被回答，下一任不要以為那四條路徑乾淨。

• 「這幾條是真的嗎」→ ✅ 可信。 6 票全投、兩條皆 3:0；首腦逐條開檔核對；F2 的關鍵前提另有資料庫實查佐證。
• 「是不是只有這幾條」→ ❌ 不可信。 ①這是快篩（單一研究員讀完 25 檔，不做盤點、不做威脅建模、不跑密鑰專項）；②卡上八點有四點完全沒碰、三點只碰一半；③（H1 當時）選單字典那一棒 P2 尚未跑，現已掃完收口。

⚠️ 這是全計畫第七次 runner 未交付四件（前六次：C1／S7／B2／H3／H1／FR-096 P1）。掃描本身完整有效，缺的只是「寫成給人看的文件」這一步。

P2 驗收（首腦，2026-09-15）

結論：零發現屬實，否決站得住。這支套件三棒全數收尾。

候選內容：前台取下拉選項的端點（任何登入者可打）只過濾「啟用」、沒過濾「公開」（system_menu_route.py:39）。

首腦四個來源逐項自核，同意否決：

→ 今天打過去選不到任何東西，否決正確。

同一支程式裡就有反例——管理端的分頁查詢有強制過濾公開欄位（app/service/system_menu_service.py:38 寫死 _filter.public = 1），前台那支反而沒有。首腦開檔確認兩處屬實。

意思是「私有」這個設計在管理端被當真、在前台沒有。哪天平台管理員標了一列私有，那一列會立刻出現在所有登入者的下拉選單裡。不是今天打得到的漏洞（要先有平台管理員去建那種資料），故不列為發現；修法只有一行（第 39 行同時檢查兩個欄位）。歸「未來的陷阱」不歸資安發現。

守門順序（四條管理端點都疊平台管理員、順序跳不過）、前台端點回傳範圍、讀選單寫日誌（會，但這張表無密碼無個資，影響低）、排序欄位白名單（有，對不上直接忽略）、撞鍵錯誤訊息（固定句、不帶實際值）、兩支 SQL（內容乾淨、都有防重複機制）——六項全部通過。

• 「零發現是真的嗎」→ ✅ 可信度高。 面板完整、否決理由具體、首腦四個來源自核一致、六個重點另追一遍。
• 「是不是真的乾淨」→ ⚠️ 兩點保留。 ①快篩模式（單一研究員、不做盤點、不做威脅建模、不跑密鑰專項）；②本輪工具沒有回報逐檔覆蓋率，33 檔中 13 支是空的 __init__.py，剩下 20 支能不能保證每支都被讀過，這份結果給不出保證。
• ⚠️ 零發現不等於這一半乾淨：工具的已知盲點是會被程式碼註解說服，而這一半的檔案 docstring 寫了大量「這是刻意設計」的說明（route 檔頭就寫明「消費端點刻意不疊守門」）。唯一那條候選正是撞上這種註解的地方——否決經查屬實，但這代表註解確實在影響判讀。

✅ 這一棒交付四件齊全——本 arc 三棒裡唯一做滿的一棒（P1 缺三件、H1 四件全缺）。

需求討論紀錄

三棒的分界是「密碼在哪、權限在哪、其餘」：

• P1（設定表，jedi 套件）——密碼全在這一半。從端點一路到資料庫的完整路徑、四道守門的接法、遮罩機制、隨包的三支 SQL（建表／隔離規則／預設值）。風險最高，先跑。
• H1（主專案接線，BE repo）——「誰改得動」與「有沒有繞過守門版」的答案都在這裡。套件的說明自己就寫著「四道守門一律由宿主注入」「權限分流表是產品的角色矩陣、留在宿主」，那張表就在這一棒範圍內。跨 repo 必須分棒（工具一次只吃一個掃描根目錄）。
• P2（選單字典，jedi 套件）——內容已查證是無個資的碼表，風險最低，但要跑完覆蓋率才完整。收尾。

為什麼不按分層水平切：權限漏洞活在層與層的接縫上，只給端點或只給服務兩邊都看不出來。三棒都是從端點一路到資料庫的完整垂直切面。

為什麼設定與選單不合成一棒：合起來 57 檔超過一棒的上限（面板成本＝候選數×3 個檢查員，每個從零讀檔），而且兩張表的租戶語意刻意相反（設定要隔離、選單要共享），混在一棒會讓研究員把兩套標準搞混。

選單表沒有客戶隔離，是正確的，不是漏洞。 首腦 2026-09-15 對 DEV 實查：這張表沒開隔離、0 條規則、共 74 筆，內容全是下拉選單的碼表（使用者狀態、啟用狀態、問卷題型這類），沒有客戶資料、沒有個資。選單字典是全站 UI 的資料來源，隔離起來會壞掉所有頁面。套件的說明也寫明兩張表的語意刻意相反：「設定是每個客戶自己的參數，選單是全站共用的字典」。

但有一件相關的事要記一句：查選單的請求格式六個欄位全部非必填，送一個空的查詢條件就回全表。以這張表的內容而言影響有限，但它屬於首腦正在盤的「共用底層送空條件就回全表」那條線（跨 arc 總表 §6 A 組第 15 項，已經第三次撞到）。報告寫一句歸那條線即可，不要當獨立發現升級。

• 首腦手冊：.claude/skills/security-scan-lead/SKILL.md
• 跨 arc 總表：docs/features/security-scan-consolidated/README.md
• 報告寫法範例：FR-081 I2 報告
• 套件路徑：~/Projects/Jedicogy/module/jedi-python-package/jedi-system-core/

以下全部由 build 掃資料夾產生，新增檔案重 build 即自動出現。標題連結指向渲染後的 HTML，md 連向源檔。

證據與盤點

卡片內容（決策紀錄、驗收條件）以 Notion 為準，本頁只記座標。

相關需求：

• FR-075 — jedi-package-security-audit
• FR-085 — common-security-scan
• FR-086 — file-upload-security-scan
• FR-093 — package-migrations-and-capability-seeding
• FR-094 — tenant-isolation-fix
• FR-095 — task-platform-security-scan