CodeQL 2.27.0 が Linux arm64 でネイティブ実行、汎用 codeql.zip は将来削除

CodeQL 2.27.0 で、CLI と CodeQL バンドルに linux-arm64 のプラットフォーム別アセットが加わった。arm64 の Linux 上で CodeQL をネイティブに実行できる。GitHub Changelog に9月9日付で載った変更で、github.com の code scanning には新しいバージョンが自動で配られる。影響が出やすいのは、CLI やバンドルを自前で取得している CI、C# を build-mode: none で解析しているリポジトリ、GHES を運用している管理者の3者だ。

arm64 の Linux では linux-arm64 のアセットを取る

CodeQL CLI の項は、linux-arm64 のプラットフォーム別リリースアセットから CLI とバンドルを入手するよう案内している。arm64 のセルフホスト環境で code scanning を回したいなら、取得先をこのアセットに切り替えるのが最初の作業になる。

アセットのファイル名の具体的な形は、告知には載っていない。GitHub Actions のワークフローでランナーのアーキテクチャに合わせて arm64 版が自動で選ばれるのかも書かれていない。既存の取得スクリプトを流用するなら、リリースページのアセット名と突き合わせてから URL を組み立てたほうが安全だ。

汎用の codeql.zip は将来消える、いまは警告だけ

同じ告知の Upcoming Deprecations に、全プラットフォームをまとめた codeql.zip を将来のリリースで削除すると書かれている。代わりにプラットフォームごとの .zip を使うよう求めていて、CLI は全プラットフォーム版から起動されると警告を出すようになった。

ログに残る警告は、次の環境変数で抑えられる。

CODEQL_ALLOW_ALL_PLATFORMS_DIST=true

止まるのは警告だけで、配布物の削除予定は変わらない。どのバージョンで消えるかは示されていない。arm64 のジョブを足すついでに、arm64 以外のジョブも取得先をプラットフォーム別の .zip に揃えておけば、削除のリリースが来たときに取得スクリプトを二度直さずに済む。

GHES では次のリリースを待つか手動で上げる

github.com の code scanning 利用者には、新しい CodeQL が GitHub によって自動でデプロイされる。GHES には将来のリリースで 2.27.0 の機能が入るとされているが、どの GHES バージョンかは明記されていない。

それより前に arm64 対応や以下の変更を使いたい場合、古い GHES でも CodeQL のバージョンは手動で上げられる、というのが告知の案内だ。

default setup が非公開レジストリのクエリパックを引ける

code scanning の default setup が、カスタムクエリやパックを取得するときに Organization のプライベートレジストリ設定を使えるようになった。その設定でコンテナレジストリや GitHub API に認証し、非公開の Git ソースや Docker レジストリに置いたカスタムコンテンツを読み込める。

社内向けのクエリパックを非公開のまま配っているチームには、default setup のままそれを載せられるかを検討する材料になる。ただ、レジストリ設定をどこで登録し、default setup 側で何を指定するかという手順は、この告知には含まれていない。

C# の build-mode: none は NuGet の restore を毎回試す

C# を build-mode: none で解析するとき、CodeQL は利用できる NuGet フィードを使ってプロジェクトとソリューションの restore を常に試みるようになった。明示的に設定されたフィードに到達できなければ、そのことも報告する。

告知が挙げている目的は、解析から欠けているかもしれない依存関係を見つけやすくすることだ。社内フィードを設定しているのに解析環境からそこへ届かないリポジトリでは、この報告が新たに目に入るはずだ。報告されたフィードに依存するパッケージは解析に入っていない可能性があるので、フィードへの到達経路を確かめる手がかりとして扱える。

Micronaut や libpq を使うコードはアラートが増えうる

2.27.0 には、言語ごとの検出範囲の拡大もまとまって入っている。

対象	2.27.0 での変更
C#	ASP.NET Core MVC のコントローラーとアクションの検出を実行時の挙動に近づけた（application parts、エンドポイントマッピング、継承したアクション、除外指定）
C#	OData のアクションパラメーターバインディングで taint tracking に対応（ODataActionParameters から取り出す値、Delta で追跡するエンティティ）
Java/Kotlin	Micronaut をモデリング（HTTP コントローラー、WebSocket エンドポイント、設定の注入、データアクセス、セキュリティアノテーション、HTTP クライアントの sink）
C/C++	PostgreSQL libpq の PQexec、PQexecParams、PQprepare、PQsendQuery、PQsendQueryParams、PQsendPrepare を SQL インジェクションの sink に追加（cpp/sql-injection など）
Rust	rust/command-line-injection を追加。rust/hard-coded-cryptographic-value は近い位置の重複結果を削減。rust/unused-variable は todo!() や unimplemented!() を含む関数の変数を報告しない
GitHub Actions	イベントペイロードの author-association フィールドのチェックは、ペイロードがそのフィールドを持つときだけ保護として扱う

出典：GitHub Changelog「CodeQL 2.27.0 adds support for Linux ARM64」

Micronaut のモデリングは HTTP コントローラーから HTTP クライアントの sink まで広いので、Micronaut で書かれたサービスでは、コードを変えていなくても更新後に新しいアラートが出ることがありうる。これは対象範囲からの推測で、件数の見込みは示されていない。libpq を直接呼ぶ C/C++ のコードも同じ理由で結果が変わりうる。

GitHub Actions のワークフローは、効果のないチェックに頼っている場合に追加のアラートが出る可能性があると告知自身が書いている。9月3日の 2.26.4 も Actions の検出を見直したリリースで、その変更点は CodeQL 2.26.4 の記事 で扱った。

Java のバージョン側では、Java 9 と 10 の言語サポートが非推奨になり、2027年1月に削除される。Java 7 と 8 は引き続きサポートされるので、手当てが要るのは 9 か 10 を対象にしたコードベースだけだ。