enterprise

Subscribe to all “enterprise” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

Introducing support for multiple GitHub accounts on a single host within the CLI! Log in with your work and personal accounts to manage your projects, wherever they're happening.

To add multiple accounts in the CLI, use the gh auth login command just as before. Now, instead of replacing your previous account, you will see the addition of a new account under gh auth status. This account will be marked as active, to indicate that gh will use it when communicating with GitHub. Run gh auth switch to change the active account, or gh auth logout to remove an account. Further details can be found in the v2.40.0 release notes.

Install or update the GitHub CLI today from your preferred source.

See more

In early November we announced a set of changes to improve troubleshooting SCIM activity at scale for enterprise managed users. Today, we are making each of those changes generally available. No updates were required during the public beta period. The following restates the beta changes that are now GA.

Enterprise audit log fields:

  • New field external_group.update_display_name: Our logs will now capture and report any changes made to an external group's display name.
  • New field external_group.add_member: When a team member is added to an external group, this action will be audit logged.
  • New field external_group.remove_member: When a team member is removed from an external group, this action will be audit logged.
  • Enhancements to external_group.update and external_identity.update to ensure consistency whenever an external group or identity is updated.

The SSO page for each user also now includes SCIM metadata for that user in addition to existing SAML metadata. Check out what's new by filling in this url https://github.com/enterprises/your-enterprise/people/username/sso with your enterprise and a valid username.

Team membership synchronization status checks GitHub's understanding of identity groups against the current members of linked teams. This allows us to flag mismatches for administrators related to license allocation or other concerns.

image

Learn more about external group audit log fields and troubleshooting EMU team memberships.

See more

GitHub Enterprise Server 3.11 is generally available

GitHub Enterprise Server 3.11 is now generally available.
With this version, customers have access to tools and features that provide a better understanding and visibility into the security of their code.

Highlights of this version include:

  • Scale your application security testing with code scanning's default setup, which now helps you to schedule weekly scans and deploy across your organization in just a few clicks.
  • The new Activity view makes viewing repository history much easier by showing activities like pushes, merges, force pushes, tag changes, and branch changes.
  • Prevent secret leaks with data-driven insights and new metrics on secret leak prevention in security overview.
  • A GitHub CLI extension for the Manage GitHub Enterprise Server API to interact with your GitHub Enterprise Server instance via the gh command-line interface.

To learn more about GitHub Enterprise Server 3.11 read the release notes,
or download it now.
If you have any feedback or questions, please contact our Support team.

See more

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.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more

Organization owners can now create and assign custom organization roles, which grant members and teams specific sets of privileges within the organization. Like custom repository roles, organization roles are made up of one or more fine-grained permissions, such as “read audit logs” or “manage repository rulesets”, and apply to the organization itself rather than the repository. This feature is available in all Enterprise Cloud organizations and will come to GitHub Enterprise Server by version 3.13.

A screenshot of the role creation page, with a new role called "Auditor" that grants access to just the audit log permission.

Today, organization custom roles supports 10 permissions:

Roles can be assigned by an organization owner only, to prevent accidental escalation of privileges, and can be assigned to users and teams. Multiple organization roles can be assigned directly to a user or team. Users and teams inherit roles from the teams they are a part of.

A screenshot showing a user that's assigned to two different roles.

More organization permissions will be built over time, similar to how repository permissions were added as well. If you have a specific permission you’d like to see added please get in touch with your account team or let us know in the discussion below. Everything you can see in the organization settings menu is an option, and we’ll be working with teams across GitHub to get those permissions created.

To learn more about custom organization roles, see “About custom organization roles“, and for the REST APIs to manage and assign these roles programmatically see “Organization roles“. For feedback and suggestions for organization permissions, please join the discussion within GitHub Community.

See more

The GitHub Enterprise Server 3.11 release candidate is here

GitHub Enterprise Server 3.11 gives customers more visibility of their instance. Here are some highlights:

  • Code scanning's default setup now does even more to protect your code, by performing scans on a weekly scheudule (in addition to scanning pushes and pull requests) and allowing you to include Swift in your analysis.
  • View repository history using the new Activity view, to see repository activity like pushes, merges, force pushes, tag changes, and branch changes, and associate them with commits and users.
  • The value of secret scanning is now much more clear thanks to push protection metrics that are available in an organization's security overview pages.
  • A GitHub CLI extension for the Manage GitHub Enterprise Server API allows customers to interact with their GitHub Enterprise Server instance via the gh command-line interface.

Release Candidates are a way for you to try the latest features early, and they help us gather feedback to
ensure the release works in your environment. They should be tested on non-production environments.
Read more about the release candidate process.

Read more about GitHub Enterprise Server 3.11 in the release notes,
or download the release candidate now.
If you have any feedback or questions, please contact our Support team.

See more

GitHub Enterprise Cloud customers that use Enterprise Managed Users (EMUs) can now participate in a public beta for a new user role that has restricted visibility of internal repositories. The guest collaborator role is defined via SCIM and assigned to users by the identity provider. Guest collaborators helps companies who work with contractors and other short-term partners in a flexible and managed fashion on specific projects, while also sharing code and ideas without restrictions amongst full enterprise members. When a guest collaborator is added to an organization they will only receive access to internal visibility repositories within that organization.

add a guest collaborator

Learn more about guest collaborators.

See more

GitHub Enterprise Cloud Enterprise Managed User customers can join a limited beta waitlist to enable individual repository access for users within their enterprise without granting organization membership. This is useful in cases where you intend to limit repository access for a specific user to the least number of repositories and combines well with features like guest collaborators to execute a least privilege access strategy. Any enterprise member is eligible to be added to an organization-owned repository and will result in use of a seat license if the user is not already a member of any other organization.

Learn more about EMU repository access for non organization members and join the waitlist!

See more

Banner announcing the new overview dashboard states prioritization made simple with security insights

A new asset in security management is now available for GitHub enterprise users. Reinforcing the “shift left” philosophy, this feature is designed to integrate security into the heart of the development lifecycle, empowering your organization to proactively identify and address vulnerabilities.

Key advantages

Historical context

By comparing historical and current data, you can visibly track improvements in your security landscape and demonstrate the value of security investments.

Reporting period drop-down menu for the new overview dashboard

Customized focus

Sharpen your focus with filters that dissect your security data by teams, repositories, or any categorization that aligns with your goals. Whether it’s tracking team performance or monitoring metrics across a core group of repositories with the repository topic filter, there’s a plethora of options available to meet your needs.

Drop-down of filters for the new overview dashboard

Prioritization made simple

With clear insights into severity and net resolve rate—security’s version of developer velocity—the dashboard shows you if your resources are aligned with the most severe threats and if remediation speed is in harmony with security demands.

Security alerts trends graph grouped by severity and the net resolve rate tile from the new overview dashboard

Strategic alignment

Gain a strategic perspective with the Repositories “Top 10” list, which shows you repositories with the largest number of open alert counts, to understand where to direct your attention first.

Repositories top 10 list from the new overview dashboard

Shift left

The dashboard, which is accessible by everyone in the organization, helps you drive best security practices by understanding potential issues as early as possible, reducing risk and workload down the line.

New overview dashboard

This overview dashboard is now available as a beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.

Learn more about the new overview dashboard and send us your feedback

See more

GitHub.com now remembers multiple accounts in your browser. You can find the account switcher in your profile picture context menu, letting you more easily switch between user accounts without re-entering your credentials.

image

The account switcher helps developers alternate between Enterprise Managed User accounts provided by an employer and personal accounts for use with personal projects and open source contributions. It also helps administrators manage service accounts they use for automation and integration purposes.

Because these accounts often have significantly different privileges, there's never any mixing of user permissions between saved accounts. When you visit a page that your current account can't access, you'll see a prompt to switch accounts if you have more than one signed in.

When you switch accounts, you won't need to sign in again or perform 2FA unless the account session has expired. Session expiration occurs after two weeks without activity. SAML/OIDC SSO authorization is also saved for sessions, but often expires every 1 or 24 hours, and may need to be done again before you can access your organization resources.

To learn more, see "Switching between accounts".

See more

GitHub Enterprise Cloud customers with Enterprise Managed Users (EMU) now have access to additional administrative capabilities for SCIM information. Troubleshooting user management at scale can take time and effort. To make this easier on administrators, we have added several new audit log fields, external identity metadata, and a new team membership synchronization status. The audit log field updates include the following:

  • New field external_group.update_display_name: Our logs will now capture and report any changes made to an external group’s display name.
  • New field external_group.add_member: When a team member is added to an external group, this action will be audit logged.
  • New field external_group.remove_member: When a team member is removed from an external group, this action will be audit logged.
  • Enhancements to external_group.update and external_identity.update to ensure consistency whenever an external group or identity is updated.

The SSO page for each user also now includes SCIM metadata for that user in addition to existing SAML metadata. Check out what’s new by filling in this url https://github.com/enterprises/your-enterprise/people/username/sso with your enterprise and a valid username.

Team membership synchronization status checks GitHub’s understanding of identity groups against the current members of linked teams. This allows us to flag mismatches for administrators related to license allocation or other concerns.

image

Learn more about external group audit log fields and troubleshooting EMU team memberships.

See more

Users who are not part of the mandatory 2FA program will now be added to it within 24 hours of creating their first release. In August we expanded the 2FA requirement to include most GitHub.com users that had created a release. Those groups have now completed their 2FA enrollment, but additional developers have since created their first release. They will be added to the 2FA program in the coming days, as will more users over time as they create releases.

Enterprise or organization administrators can learn more about their users' current 2FA requirements by visiting the People page for their enterprise or organization.

To learn more about the 2FA program, see our May 2023 blog post, as well as the “About the mandatory 2FA program” documentation.

See more

We are excited to announce the beta release of Copilot in GitHub Support, a faster way to find answers to your GitHub related questions! In August, we launched the Alpha to a limited number of randomly selected GitHub Enterprise Cloud customers. We have made lots of improvements to the experience since and are excited to welcome more customers into the new experience. Copilot in GitHub Support is now trained on the latest GitHub Enterprise Server documentation in addition to GitHub Enterprise Cloud documentation it was previously trained on.

Initially, we’re offering the Copilot experience to a limited number of randomly selected GitHub Enterprise customers. We hope to continue rolling out the experience to a wider audience over the coming months.

During the beta, GitHub will be reviewing answers provided and collecting feedback from participating customers to improve the accuracy.

Copilot in GitHub Support is part of our ongoing effort to make GitHub the best place for all developers to collaborate, innovate, and ship great software. We believe that Copilot in GitHub Support will enhance your experience and productivity.

We look forward to hearing from you and learning from your feedback.

See more

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.

Dependabot auto-triage rules list

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.

Create a stacked Dependabot auto-triage ruleset

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?

Enforce a Dependabot auto-triage rule

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.

Target alerts based on attributes

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.

How do I learn more?

How do I provide feedback?

Let us know what you think by providing feedback — we’re listening!

See more