本卡為 FR-120 母案。決策者裁「主專案掃描準備啟動，與修正線並行」。切 U1～U12 十二棒判斷邏輯掃描＋U13a／U13b 兩棒 DI 專掃＋1 張 DI 腳本實作卡，共 15 張子卡。子卡清單在末段。

這系列在做什麼（白話）

資安掃描已經把 21 支外部套件（管使用者身分、管合規文件、管稽核流程的那些獨立程式庫）全部掃過一輪，但主專案自己寫的程式（BE repo 本身，826 支檔案）從來沒有被系統性掃過——425 支完全沒被任何一棒碰到，其中 119 支有真正的判斷邏輯（會做決定、會查資料庫、會處理使用者輸入），其餘是純資料格式宣告不需要掃。這系列要把這 119 支程式，加上另外一批「接線設定檔」（決定「哪個功能該用哪個安全檢查」的組裝表），全部掃過一遍。只掃不修，找到問題另外開修正卡。

為什麼要做

五個關鍵事實：① 21 支套件已全掃完，主專案自己的程式反而是最後一塊空白；② 這 119 支判斷邏輯檔总共 17,511 行，切成 12 棒（每棒都在 2,000 行、30 檔的上限內）；③ 另外還有 75 支「接線設定檔」（DI，Dependency Injection，決定「這個功能上線時要不要接上安全檢查」的組裝表）從沒被專門核對過，其中 17 支連順帶讀過都沒有；④ 已知至少一處「接線漏掉」的真實案例（FR-113／FR-116 都抓到「查資料時只認編號、不認這筆資料屬於哪家客戶」的洞，根因就在套件的刪除方法裡，主專案這邊接線接得對不對同樣沒人核過）；⑤ 決策者裁定「掃描準備先啟動，開卡、盤點不用等修正線做完」，兩條線並行推進。

首腦讀完後的重點

• U1（權限共用層）排第一：這是全產品守門的地基，common/authz/ 這個目錄的程式決定了「誰能做什麼」，後面每一棒的研究員都會追進來看，只有 U1 自己報這裡的問題。
• U2（啟動與中介層）排第二：這是每一個網路請求都會先經過的關卡（登入檢查、逾期唯讀模式），錯一步全站遭殃。
• U3（安裝精靈）排第三：這幾支程式在使用者登入之前就打得到（安裝新系統時用一次性碼代替密碼），攻擊面比登入後的功能更前面。
• U5／U6（雲端硬碟）零守門字眼：U5 的 Google 回呼端點完全不用登入（靠外部系統回傳的一組代碼認身分），U6 的八支處理器會把資料寫進「沒有客戶隔離」的資料表——這兩棒的程式碼裡連一次「檢查權限」的關鍵字都沒出現，值得優先看。
• U7 有一個總表已經記錄、但沒人核過的疑點：「批次完成任務」這支程式的某一段，被前一輪盤點寫成「疑似把呼叫的人直接當管理員看待」，這棒要去確認是不是真的。
• U8／U9 都在寫或讀『沒有客戶隔離』的資料表：U8 的背景排程用最原始的資料庫指令直接寫四張沒有客戶欄位、沒有資料庫層隔離保護的表；U9 的專案摘要報告則是「同一家客戶內，非該專案成員能不能偷看別的專案」的問題（資料庫的保護只擋得住跨客戶，擋不住公司內部跨專案）。
• 資料庫隔離總表的結論（第 6 節）：compliance.job_evidences（證據）、task_assignees（任務指派人）、job_execution_devices、job_execution_org_units 這四張表完全沒有客戶隔離、也沒開資料庫的保護機制——寫這幾張表的程式（U6、U8）如果邏輯有漏洞，資料庫不會幫忙擋。
• U13（接線設定檔）值得先做一支腳本，不建議直接用掃描工具：這類問題是「少接一條線」，掃描工具擅長抓「程式邏輯寫錯」，不擅長抓「應該要有卻沒有的東西」；建議先寫一支比對腳本，列出每個功能需要哪些安全檢查零件、容器組裝表實際給了哪些，自動找出缺漏，U13a／U13b 兩棒帶著這份比對結果去看最可疑的地方。

怎麼拆

• U1 權限檢查共用層＋共用小工具（15 檔／1,132 行）— 全產品守門地基，優先序第 1。
• U2 啟動與中介層（6 檔／1,233 行）— 每個請求都經過，優先序第 2。
• U3 首次安裝精靈＋版本資訊（9 檔／930 行）— 登入前就打得到，優先序第 3。
• U5 雲端硬碟：回呼＋同步排程主幹（9 檔／1,838 行）— 不登入的外部入口＋零守門，優先序第 4。
• U6 雲端硬碟：八支檔案搬移處理器（10 檔／1,758 行）— 寫沒隔離的表，優先序第 5。