本卡為 FR-076 母案。License 簽發與驗證鏈的資安掃描，四棒切分，只掃不修。子卡清單在末段。

這系列在做什麼（白話）

產品的授權機制由兩端組成：license_center 負責簽照（私鑰在這裡），jedi-license-runtime 裝在主產品裡負責驗照。這系列把兩端完整掃一遍，找資安問題。

只找問題、不修問題。產出是一份可信的問題清單，修正另外開卡。

為什麼要做

比 jedi-iam 更值得掃，因為攻擊者的動機明確且獲利直接：繞過授權等於免費使用整套產品。而 jedi-iam 的漏洞多半要先有帳號或有網路位置。

這兩支從來沒有被系統性掃過。2026-07 的資安掃描（security-scan-2607）只掃主專案 BE/FE；FR-075 掃的是 jedi-common 與 jedi-iam。License 鏈是完全的空白。

首腦讀過程式碼後認為最值得看的幾點

• 兩種信封格式共存：verify_payload 同收 v2 與 v1，兩條路徑的檢查是否等價、能否降級攻擊
• 三種憑證共用一支驗章與同一組公鑰（license／manifest／unlock_token），且 payload_type 缺鍵時預設當 license——型別混淆的空間
• 公鑰硬編三把（DEV／STG／POC）：用 DEV 私鑰簽的照，POC 機器也會認。刻意還是疏漏？
• 機器指紋 fallback 到 MAC：讀不到 /etc/machine-id 就用 uuid.getnode()，攻擊者能否讓它變成可控值
• license runtime 的端點自己不掛守門，靠宿主注入 decorator——有沒有漏掛的
• license_center 是對外網頁後台：登入、CSRF、模板注入、API token，攻擊面性質與其他三棒完全不同

四棒怎麼分

• L1 License 驗章核心（密碼學層）（jedi-license-runtime，約 10 檔）— 這 10 個檔決定「一張 license 是真是假」。
• L2 License 授權狀態與 API（jedi-license-runtime，約 33 檔）— 驗章之後的部分：照存哪、狀態怎麼轉（生效／到期／寬限／停權）、誰能上傳或指派照、租戶之間怎麼隔離。
• L3 License Center 簽發核心與模組（license_center，約 32 檔）— 簽發端的核心：私鑰怎麼被載入與使用、照怎麼被簽出來、API token 怎麼驗、竄改回報怎麼收。
• L4 License Center 網頁後台（license_center，約 43 檔）— 簽發站的操作介面，是唯一對外開網頁的部分。

L1 先跑：只有 10 個檔但密度最高，一兩小時內會有結果，順便驗證「Opus 1M ＋ 小範圍」這個組合。L1 順利再派其餘三棒（L2／L3／L4 之間無衝突，可平行）。