CodeQL 2.26.3 移除 SelfHostedQuery 怎麼辦？先盤點自訂 GitHub Actions query

先確認你是否真的使用了這個 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。

為什麼不能把 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.3 也改善多個 Actions query 的路徑與判斷，因此 finding 的位置或數量改變不一定是 query 遷移失敗。先對照官方 changelog，再逐一檢查 workflow diff；不要把所有新增 finding 都當成誤報。

GitHub.com 與 GHES 的版本邊界#

GitHub 表示 GitHub.com 會自動部署 CodeQL 2.26.3；未來的 GitHub Enterprise Server release 會包含這項功能，較舊的 GHES 版本則可以手動升級 CodeQL。這代表同一個 query pack 在不同環境可能同時遇到「已移除 module」與「尚未更新」兩種狀態。

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

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

SelfHostedQuery 被移除不是把 import 路徑換掉就結束，而是提醒自訂 query 不應把 runner label 當成安全邊界。先用 rg 盤點直接與間接依賴，依 query 目的拆出 runner 管理政策和 workflow 資料流分析，再在測試分支編譯、執行與比對 findings。若是遠端 pack，優先確認維護者的相容版本，不要在 production 中自行猜一個替代 API。

常見問題#