Creating a custom security configuration

About custom security configurations

We recommend securing your organization with the GitHub-recommended security configuration, then evaluating the security findings on your repositories before configuring custom security configurations. For more information, see Applying the GitHub-recommended security configuration in your organization.

With custom security configurations, you can create collections of enablement settings for GitHub's security products to meet the specific security needs of your organization. For example, you can create a different custom security configuration for each group of repositories to reflect their different levels of visibility, risk tolerance, and impact.

Creating a custom security configuration

1. In the upper-right corner of GitHub, select your profile photo, then click Your organizations.

2. Under your organization name, click Settings. If you cannot see the "Settings" tab, select the dropdown menu, then click Settings.

   

3. In the "Security" section of the sidebar, select the Code security dropdown menu, then click Configurations.

4. In the "Code security configurations" section, click New configuration.

5. To help identify your custom security configuration and clarify its purpose on the "Code security configurations" page, name your configuration and create a description.

6. In the "GitHub Advanced Security features" row, choose whether to include or exclude GitHub Advanced Security (GHAS) features. If you plan to apply a custom security configuration with GHAS features to private repositories, you must have available GHAS licenses for each active unique committer to those repositories, or the features will not be enabled. See About billing for GitHub Advanced Security.

7. In the "Dependency graph" section of the security settings table, choose whether you want to enable, disable, or keep the existing settings for the following security features:

   • Dependency graph. To learn about dependency graph, see About the dependency graph.
   • Automatic dependency submission. To learn about automatic dependency submission, see Configuring automatic dependency submission for your repository.
   • Dependabot. To learn about Dependabot, see About Dependabot alerts.
   • Security updates. To learn about security updates, see About Dependabot security updates.

8. In the "Code scanning" section of the security settings table, choose whether you want to enable, disable, or keep the existing settings for code scanning default setup. If you want to target specific runners for code scanning, you can also choose to use custom-labeled runners at this step. See Configuring default setup for code scanning.

9. In the "Secret scanning" section of the security settings table, choose whether you want to enable, disable, or keep the existing settings for the following security features:

   • Secret scanning. To learn about secret scanning, see About secret scanning.
   • Validity check. To learn more about validity checks for partner patterns, see Evaluating alerts from secret scanning.
   • Non-provider patterns. To learn more about scanning for non-provider patterns, see Supported secret scanning patterns and Viewing and filtering alerts from secret scanning.
   • Push protection. To learn about push protection, see About push protection.

10. Optionally, under "Push protection", choose whether you want to assign bypass privileges to selected actors in your organization. By assigning bypass privileges, selected organization members can bypass push protection, and there is a review and approval process for all other contributors. For further guidance on how to configure this setting, see Enabling delegated bypass for push protection.

11. In the "Private vulnerability reporting" section of the security settings table, choose whether you want to enable, disable, or keep the existing settings for private vulnerability reporting. To learn about private vulnerability reporting, see Configuring private vulnerability reporting for a repository.

12. Optionally, in the "Policy" section, you can choose to automatically apply the security configuration to newly created repositories depending on their visibility. Select the None dropdown menu, then click Public, or Private and internal, or both.

    Note

    The default security configuration for an organization is only automatically applied to new repositories created in your organization. If a repository is transferred into your organization, you will still need to apply an appropriate security configuration to the repository manually.

13. Optionally, in the "Policy" section, you can enforce the configuration and block repository owners from changing features that are enabled or disabled by the configuration (features that are not set aren't enforced). Next to "Enforce configuration", select Enforce from the dropdown menu.

    Note

    If a user in your organization attempts to change the enablement status of a feature in an enforced configuration using the REST API, the API call will appear to succeed, but no enablement statuses will change.

    Some situations can break the enforcement of security configurations for a repository. For example, the enablement of code scanning will not apply to a repository if:

    • GitHub Actions is initially enabled on the repository, but is then disabled in the repository.
    • GitHub Actions required by code scanning configurations are not available in the repository.
    • The definition for which languages should not be analyzed using code scanning default setup is changed.

14. To finish creating your custom security configuration, click Save configuration.

Next steps

To apply your custom security configuration to repositories in your organization, see Applying a custom security configuration.

To learn how to edit your custom security configuration, see Editing a custom security configuration.