About default setup
Default setup for code scanning is the quickest, easiest, most low-maintenance way to enable code scanning for your repository. Based on the code in your repository, default setup will automatically create a custom code scanning configuration. After enabling default setup, the code written in CodeQL-supported languages in your repository will be scanned:
- On each push to the repository's default branch, or any protected branch. For more information on protected branches, see About protected branches.
- When creating or committing to a pull request based against the repository's default branch, or any protected branch, excluding pull requests from forks.
- On a weekly schedule.
If you need more granular control over your code scanning configuration, you should instead configure advanced setup.
Supported languages
We recommend enabling default setup for eligible repositories if there is any chance the repositories will include at least one CodeQL-supported language in the future. If you enable default setup on a repository that does not include any CodeQL-supported languages, default setup will not run any scans or use any GitHub Actions minutes. If CodeQL-supported languages are added to the repository's default branch, default setup will automatically begin scanning CodeQL-supported languages and using GitHub Actions minutes. For more information on CodeQL-supported languages, see About code scanning with CodeQL.
If the code in a repository changes to include any CodeQL-supported languages, GitHub will automatically update the code scanning configuration to include the new language. If code scanning fails with the new configuration, GitHub will resume the previous configuration automatically so the repository does not lose code scanning coverage.
Available runners
You can use default setup for all CodeQL-supported languages on self-hosted runners or GitHub-hosted runners.
You can assign self-hosted runners for default setup by giving the runners the default code-scanning label, or you can optionally give them custom labels so that individual repositories can use different runners.
Unless you have a specific use case, we recommend that you only assign runners with the default code-scanning label. However, you may want to use custom labels to:
- Assign more powerful self-hosted runners to critical repositories for faster code scanning analysis.
- Run your code scanning analyses on a particular platform (for example, macOS).
- Have granular control over the workload for your GitHub-hosted runners and self-hosted runners.
About advanced setup
Advanced setup for code scanning is helpful when you need to customize your code scanning. By creating and editing a workflow file, you can define how to build compiled languages, choose which queries to run, select the languages to scan, use a matrix build, and more. You also have access to all the options for controlling workflows, for example: changing the scan schedule, defining workflow triggers, specifying specialist runners to use.
You can also configure code scanning with third-party tools.
If you run code scanning using multiple configurations, an alert will sometimes have multiple analysis origins. If an alert has multiple analysis origins, you can view the status of the alert for each analysis origin on the alert page. For more information, see About code scanning alerts.
Next steps
You can enable default setup for a single repository, multiple repositories, or all repositories in an organization at the same time.
- For a single repository, see Configuring default setup for code scanning.
- For bulk enablement, see Configuring default setup for code scanning at scale.
To configure advanced setup instead, see Configuring advanced setup for code scanning.