本卡屬 FR-120（母卡待填）。這一棒掃主專案自己程式的「零散殘段＋系統設定守門補掃＋人員對帳跨公司比對殘段（三塊合併，決策者裁）」（16 檔／約 1,922（實跑驗檔數為準） 行）。只掃不修。

這一棒在做什麼（白話）

用資安掃描工具掃 BE repo 自己寫的「零散殘段＋系統設定守門補掃＋人員對帳跨公司比對殘段（三塊合併，決策者裁）」這塊程式（16 檔，約 1,921（實跑驗檔數為準） 行），找出權限檢查、資料歸屬判斷上的漏洞並產出報告。只找問題、不修問題。

為什麼切這一塊

🟡 優先序第 10：三塊零散但決策者裁定要一起做——盤點原始 U12（7 檔）＋掃後新增 391 行守門邏輯的系統設定服務（decision-draft 第 52 項）＋沒查完的人員對帳跨公司比對殘段（decision-draft 第 54 項）。

重點看什麼

這些是首腦讀過盤點檔與程式碼後認為最容易出事的地方，是思考起點不是檢查清單：

• common/integrity/adapters.py（357 行）：主專案給防竄改套件（jedi-integrity）的接線，套件本體已掃、這支接線沒掃過。問：雜湊鏈寫入 api_logs（沒有客戶隔離）時的租戶歸屬。
• 兩支解析工作單 repo（ssp_docx_parse_job_repo_impl.py／ssp_excel_parse_job_repo_impl.py）：已知這兩張表的資料庫保護規則寫壞了，這兩支就是讀寫那兩張表的程式，當時沒在範圍內。
• notification_socketio_handler.py：即時通知的 WebSocket 連線。問：連線時怎麼認身分、能不能訂閱別人的通知頻道。
• 🔴 guarded_system_config_service.py（665 行）：這支上次掃描後又新增 391 行、12 支函式，新增的內容就是「平台管理員專屬設定」的守門本身（AI 金鑰遮罩、Google Drive 應用程式設定群組、_platform_admin_only、_assert_restricted_group_access）。問：這道守門實際涵蓋的設定項目名單完不完整，有沒有漏掉哪個敏感設定沒被這道檔住。
• tenant_storage_config_seeder.py：AI 分類設定金鑰寫入邏輯的新增部分（47 行、1 支函式）。問：寫入時有沒有限定租戶。
• 🔴 人員對帳跨公司比對殘段（party_reconciliation_service.py 與 domain/oscal/service/reconciliation/ 下五支）：前一輪盤點沒有查完這塊「人員對帳」邏輯有沒有跨公司比對的問題。問：比對演算法（organization_reconciler.py／person_reconciler.py）有沒有把不同客戶的人員資料放在一起比對、比對出來的結果有沒有可能把 A 客戶的人員錯配到 B 客戶。
• 有人守了一半（跨棒共通疑點，遇到就多看一眼）：只驗證了「你是誰、你登入了沒」卻沒驗證「這筆資料是不是你的」；只檢查了列表查詢卻沒檢查單筆存取；權限判斷寫在 route 層裝飾器卻繞得過（例如有第二支路由沒掛）；守門條件用 or 串起來，其中一個條件永遠成立；例外處理把「查不到資料」與「沒有權限」混成同一個回應；背景排程/系統身分執行的程式碼假設「呼叫者一定是自己人」；防重放/計次的邏輯只在單一進程內生效，多台機器或重啟就破功；註解寫「這裡刻意不檢查」但沒人在上一層真的檢查。
• 零發現時怎麼辦：工具沒有候選，不代表這棒乾淨。逐支通讀一遍，卡片列的每一條「重點看什麼」都要親自開檔核對答完，答案（成立／不成立）寫進報告。

已知背景

本範圍全部從未被任何一棒正式掃過。這是三個獨立盤點結論合併成一棒（decision-draft.md 第 52、54 項裁定併入），驗檔數時務必用下面第二步的實際指令核對總行數（盤點估算約 1,770～1,922 行，需以 wc -l 實跑為準）。

怎麼做

第一步：讀完本卡與母卡，再讀盤點檔 docs/features/FR-119-2609-security-scan-closeout/scan-inventory.md 對應本棒段落。

第二步：驗 scope 檔數，在 BE repo 跑下面指令，對上 16 檔／1,921（實跑驗檔數為準） 行 才往下；對不上停下回報。