本卡屬 FR-120(母卡待填)。這一棒掃主專案自己程式的「任務入口與批次」(7 檔/1908 行)。只掃不修。
用資安掃描工具掃 BE repo 自己寫的「任務入口與批次」這塊程式(7 檔,約 1908 行),找出權限檢查、資料歸屬判斷上的漏洞並產出報告。只找問題、不修問題。
🔴 優先序第 6:總表已知未核對點——「批次完成任務」疑似把呼叫者當管理員看待,決策者裁定要掃(decision-draft.md 第 50 項)。
這些是首腦讀過盤點檔與程式碼後認為最容易出事的地方,是思考起點不是檢查清單:
job_batch_complete_service.py:50-56:總表第 59 項「預設把呼叫者當管理員」的未核對點,前一輪盤點明寫「待核對」,這是本棒最重要的一條。job_import_service.py(470 行):Excel 批次建任務。前一輪盤點寫「匯入三步只有最後一步有守門」。問:前兩步(上傳、預覽)能不能讀到別的專案的資料。my_grc_jobs_query.py、flow_control_dashboard_repo_impl.py:「我的任務」與儀表板查詢,原生 SQL。問:WHERE 條件有沒有限定「是我的」/「是我能看的專案」,還是只靠資料庫的保護機制。job_route.py:只掛登入+授權模組,權限在 job_service._require_manager(已掃過)。問 route 這層有沒有哪支方法沒走到那道檢查。or 串起來,其中一個條件永遠成立;例外處理把「查不到資料」與「沒有權限」混成同一個回應;背景排程/系統身分執行的程式碼假設「呼叫者一定是自己人」;防重放/計次的邏輯只在單一進程內生效,多台機器或重啟就破功;註解寫「這裡刻意不檢查」但沒人在上一層真的檢查。本範圍從未被任何一棒正式掃過。U7 ↔ U8 接縫:task_existence_query.py 放 U8,U7 會讀不重報;job_service.py(已掃)U7 可讀不重報。
第一步:讀完本卡與母卡,再讀盤點檔 docs/features/FR-119-2609-security-scan-closeout/scan-inventory.md 對應本棒段落。
第二步:驗 scope 檔數,在 BE repo 跑下面指令,對上 7 檔/1908 行 才往下;對不上停下回報。
cd /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be && git ls-files -- \
api/flow_control/routes/job_route.py \
api/flow_control/serializers/job.py \
app/flow_control/service/job_import_service.py \
app/flow_control/service/job_batch_complete_service.py \
app/readmodel/service/my_jobs_app_service.py \
infra/readmodel/tasks/my_grc_jobs_query.py \
infra/readmodel/audit/flow_control_dashboard_repo_impl.py | xargs wc -l | tail -1 # 7 檔、1908 行
第三步:把啟動指令交給決策者(你不能自己啟動)。/claude-security 帶 disable-model-invocation: true,模型用 Skill tool 叫會被直接擋掉;也不可以自己叫 Workflow、不可以自己派研究員/verifier 拼報告——三人面板的票數是工具程式碼算出來的,報告的驗證章就蓋在那個數字上。這是刻意設計,撞到不要 debug、不要找繞路。兩行要當同一則訊息送出,第二行不能省(省了會停在成本確認題):