CodeQL adds beta support for Kotlin! 🚀

[turbo]

Starting today, GitHub code scanning includes beta support for analyzing code written in Kotlin, powered by the CodeQL engine.

Kotlin is a key programming language used in the creation of Android mobile applications, and is an increasingly popular choice for new projects, augmenting or even replacing Java. To help organisations and open source developers find potential vulnerabilities in their code, we’ve added Kotlin support (beta) to the CodeQL engine that powers GitHub code scanning. CodeQL now natively supports Kotlin, as well as mixed Java and Kotlin projects. Set up code scanning on your repositories today to receive actionable security alerts right on your pull-requests. To enable Kotlin analysis on a repository, configure the code scanning workflow languages to include java.

CodeQL support for Kotlin has already been used to identify novel real-world vulnerabilities in popular apps, from task management to productivity platforms. You can watch the GitHub Universe talk on how CodeQL was used to identify vulnerabilities like these here.

Kotlin beta support is available by default in GitHub.com code scanning, the CodeQL CLI, and the CodeQL extension for VS Code. GitHub Enterprise Server (GHES) version 3.8 will include this beta release.

If you have any feedback or questions, please use this discussion thread or open an issue if you encounter any problems.

[sschuberth]

I tried to enable Kotlin analysis in here, but the build after initializing CodeQL is running into java.lang.OutOfMemoryError: Java heap space although a regular build just works fine.

@turbo, can it really be that a build after CodeQL initialization takes more memory?

PS: I tried with autobuild first, but changed to a manual build step after I saw the same memory issue originally there.

[turbo]

Hi @sschuberth,

I've raised this issue internally. The team is investigating and will get back to you with next steps soon.

[tamasvajk]

Hello @sschuberth,

I could reproduce your java.lang.OutOfMemoryError: Java heap space issue locally with the following build command ./gradlew clean classes -x :reporter-web-app:yarnBuild. To some extent, it's expected that the analysis takes more memory than a normal build. We're going to investigate if we can improve on our memory footprint. For the time being, I was able to overcome the issue by adding -Dorg.gradle.jvmargs=-Xmx1g to the build command.

Let us know if this doesn't unblock you.

[LeShadow]

Hey @turbo ,

I've been following this closely because this was a requested language for us!

Am I correct to assume that in your CodeQL file you have to add both java AND kotlin to the language matrix?

Thank you!

[turbo]

Hi @LeShadow,

Good question! No, Kotlin is part of our Java support. You only have to enable java, which from now on automatically includes Kotlin (even for Kotlin-only projects).

[LeShadow]

@turbo thank you for the clarification!

I did a test run on one of our repositories, and either we have super good code quality or I am missing something. Because I have no alerts whatsoever on an entire codebase. Is this possible with the default settings?

[turbo]

@LeShadow To check if CodeQL has successfully analyzed Kotlin code, take a look at the Actions logs for the workflow. It should include a section on "analyzed LoC" (lines of code). If those roughly match the expected count, the analysis worked as intended.

If that's the case you can then take a look at increasing the number of queries run by, for example, enabling the security-extended query suite.

A note on:

super good code quality

Just to avoid confusion: CodeQL's focus is code security, not code quality. So while extended the number of queries run may flag up additional security alerts, it won't include quality checks. For that use case, we recommend running additional quality tools that integrate with GitHub code scanning, such as Detekt.

If you still encounter problems after following these steps, please open an issue and the team will assist 🙂.

[sschuberth]

No, Kotlin is part of our Java support. You only have to enable java, which from now on automatically includes Kotlin (even for Kotlin-only projects).

How about simply defining "kotlin" as an alias for "java" to avoid some potential user confusion? Also, if users would start using "kotlin" already now, that would allow you guys to seamlessly introduce Kotlin-specific checks in the future.

[turbo]

@sschuberth Thanks for the feedback. The mapping is automatically done when code scanning is set up via the UI for the first time on a repo containing Kotlin and we're considering various ways of making this more seamless for our integrated languages (Java/Kotlin, JS/TS).

[sschuberth]

So, I've run into a new problem now. After increasing the heap memory helped to complete a CodeQL scan, three Arbitrary file write during archive extraction ("Zip Slip") issues were found, which is great. However, these findings stick around even after addressing them.

Can it be that CodeQL cannot deal with Kotlin's File.startWith() extension function to recognize the check, @tamasvajk?

[smowton]

https://github.com/github/codeql-cli-binaries/releases

Since that has been released, with tools: latest you should see CodeQL 2.12.3 in use and Kotlin 1.8.10 supported.

[sschuberth]

@smowton I'm still seeing this with tools: latest in a PR that I've created about 1 hour ago.

[smowton]

Apologies, I missed that in fact we need both a CLI binary (released yesterday) and a corresponding bump to https://github.com/github/codeql-action/tree/releases/v2, which typically follows around a day or two later.

[smowton]

Edit: said bump has now been applied. Rerunning your workflow ought to work.

[sschuberth]

Confirmed, thanks for the heads-up!

[eygraber]

I integrated CodeQL into my Kotlin project but the action log and CSV show that Kotlin files weren't extracted. Is there something that needs to be done to let CodeQL know that there are Kotlin files present?

[sschuberth]

What looks a bit weird is that you set up gradle-build-action, but when use a manual run step to build (instead of passing arguments to gradle-build-action). Though I don't think that should be the root cause of things not working in your case. Anyway, this works for us.

[eygraber]

I have another repo where that works fine. With this one I'm noticing a warning "Timed out waiting for analysis to finish processing"

[sschuberth]

Probably a memory issue. Try increasing the memory for building similar to like we did.

[Marcono1234]

@eygraber, were you able to solve this? I assume you fixed it by disabling the build cache in eygraber/portal@182ac6e, right?

[eygraber]

Yes, sorry I forgot I had two places where I was discussing this. Disabling the caching solved the problem.

[NorseDreki]

Hi there,

Looks like support for Kotlin actually means support for Kotlin code only targeting JVM, is that assumption correct?
From what I see, is there currently no support for Kotlin / Native code which compiles to platform native binary?

[smowton]

That's right. That could change in the future, but right now our support works as part of a combined Java/Kotlin JVM languages analysis.

[NorseDreki]

Thanks for heads up.