本卡屬 FR-078(母卡 CM-1602),第 1 棒:jedi-notification 套件本體(jedi monorepo)。只掃不修。本棒同時是「5X 額度下驗證面板跑不跑得完」的實驗。

這一棒在做什麼(白話)

用 claude-security plugin 掃 jedi-notification 這支套件的全部程式碼(30 個受版控 .py,其中 15 個是 __init__.py(多數為空),真正有邏輯的 15 檔約 622 行),找出資安問題並產出報告。這支套件負責產品所有對外通知的實際投遞:SMTP 寄信、Discord webhook、Telegram bot。只找問題、不修問題。

為什麼切這一塊

套件本體與宿主接線在兩個 repo,而 scanRoot 只能指一個目錄,所以物理上必須切開(宿主那半是 N2)。本棒單獨看「協定層怎麼實作」:憑證驗不驗、密碼會不會進 log、對外請求有沒有 timeout、使用者輸入怎麼組進郵件標頭。

額外意義:這是至今嘗試過最小的一棒(FR-076 L1 的 10 檔是唯一面板跑完的紀錄,本棒 30 檔但有效邏輯只有 15 檔 622 行)。決策者目前 5X 額度,FR-077 R1 的 42 檔面板全滅。本棒的面板跑不跑得完,決定這個工具在此額度下還能不能用。

重點看什麼

以下是首腦讀過程式碼後認為最容易出事的地方,是思考起點不是檢查清單——工具不會照這份走,漏掉的要 runner 自己補追(FR-076 L2 的 HIGH 就是 runner 照這種清單人工追出來的,工具只報了 LOW)。

已知背景

本套件從未被掃過。security-scan-2607 只掃主專案 BE/FE;FR-075 掃 jedi-iam;FR-076 掃 License 鏈;FR-077 掃遠端 Agent 鏈(已暫停)。這支是空白。

參照用的舊發現(未經本棒驗證,只是提示同類病灶存在):CM-1560 LDAP TLS 不驗憑證、CM-1565 Redis TLS 不驗憑證、CM-1564 LDAP 連線測試改位址可套出既存密碼。前兩條與本棒重點①同型,第三條與 N2 的測試信端點同型。

🔴 版本落差要在報告裡回答