Roadmap

This isn't a proper roadmap at the moment but does detail some initial areas to be tackled. This will evolve into a more prioritized Roadmap as scope and priority is established.

Group Membership

If you have a well-designed OIDC or SAML implementation and an Enterprise account then you can manage group membership fairly easily as long as that's viable for your organization.

Many organizations do not have this, and even if you do engineering needs can change quickly. It is also often adventagious to have groups that you use for purposes other than access to repositories such as rulesets or even just easily tagging or notifying subsets of GitHub users. If membership is inconsequential you can allow that to be managed by trusted individuals - but if it's used in rules you need a way to have process around it.

A good example here is if you have a stream-aligned teams approach, or have self-organized teams. Reorganizing all of your teams in your IDP every time these structures change is unsustainable for many organizations. There is a need for enabling some self-organization in this space with good controls.

Access Control

When team structures change it can be a significant challenge to ensure consistent application of access controls across an organization, but it can get really dicey when it comes to enterprises. GitHub's recent addition of Enterprise teams offers some significant benefits for cross-organization access in larger enterprise deployments that need it -- but introduces new challenges for managing what those teams can access in a given organization.

Ideally there would be ways to do something similar to what you can with rulesets -- where a given group can access repositories based on a set of policy rules connected to attributes of the repository. This is not available today in GitHub itself, but could theoretically be implemented by an external tool.

Rulesets

GitHub has made some strides around improving the way rulesets can be leveraged that make maintaining consistent expectations across an organization much easier. Common minimal policies can be set and applied to repositories based on attributes that is far better than the Branch rules were.

However in an enterprise context these have to be applied in each organization. For small single organization enterprises this is straightforward but can quickly become a thorny problem in larger deployments. Even if these types of rulesets could be configured at the enterprise level that would only work for repository attributes that are consistent. For example, some repository attributes that come into play might be based on properties that would have different possible values depending on the organization. The groups you reference in the ruleset, or file paths, might be different per organization despite the policy outcomes being the same. These will likely always need to be managed per organization.

It should be possible to define the core policy rule, and then apply it consistently across organizations while making the necessary adjustments. Consider a scenario where each organizations has custom attribute for the applications in that organization. That organization has a separate GitHub team comprised of the experts for each of those. The administrators configure each repository to identify the product using that custom property.

An administrator should then be able to create a ruleset template that requires an approving review from an appropriate team of maintainers for that product. The template defines the specifics of the rule, and references the property. Policy then maps the specifics:

org1:
  productA: teamA
  productB: teamB

org2:
  productC: teamC
  productD: teamD

When the policy is enforced, for each organization it creates a ruleset for each product in that organization that has a mapped team, requiring an approving review.

Testing and Verification

As the complexity of access controls, rules, etc grows it can also be more challenging to ensure your outcomes are correct. There are some helpers available from GitHub for understanding how your rulesets apply to a given repository, as well as insights into how rules have been applied to recent actions -- but this is a manual undertaking that is valuable primarily for iterating on rules.

It would be valuable to be able to test your implementation against a set of goals. Firstly, a way to express concepts as policy that could be validated. The natural language version might look something like these examples:

• "All repositories with a custom property indicating they are in-scope for ISO27001 must require pull-requests, must require at least N approving reviews, and must have at least one required check defined."
• "No repository with a custom property indicating active production may grant the following permissions to users other than A, B and C"
• "All repositories must prevent force pushes"

Policy runs could then iterate through these on a schedule, or after a change, to validate that this is true -- detecting where some overlap of policies or incorrect scoping has caused an unintended outcome.

Second, there should be a way to define a number of tests. A separate organization and/or separate repositories that reflect common practices would be used to execute a defined set of actions (commits, pushes, merges, etc) to test specific scenarios. This would allow for evaluating the impact of changes, but also to deal with complex edge-cases that might be hard to test without actually creating the event.