本卡屬 FR-080（母卡 CM-1612），第 1 棒：第三方整合與憑證（jedi monorepo）。只掃不修。風險最高的一棒，建議第一個跑。

這一棒在做什麼（白話）

用 claude-security plugin 掃 jedi-issue 裡「跟 GitLab／GitHub 打交道」的那部分（25 檔），找出公司的存取權杖會不會外洩、對外連線會不會被騙去別的地方這類問題。只找問題、不修問題。

為什麼切這一塊、為什麼排第一

這是整個套件唯一會帶著憑證對外連線的部分，而且這個模組的權杖外洩過一次（CM-1573「jedi-issue PAT 外洩處置」，已 Done）。憑證＋外部連線＋外洩前科三者疊加，風險密度全套件最高。

更關鍵的是：套件檔頭把這 25 檔的大部分標成「死碼、產品沒在用」，而那是錯的（見下方重點 ①）。如果照檔頭的說法跳過，等於把最危險的一塊漏掉。

重點看什麼

這些是首腦讀過程式碼後認為最容易出事的地方，是思考起點不是檢查清單；全部未經任何驗證，以你實際讀到的為準。工具不會照這份清單走，HIGH 級的東西常常要靠人照這裡追出來。

• 🔴 檔頭自陳不可信，這是本套件最重要的警告。 jedi_issue/api/__init__.py:11-13 自稱「GitLab／GitHub 整合目前產品沒有在用，約佔套件 58%」——首腦已從宿主端證偽：app/feedback/service/feedback_service.py 的 156／171／210／222／246／252 六處實際呼叫那些路徑（IssueProviderCode 統計 LOCAL 9／GITLAB 4／GITHUB 3）。這是工具已知盲點二（會被程式碼註解說服）的教科書形狀，FR-075 的 S2 就是這樣八檔零發現卻漏掉真洞。本套件的 docstring 普遍寫得詳盡且處處自我辯護，一律當成待查證的宣稱、不是事實。
• ① 首腦已看到的具體洞（給你當錨點，但要自己驗）：jedi_issue/infra/github.py:22 與 jedi_issue/infra/issue/adapter/github/github_issue_adapter.py:43 兩處都寫 Github(auth=auth, per_page=100, timeout=10, verify=False)——帶著存取權杖走不驗憑證的 TLS，中間人可直接攔下 token。首腦初判 HIGH。要追：verify=False 是刻意還是複製貼上、有沒有設定可覆寫、實際部署會連到哪個主機（自架 GitHub Enterprise？）。
• ② GitLab 那邊有沒有同樣問題。 jedi_issue/infra/gitlab.py:27-31 的 gitlab.Gitlab(url=..., private_token=..., api_version=...) 沒有顯式 verify 參數——要查 python-gitlab 的預設行為（預設驗證還是不驗），以及 url 來自 os.getenv("GITLAB_URL") 時能不能被指向任意主機。
• ③ 權杖怎麼進來、會不會外流。 兩支都是 os.getenv fallback（gitlab.py:18-20、github.py:16）。要追：token 實際由誰設定、有沒有預設值、例外訊息與 log 會不會把它印出來（github.py:19 的 ValueError 訊息本身沒帶 token，但呼叫端的 except 可能把整個物件印出去）。注意 CLAUDE.md 紀律：任何情況不可把金鑰材料寫進落地檔，報告只寫「在哪一行、什麼形狀」不寫值。
• ④ 使用者輸入會流進第三方 API 呼叫。 gitlab_issue_adapter.py（197 行）與 github_issue_adapter.py（163 行）把標題、內容、標籤、指派對象組進請求。要追有沒有可控欄位能改變請求語意——專案 ID／路徑／查詢參數被使用者控制的話，就是「用公司權杖去打攻擊者指定的專案」。
• ⑤ 成員查詢那兩支。 infra/project_member/adapter/gitlab/member_adapter.py（158 行）與 github/member_adapter.py（99 行）——它們回傳的是成員名冊，且是套件唯一對外 route /issue/get_members 的資料源（那條 route 只有 @jwt_required()，見 I4 棒）。要追：查詢時的專案範圍由誰決定、會不會回傳超出呼叫者應見範圍的人。
• ⑥ local_issue_adapter.py（215 行，本群最大檔）。 本地模式是產品實際主用的路徑（IssueProviderCode.LOCAL 出現 9 次）。要追它與 gitlab／github 兩個 adapter 的行為差異——三個 adapter 實作同一組介面，權限與過濾若只有其中一個做了，就是漏洞。
• ⑦ 超時與重試。 github 那邊設了 timeout=10，gitlab.py 沒看到 timeout。要確認對外呼叫會不會吊死（FR-078 的 Discord／Telegram 就是這個形狀）。

已知背景

• 本範圍從未掃過。 jedi-issue 在排名表是第 20 名（129 檔／3,599 行），至今無任何掃描。
• CM-1573「jedi-issue PAT 外洩處置」已 Done（jedi monorepo ed62d8a）——決策者當時裁「token 早已註銷，跳過後台再確認，直接處理 dist／Nexus 殘留」。那是處理外洩的字串，不是修這裡的傳輸方式；本棒要看的是「現在還會不會再外洩一次」。
• 同型前案可參照（未經本棒驗證，只是形狀參考）：CM-1560（LDAP TLS 不驗憑證）、CM-1565（Redis TLS 不驗憑證）、FR-078 CM-1606（SMTP starttls 不驗憑證）——本專案這是第四處同款病。