We’ve improved the depth of CodeQL's analysis by adding support for more libraries and frameworks and increasing the coverage of our existing library and framework models. JavaScript analysis now supports most common templating languages, and Java now covers more than three times the endpoints of previous CodeQL versions. As a result, CodeQL can now detect even more potential sources of untrusted user data, steps through which that data flows, and potentially dangerous sinks in which this data could end up. This results in an overall improvement of the quality of the code scanning alerts.
We carefully choose and prioritize the libraries and frameworks supported by CodeQL based on their popularity and through user feedback. These improvements are now available to users of CodeQL code scanning on GitHub.com, and will also be available in the next release of GitHub Enterprise Server (3.3).
Java
We've improved coverage for the following libraries:
JavaScript
We've added support for the following templating languages:
Learn more about CodeQL and code scanning.
Developers and security researchers using the CodeQL CLI and VS Code extension can now build databases and analyze code on machines powered by Apple Silicon (e.g. Apple M1).
In order to use the CodeQL CLI and/or the VS Code extension on Apple Silicon, please make sure to install the Xcode command-line developer tools and Rosetta 2.
For detailed instructions on how to set up the CLI on supported platforms, please refer to the CodeQL CLI guide.
Learn more about CodeQL and code scanning.
You can now require that all changes to a protected branch are made using a pull request, but without requiring reviews. This can be useful when you want to use pull requests for tracking purposes or to simplify your continuous integration (CI) configuration, but don't want to gate merging on review.
Previously, you could create a branch protection rule that required pull requests with approving reviews before commits could be merged into a branch. When pull requests were required, approving reviews were also required. This didn’t meet the needs of users who wanted to require pull requests for tracking purposes or CI validation, but who didn’t want their ability to merge to be gated by approving reviews.
Now, requiring pull requests and requiring approving reviews are separate options of protecting a branch. For example, you can now require pull requests without requiring reviews, or with requiring approving reviews. This flexibility lets you choose what is best for you and your branches.
For more information, visit Managing a branch protection rule.