本卡屬 FR-120(母卡待填)。這一棒掃主專案自己程式的「啟動與中介層」(6 檔/1233 行)。只掃不修。
用資安掃描工具掃 BE repo 自己寫的「啟動與中介層」這塊程式(6 檔,約 1233 行),找出權限檢查、資料歸屬判斷上的漏洞並產出報告。只找問題、不修問題。
🔴 優先序第 2:每個請求都經過的關卡,錯一步全站遭殃。
這些是首腦讀過盤點檔與程式碼後認為最容易出事的地方,是思考起點不是檢查清單:
license_readonly_mw.py(217 行):授權到期後全站唯讀的閘門。問:它用什麼判斷「這是寫入請求」(HTTP 方法?網址白名單?)——有沒有 POST 其實是讀、或 GET 其實是寫的漏網;白名單網址是前綴比對還是完整比對。jwt_mw.py:登入權杖的解析。問:權杖過期、簽章錯誤、缺欄位時的處理;有沒有哪條路會把「解不開」當成「匿名但放行」。core/app_factory.py(469 行):中介層的掛載順序+哪些路由被豁免。問:豁免清單(免登入、免授權)列了誰,是不是每一個都有理由。main.py 的 diag 子命令分支:命令列入口,確認只在本機命令列觸發、網址打不到。or 串起來,其中一個條件永遠成立;例外處理把「查不到資料」與「沒有權限」混成同一個回應;背景排程/系統身分執行的程式碼假設「呼叫者一定是自己人」;防重放/計次的邏輯只在單一進程內生效,多台機器或重啟就破功;註解寫「這裡刻意不檢查」但沒人在上一層真的檢查。本範圍從未被任何一棒正式掃過。U2 ↔ U3 有接縫:core/app_factory.py 放這棒,U3 會讀它追「安裝精靈的路由怎麼繞過中介層」,U3 不重報這支。
第一步:讀完本卡與母卡,再讀盤點檔 docs/features/FR-119-2609-security-scan-closeout/scan-inventory.md 對應本棒段落。
第二步:驗 scope 檔數,在 BE repo 跑下面指令,對上 6 檔/1233 行 才往下;對不上停下回報。
cd /Users/chouraymond/Projects/Billows/Audit-Manager/compliance-manager-be && git ls-files -- \
common/middleware/jwt_mw.py \
common/middleware/license_readonly_mw.py \
core/app_factory.py \
core/host_capabilities.py \
main.py \
config/config_loader.py | xargs wc -l | tail -1 # 6 檔、1233 行
第三步:把啟動指令交給決策者(你不能自己啟動)。/claude-security 帶 disable-model-invocation: true,模型用 Skill tool 叫會被直接擋掉;也不可以自己叫 Workflow、不可以自己派研究員/verifier 拼報告——三人面板的票數是工具程式碼算出來的,報告的驗證章就蓋在那個數字上。這是刻意設計,撞到不要 debug、不要找繞路。兩行要當同一則訊息送出,第二行不能省(省了會停在成本確認題):