We’ve gotten great feedback on default setup, a simple way to set up code scanning on your repository. Now, you have the ability to use default setup across your organization's repositories, in just one click.
In January, we launched default setup, a new way to enable code scanning. Default setup has been a game changer, allowing you to enable code scanning on your repository in just a few clicks, without using a .yaml workflow file. We’ve gotten great feedback from the security community, and the numbers speak for themselves. Almost half of all new code scanning implementations now utilize default setup to enable code scanning and 96% of users who try default setup continue to use the feature today.
In the last month, we’ve expanded our default setup feature to offer you greater flexibility and ease of enablement. These enhancements include the ability to scale code scanning across specific groups of repositories or even your entire organization, additional query pack configurations, and the ability to use an API to leverage default setup.
First, let’s take a deeper look at the highly requested feature, multi-repository enablement, for code scanning default setup.
Multi-repository enablement allows you to easily enable many security features, including default setup for code scanning, directly from the security coverage page in security overview. This feature offers greater flexibility and granularity than the “Enable all” functionality, which enables a security feature for all repositories in your organization. With multi-repository enablement, you can now effortlessly filter for repositories on the security coverage page by attributes, such as team or repository topic, and enable code scanning default setup for only those repositories with just a few clicks.
Additionally, you have the option to exclude repositories where you don’t want code scanning default setup, or other security features, enabled by using the negation symbol (“-“) when filtering. This is particularly useful for excluding repositories such as test or documentation repositories. These options allow you to scale code scanning effortlessly, ensure that the feature is only enabled on the repositories that matter most, and gain greater visibility into your application security surface.
To get started using multi-repository enablement, go to the security coverage page in security overview.
There, you’ll be able to select multiple repositories by checking the checkbox next to each repository. To select all repositories on the page, click the checkbox in the header row, and then click the “Select all repos” hyperlink to select more than 25 repositories.
Next, click the “Security settings” button in the header row to choose which security features to enable/disable by selecting the relevant drop-downs in the enablement panel. The settings will apply to all eligible repositories that you selected in the previous step. Note: for those security feature drop-downs that say “No change,” the feature’s enablement status will not be modified. If the security feature was previously enabled for some repositories and not others, the enablement state will remain this way after submitting your changes. Finally, click “Apply changes” to submit your changes.
Along with the new multi-repository enablement feature, we also offer a one-click option to enable code scanning default setup for all eligible repositories in your organization. To use this option, navigate to the “Code security and analysis” section on the “Settings” tab of your organization. There, you’ll see an option to “Enable all” for code scanning default setup, in the same way we have for other GitHub Advanced Security products.
Clicking “Enable all” will automatically set up code scanning’s default setup on all eligible repositories in the organization. As a reminder, default setup automatically uses the most up-to-date starter workflow to find the best configuration for each repository. For information on how to see which repositories are enabled, please see our documentation.
We’ve also been working to enhance the default setup experience at the repository level. We have recently added the ability to use the extended query suites for analysis. This query suite can be selected during setup or changed at any time by viewing and editing your CodeQL configuration.
Our extended suite includes the same high precision queries as our default suite, but also includes lower severity and experimental queries. This is useful if you’d like to see a wider range of alerts.
We’ve also shipped an API for repositories to programmatically enable code scanning’s default setup. This can be used to onboard a repository to code scanning, specify which query suite the configuration should use, view the current configuration, and offboard the repository from default setup.
These improvements are meant to give you more flexibility in how you can leverage default setup to meet your specific use case. We have a number of other exciting enhancements on our roadmap for default setup, including support for additional languages and additional customization options, so watch this space for future announcements.
GitHub is committed to helping build safer and more secure software without compromising on the developer experience. To learn more or enable GitHub’s security features in repositories, check out the getting started guide.
This blog post is an in-depth walkthrough on how we perform security research leveraging GitHub features, including code scanning, CodeQL, and Codespaces.
In this post, I’ll look at CVE-2023-6241, a vulnerability in the Arm Mali GPU that allows a malicious app to gain arbitrary kernel code execution and root on an Android phone. I’ll show how this vulnerability can be exploited even when Memory Tagging Extension (MTE), a powerful mitigation, is enabled on the device.
With push protection now enabled by default, GitHub helps open source developers safeguard their secrets, and their reputations.
Walker Chabbott 
Kelly Arwine 
Dorothy Mitchell 
