CodeQL 2.27.1 accepts GitHub Actions pinned through a lockfile
Victoria Shinder2 min readGitHub released CodeQL 2.27.1 on 25 September, and it is already live for code scanning on github.com; GitHub Enterprise Server will carry it from version 3.24. The release adds support for Kotlin 2.4.20 and fixes how Foo::class.java arguments are extracted under the K2 compiler, which removes false positives in the Android implicit-pendingintents query.
The most consequential change for most repositories is in the GitHub Actions queries. actions/unpinned-tag, which warns when a workflow references an action by a mutable tag instead of a commit, no longer reports actions pinned by a structurally valid entry in .github/workflows/actions.lock for that workflow. It also stops reporting self-references written as uses: $/path/to/action, which resolve to the same repository at the running commit and cannot drift.
Language coverage grows elsewhere. C and C++ get a new cpp/ambiguous-assignment-of-comparison query for code that assigns a comparison to a variable and uses the assignment as a condition, plus taint models for Boost.Asio's resolver, Bloomberg's BDE blob buffer and the protobuf MessageLite API. Go gets models for 1.27 standard-library additions including strings.CutLast and the new encoding/json/jsontext package. JavaScript analysis now recognises Fastify servers configured through chained calls such as withTypeProvider(), which may add js/missing-rate-limiting findings and remove false ones where a global plugin protects the route. C# gets cs/linq/missed-firstordefault and stops suggesting LINQ rewrites that would not compile, and the anti-forgery query now understands a globally registered AutoValidateAntiforgeryTokenAttribute.
What it means
Most of this list is the unglamorous work of reducing false positives, and that is the part worth noticing. A code-scanning rule that fires on correct code teaches people to dismiss it, and once dismissal is a habit the true positive gets dismissed too. The unpinned-tag change is a good example: projects that had adopted a lockfile to pin their actions were still being told they had not, so the rule was punishing exactly the behaviour it exists to encourage.
Two practical steps. If your repository has accumulated dismissed unpinned-tag alerts, review them after the update - the ones that disappear were noise, and the ones that remain now mean something. And if you rely on the JavaScript rate-limiting query for Fastify services, expect the alert count to move in both directions and triage the new results rather than treating the change as a regression.