Recent improvements to enterprise repository policy, rulesets, and custom properties now ensure a more consistent, intuitive experience, making it easier for you to navigate and accomplish your tasks efficiently.
Enterprise repository policy page has been renamed to “Member privileges” to align the page title with the current URL path, API endpoints and the corresponding organization setting.
Repository rulesets now support enterprise owners as a bypass actor, ensuring your most privileged roles across your enterprise can bypass rulesets.
Custom repository properties now have an “additional options” section for administrators to easily manage properties.
You can now restrict pushes into your private and internal repositories and their forks, with push rules – a new type of ruleset. Push rules enable you to limit updates to sensitive files like actions workflows, and help to enforce code hygiene by keeping unwanted objects out of your repositories.
In addition, organization owners can now allow repository property values to be set when repositories are created. This ensures appropriate rules are enforced from the moment of creation and improves discoverability of new repositories.
Push Rules
Organization and repository owners can now configure rules that govern what changes can be pushed to their repository, by attributes of the files changed – including their paths, extensions and sizes.
Available push rules
Restrict file paths
This rule allows you to define files or file paths that cannot be pushed to. An example of when you might use this is if you wanted to limit changes to your Actions workflows in .github/workflows/**/*
Restrict file path length
You can limit the path length of folder and file names.
Restrict file extensions
You can keep binaries out of your repositories using this rule. By adding a list of extensions, you can exclude exejar and more from entering the repository.
Restrict file size
Limit the size of files allowed to be pushed. Note: current GitHub limits are still enforced.
Push rules are available on GitHub Team plans for private repositories, and coverage extends to not just the repository, but also all forks of that repository. Additionally, GitHub Enterprise Cloud customers can set push rules on internal repositories and across organizations with custom repository properties. You can also access rule insights to see how push rules are applied across your repositories.
Additional details
Delegated bypass for push rules, currently in beta, allows your development teams to stay compliant with internal policies and keep a clean git history. Developers can easily request exceptions to push rules, that are reviewed and audited all within GitHub.
To ensure best performance push rules are designed to handle up to 1000 reference updates for branches and tags per push.
Organization owners can now allow their users to set custom properties during repository creation. Previously, this was only available to repository administrators or those with permissions to edit custom repository properties. By selecting Allow repository actors to set this property for your custom property, you can ensure repositories have properties attached from the start.
We’re excited to bring an updated repository list view experience and the ruleset merge queue rule to general availability, as well as an update to the status check and workflow rules.
Finding repositories in your organization is now easier
With the introduction of custom properties earlier this year we wanted to make it easier to find repositories across your organization. With the new organization repository view and advanced filtering you find repositories based on common parameters like visibility and language, but also custom properties, size, license and a host of additional values.
Repository Rules updates
Repository ruleset merge queue rule is now generally available
In addition to being able to manage your merge queue via rules, you can now see all the pull requests that merged in the same group along with the checks needed for the queue with rule insights.
Avoid required status checks and required workflows when creating branches
Applying status check and actions workflow rules to newly created branches has been a point of friction in rulesets. When creating a new branch will fail unless you add bypass actors or create an intermediate unprotected branch. To alleviate this friction there is a new option available prevent checks and workflows from running on new branches.
Multi select allows a repo to have more than one value for a property defined. Now a repository can have a property that defines a compliance requirement with values for FedRamp and SOC2, for example.
True/False allows you to set whether a given property is true or false for a given repository.
Target rulesets by repository visibility and more
In addition to targeting repositories with the custom properties you’ve created, we’ve now extended property targeting to include the ability to target by:
– Visibility: public, private, or internal
– Fork: true, false
– Language: select primary repository language.
Previously to bypass push rules you had to be on the bypass list to push restricted content. Now with delegated bypass, contributors can propose bypassing a push rule and members of the bypass list can review those bypass requests to allow or deny the content.
Starting today, we will begin work towards the sunset of tag protections, with a full deprecation planned for August 30, 2024. See below for a full sunset timeline. You can migrate existing tag protections with the import to ruleset feature.
We launched repository rules last year to meet the needs of tag protection rules, while also scaling support to provide new functionalities like org-wide rules, granular restrictions for creating, reading, and updating events, and a more granular bypass model that does not require repository administrator permissions. As we such, we will sunset tag protections in favor of our ongoing investment in the repository rulesets platform.
You can import existing tag protection rules today with the existing migration feature. If no action is taken before the sunset date, GitHub will migrate all existing tag protections into a corresponding ruleset.
When are changes happening?
GitHub.com Timeline
May 30 : Repositories without tag protection rules will no longer be able to add new protection rules via the GitHub.com UI
July 24 through August 14 : A series of API brownouts will be run, see below for additional details on dates and times.
August 30, 2024: All tag protection rules will be migrated to a new tag ruleset. All REST and GraphQL API endpoints will be deprecated
GitHub.com API Timeline
May 30: API responses will include a deprecation notice
July 24: 1 hour API brownout
August 7: 8 hour API brownout
August 14: 24 hour API brownout
August 30: The tag protection rule API will begin responding with NULL data
The tag protection rules API will be deprecated in the next calendar version
GitHub Enterprise Server Timeline
Version 3.14: Tag protection rules will be marked for deprecation with an in-product banner and API responses will include a deprecation notice
Version 3.15: No changes will be made
Version 3.16: Tag protection rules will be migrated to a ruleset and the tag protection rule feature will no longer be available
Deploy keys are now supported as a bypass actor in repository rules, allowing additional granularity for your automations. Previously for deploy keys to bypass a ruleset the Repository Administrator role was required.
Webhooks and GitHub Actions will no longer be run for any push that includes over 5000 branches. Clients will now receive the following warning indicating they have reached this limit. remote: warning: No webhooks or actions will be performed for this push as it updates more than 5000 branches.
The code scanning option for repository rules is now available in public beta. Code scanning users can now create a dedicated code scanning rule to block pull request merges, instead of relying on status checks.
Making it easier than ever to prevent new vulnerabilities from being introduced into your code base.
Configuring code scanning merge protection with rulesets can be done at the repository or organization levels and for repositories configured with either default setup or advanced setup. Additionally you can also use the REST API to set merge protection with rulesets.
You can use rulesets to prevent pull requests from being merged when one of the following conditions is met:
– A required tool found a code scanning alert of a severity that is defined in a ruleset.
– A required code scanning tool’s analysis is still in progress.
– A required code scanning tool is not configured for the repository.
Note: Merge protection with rulesets is not related to status checks. If the code scanning rule is configured for the repository in parallel with an alert threshold and the merge protection rule for the code scanning check run, the two functionalities will work simultaneously. For more information about status checks, see about status checks.
Say goodbye to unwanted files cluttering your repos, like *.jar or *.so. And limit who can make updates to sensitive files like your Actions workflows with the public beta of push rules. 🎉
You can now enable a new type of ruleset that allows you to control pushes to repositories based on file extensions, file path lengths, file and folder paths and file sizes. Push rules don’t require any branch targeting as they apply to every push to the repository, and also apply to all forks of the repo to ensure all pushes to the repository network are protected.
Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.
Configuring merge queue in your repo rulesets is now available in public beta!
Merge queue & rule insights
Until now, rule insights would only list one pull request as merged even when multiple pull requests were merged by the queue at the same time. Also in this beta, each pull request in a merge queue will have an individual record in rule insights, linked to the actor that added the pull request to the merge queue.
Within the additional data of a rule insight dialog you can now see all the pull requests that merged in the same group along with the checks needed for the queue.
Limitations
The merge queue rule cannot be configured via an API. This feature will be available in the near future.
Merge Queue for branch protections and repository rules do not support wildcard patterns
Not supported in organization rulesets.
Multiple merge queues configured against a single branch will prevent merging.
We’re excited to announce the general availability of Repository Custom Properties, a major enhancement to how repositories are managed and classified across GitHub organizations.
Properties offer a flexible way to add meaningful metadata to your repositories that simplifies repository classification, enhances discoverability, and seamlessly integrates with rulesets.
Check out this video from our own Jon Peck for a walk through of a common scenario.
Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale. We've heard your feedback, which is helping us improve throughout this beta period.
Starting today, you can now create Dependabot auto-triage rules using CVE IDs or GHSA IDs to target subsets of alerts.
Auto-triage rules are a powerful tool to help you reduce alert and pull request fatigue substantially, while better managing your alerts at scale.
What's changing?
Starting today, you can define your own rules to control and enforce Dependabot behaviors across organizations and individual repositories.
You can now define which alerts receive pull requests to resolve them, rather than targeting all alerts.
You can enable and enforce those Dependabot security update rules across organizations, in addition to individual repositories.
You can enable, disable, or enforce how GitHub default rulesets are applied across your organization.
You can also now enable and enforce custom auto-dismiss (alert ignore and snooze) rules across organizations.
Auto-triage rules are defined by alert targeting criteria, the behaviors you'd like Dependabot to automatically perform for these alerts, as well as how you want the rule to be enabled or enforced across your organization.
Alerts can be targeted based on metadata related to the advisory, dependency, and how it's used. For this public beta, currently supported attributes at the organization level are: severity, scope, package-name, cwe, and ecosystem. At the repository level, you can also target specific manifest files.
For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, choose which alerts open Dependabot security updates, and – as rules apply to both future and current alerts – manage existing alerts in bulk.
This feature is free for open source (all public repositories) and available for use in private repositories through GitHub Advanced Security.
Frequently asked questions
Why is GitHub making this change?
At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.
That’s why, moving forward, we’re releasing a series of ships powered by a flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns and has helped millions of repositories filter out false positive alerts. Today’s ship exposes our rules engine at the organization and repository levels, so you can create and enforce custom rules, too.
How do I create a rule?
From your organization or repository settings page, admins and security managers can navigate to Code security and analysis settings. Under Dependabot, select Dependabot rules to add or modify your own custom rules or modify GitHub presets.
How do I enforce rules for my organization?
At the organization level, rules can be set with the following states.
State
Description
Enabled
This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Any individual repository can choose to disable the rule.
Enforced
This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Individual repositories cannot override this setting.
Disabled
This rule will be disabled and hidden across your organization.
At the repository level, rules can be set to enabled or disabled if they're not enforced.
Which criteria are supported?
Rules can be created across the following attributes:
Attribute
Description
severity
Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical.
scope
Scope of the dependency: development (devDependency) or runtime (production).
package-name
Packages, listed by package name.
cwe
CWEs, listed by CWE ID.
ecosystem
Ecosystems, listed by ecosystem name.
manifest
Manifest files, listed by manifest path.
Note: manifest is only available at the repository level.
How do I control how Dependabot automatically generates pull requests for alerts?
You can use the alert criteria (above) to indicate which alerts Dependabot will attempt to open pull requests to resolve. To use auto-triage rules with Dependabot updates, you must disable Dependabot's option to always open pull requests to resolve all open alerts from the repository Code security and analysis settings.
How do I control how Dependabot automatically closes or reopens alerts?
Similar to Dependabot pull request rules, you can control how Dependabot filters out false postives (with dismiss indefinitely) or snoozes alerts (with dismiss until patch).
How many custom rules can I create?
At the time of public beta, you can create 20 rules per organization and 10 rules for each repository. Want more? Let us know!
How will this activity be reported?
Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.
Who can create and modify rules?
Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories and at the organization level.
How do I reopen an automatically dismissed alert?
Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).
What happens if alert metadata changes or advisory information is withdrawn?
Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.
We’ve now made migrating existing tag protection rules into repository rules easy. With a few clicks, you can take multiple tag protection rules and turn them into a single ruleset or turn each rule into corresponding rulesets for more granular control.
Tag protection rules control who can create, update, and delete tags. Moving your tag protections to repository rules allows you to require status checks, deployments to pass, and signed commits. You also get the rest of the repository rules power, with configurable enforcement status, bypass lists, and flexible targeting.
For GitHub Enterprise Cloud customers, you can pair metadata restrictions with your tag protection to manage commit messages and control the names of your tags.
Need to roll back a change to a ruleset? How about easily moving your ruleset around?
With today’s public beta you now have new tools to manage your ruleset.
Import and Export
Rulesets are now easier to share and reuse, with the ability to import and export rulesets as JSON files. Giving you the ability to share rules across repositories and organizations or to share your favorite rules with the community. Which is what we’re doing. The ruleset-recipes repository is home to a collection of pre-baked rulesets covering a number of popular scenarios ready for you to use.
History
If you are a repository or organization administrator of GitHub Enterprise cloud, we’re adding a history experience so you can track changes and revert rulesets. Now, it’s easy in the ruleset UI to see who changed a ruleset, when it happened, and what changed. Then, quickly get back to a known good state.
Only changes made to a ruleset after the public beta are included in ruleset history.
Starting today, organization administrators can create custom properties to enrich repositories with valuable information. Using these properties, you can dynamically target repository rules to apply protections on just your production repositories or to a business unit or any other way you want to classify your repositories.
Only organization administrators can configure custom properties; you can be confident knowing that they are not accidentally removed by a repository administrator, ensuring your branch and tag rules are consistently applied. Property values can also be automatically applied with default values at repository creation, ensuring every new repository is classified, and its first commit is protected.
Today, organization administrators can only use custom properties for dynamically targeting rulesets. But soon, you can use properties to filter and search in an updated repository list and other experiences across GitHub.
