CodeQL 2.27.0 升級怎麼查？從 Linux ARM64 到 SelfHostedQuery

CodeQL 2.27.0：Linux ARM64 要改成按架構取 CLI#

CodeQL 2.27.0 提供 Linux ARM64 的原生 CLI／bundle。這對使用 ARM64 self-hosted runner、ARM 架構建置主機，或自行快取 CodeQL CLI 的團隊最有感：下載與快取流程不能再假設所有 Linux runner 都是 x64，也不要把已標示 deprecated 的通用多平台 codeql.zip 當成長期介面。

先在 workflow 與安裝腳本盤點三件事：

1
rg -n 'codeql|linux64|arm64|x86_64|codeql\.zip' \
2
  .github scripts Makefile package.json 2>/dev/null || true
3
uname -m

接著讓 runner 架構成為下載與 cache key 的明確輸入：

這是工具鏈的部署邊界，不代表 ARM64 會自動修正 query 或 workflow 權限。升級後仍要執行一次完整分析，確認 database 建立、query pack 載入與 SARIF 上傳都成功。

此外，CodeQL 2.27.0 把 Java 9 與 Java 10 標為 deprecated，官方說明預計在 2027 年 1 月移除相關支援。如果你的分析矩陣仍包含這兩個版本，現在就應把它們列為 migration work，而不是等 CLI 下一次升級才處理。

先確認你是否真的使用了這個 module#

GitHub 會自動把新的 CodeQL 版本部署到 GitHub.com 的 code scanning；如果你使用 advanced setup、遠端 query pack 或 repository 內的 .ql 檔案，先在 repository 根目錄盤點引用：

1
rg -n 'SelfHostedQuery|codeql\.actions\.security' \
2
  .github codeql 2>/dev/null || true

接著把搜尋結果分成三類：

如果你只使用 default setup，仍可參考 GitHub Code Scanning default setup 的中央設定檔；那篇處理的是設定檔如何套用，不是這次被移除的 query module。

CodeQL 2.26.x：GitHub Actions finding 變多時先看規則變化#

2.26.4 的 GitHub Actions query 調整，可能讓同一個 workflow 在升級後出現新的 finding 或不同的 alert 位置。先把變化分成「偵測能力變強」和「原本的安全假設不再成立」，不要直接回退 CodeQL：

GitHub 的說明也列出其他語言的變化，例如 Rust data flow alert 會依實際 source／sink 調整位置，部分 alert 會關閉後以新位置重新出現。這種「舊 alert 關閉、新 alert 出現」不一定代表風險新增，但應在 code scanning diff 中留下對照。

為什麼不能把 runner label 當成安全邊界#

SelfHostedQuery 原本提供的是與 self-hosted runner 判斷相關的 query 能力。GitHub 在 2.26.3 的說明中指出，runner labels 並不能可靠地區分 self-hosted 與 managed runner，因此把這個 module 移除。

這裡有一個容易誤判的地方：工作流裡的 runs-on 字串可以描述選擇條件，卻不等於一個經過驗證的信任根。若自訂 query 把某個 label 名稱直接當成「一定是自架 runner」或「一定不是自架 runner」，query 可能輸出看似精準、實際上不可靠的安全結論。

因此，遷移時不要只把 import 換成另一個名稱相近的 API，也不要用 runs-on 的字串比對把原問題搬到 query 裡。先寫清楚這條 query 真正要回答的是：

• 哪個 workflow 會接受不受信任的輸入？
• 哪個 job 會在較高權限的 context 執行？
• 哪個步驟會把輸入帶到 shell、action、artifact 或 cache？
• 這個風險是否應由 CodeQL finding、repository ruleset 或 runner 管理政策處理？

依依賴目的選擇遷移方向#

官方 changelog 沒有提供一個一對一的替代 module，因為原本的判斷本身就不應再被當作可靠條件。可以依自訂 query 的目的做保守分流：

用測試分支驗證 query，而不是直接改 default branch#

遷移應至少保留三份證據：query 是否能載入、workflow 是否仍成功、finding 是否有預期差異。可以用下列檢查整理分支中的變更：

1
# 只看 CodeQL 相關設定與 query 變更
2
git diff -- .github/workflows .github/codeql codeql
3

4
# 確認不再載入已移除的 module
5
rg -n 'SelfHostedQuery|codeql\.actions\.security' \
6
  .github codeql 2>/dev/null || true

接著在測試 repository 或 pull request 執行既有的 code scanning workflow，確認：

1. query pack 可以成功解析，沒有 import 或 compilation error。
2. GitHub Actions job 的 permissions、runner 與 secrets 行為沒有因遷移被放寬。
3. 原本應該存在的 finding 仍能出現，預期消失的 finding 有留下原因。
4. 若 query 是在 GHES 或本機 CodeQL CLI 執行，使用的 CodeQL 版本與 GitHub.com 的版本差異已被記錄。

CodeQL 2.26.4 也改善多個 Actions query 的路徑與判斷，因此 finding 的位置或數量改變不一定是 query 遷移失敗。先對照官方 changelog，再逐一檢查 workflow diff；不要把所有新增 finding 都當成誤報。

GitHub.com 與 GHES 的版本邊界#

GitHub 表示 GitHub.com 會自動部署新的 CodeQL 版本；未來的 GitHub Enterprise Server release 會包含 2.27.0，較舊的 GHES 版本則要依平台文件與可用的 CodeQL bundle 評估手動升級。這代表同一個 query pack 在不同環境可能同時遇到「已移除 module」、「CLI 架構不同」與「尚未更新」三種狀態。

在 organization 的遷移紀錄中至少留下：平台（GitHub.com 或 GHES）、runner 作業系統／架構、CodeQL Action／CLI 版本、query pack commit、編譯結果與 finding diff。這些資料比只寫「掃描已恢復」更容易在下一次升級時重現。

結論：移除不可靠的 runner 推論，保留可驗證的資料流#

SelfHostedQuery 被移除不是把 import 路徑換掉就結束；CodeQL 2.27.0 也提醒自訂工具鏈不能假設 runner 架構固定。先用 rg 盤點直接與間接依賴，讓 CLI 下載／cache 按架構分流，再依 query 目的拆出 runner 管理政策和 workflow 資料流分析，最後在測試分支編譯、執行與比對 findings。若是遠端 pack，優先確認維護者的相容版本，不要在 production 中自行猜一個替代 API。

常見問題#