Skip to content

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

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

GitHub Enterprise and organization owners now have improved visibility into authentication activity via personal access token (classic), fine-grained personal access token (FGP), OAuth token, SSH key or deploy key. The audit log may now contain hashed renderings of the token or key used for authentication and the programmatic_access_type field describing the type of token/key used for authentication. Enterprise and organization owners can query by specific token or key to identify and track activity.

To learn more, read our documentation on identifying audit log events performed by an access token.

See more

GitHub Enterprise Cloud customers can now participate in a public beta displaying SAML single sign-on (SSO) identities for relevant users in audit log events.

SAML SSO gives organization and enterprise owners a way to control and secure access to resources like repositories, issues, and pull requests. Organization owners can invite GitHub users to join an organization backed by SAML SSO, allowing users to become members of the organization while retaining their existing identity and contributions on GitHub.

With the addition of SAML SSO identities in the audit log, organization and enterprise owners can easily link audit log activity with the user's corporate identity used to SSO into GitHub.com. This provides increased visibility into the identity of the user and enables logs from multiple systems to quickly and easily be linked using a common SAML identity.

To learn more, read our documentation about SAML SSO authentication data in our audit logs. Enterprise and organization owners can provide feedback at the logging SAML SSO authentication data for enterprise and org audit log events community discussion page.

See more

Now generally available, GitHub Enterprise Cloud customers with enterprise managed users (EMU) can integrate with Ping Federate as a formally supported SSO and SCIM identity provider. To get started, download the Ping Federate "GitHub EMU Connector 1.0" from the add-ons tab on the download page, under the "SaaS Connectors" heading. Add the connector to your Ping Federate installation and consult the Ping Federate documentation in addition to GitHub's SAML SSO and SCIM documentation for configuration.

The Ping Identity logo

The "GitHub EMU Connector" is maintained and supported by our partner, Ping Identity. Ping additionally maintains their own release notes for this connector.

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.

Starting today, you can now create your own custom rules to control how Dependabot auto-dismisses and reopens alerts – so you can focus on the alerts that matter, without worrying about the alerts that don’t.

What’s changing?

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, and – as rules apply to both future and current alerts – manage existing alerts in bulk.

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 an underlying, all-new, flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns. Today’s ship exposes our rules engine so you can create your own rules, too.

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.

What behaviors are supported?

Create or edit a custom rule

Today’s ship covers support for auto-dismissing alerts indefinitely as well as snoozing alerts until patch. Auto-dismissing ensures all activity is easily visible and can be caught by existing reporting systems and workflows, while also ensuring that alerts can be reintroduced if metadata across the alert changes.

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.

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

In October 2022, we released a private beta adding linked SAML single sign-on (SSO) identities for relevant users to GitHub Enterprise audit log events.

We are expanding the private beta to now include linked identities within git events, making this information available across all relevant events.

Enterprise owners interested in participating in the private beta should reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. Once enabled, enterprise and organization owners can provide feedback at the logging SAML SSO authentication data for enterprise and org audit log events community discussion page.

See more

Public documentation of the SCIM API for Enterprise Managed Users (EMU) is now available.

Administrators of EMU enterprises can use a token with the admin:enterprise scope to make GET requests from SCIM clients. With this read access, you can directly reconcile GitHub's understanding of SCIM-defined users and groups with your federated identity groups for auditing purposes.

Write requests to these APIs are possible through our published IdP applications, or through a new private beta that offers direct API access.

To get write access to these APIs in beta, register your interest here.

See more

Enterprise Managed User namespace repositories were previously able to use GitHub-hosted Actions runners outside of the owning enterprise's entitlements. This was not an intentional configuration. Today we have disabled the ability for EMU user namespace repositories to use GitHub-hosted runners.

For customers using inner source workflows we recommend forking from an organization owned repository into your user namespace. You may then open a pull request back to the upstream repository and actions workflows will run as usual within the context of that organization and enterprise.

Learn more about enabling private repositories to run actions workflows from forks.

See more

GitHub Enterprise Server 3.10 is generally available

GitHub Enterprise Server 3.10 gives customers more control over how their instance is used and run. Here are a few highlights:

  • GitHub Projects is generally available, with additions that help teams manage large projects
  • Always deploy safely, with custom deployment protection rules for GitHub Actions and new policy control over runners
  • Start finding vulnerabilities in all your repositories, in just a few clicks with a new default setup experience for GitHub Advanced Security code scanning, and track security coverage and risk at the enterprise level
  • Fine-grained personal access tokens (PATs) bring granular control to PATs
  • Branch protections meet more compliance needs with more control over merge policies
  • Backup instances faster and more incrementally, for more confident operations

If you are upgrading from Enterprise Server 3.8 then this release also includes an upgrade from MySQL 5.7 to 8, which will increase I/O utilization. Please read this page for more details on this increase and how to mitigate it if you see an unacceptable degradation of performance on your instance.

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

See more

Earlier this year, we announced the roll out of enterprise accounts to all GitHub Enterprise customers. Enterprise accounts enable enterprise customers to manage and scale their users and Organizations through one administrative portal.

As part of this transition, customers upgrading from a Free or Teams plan Organization to the Enterprise plan now have an enterprise account.

If you are currently on GitHub Enterprise with a single organziation, a free upgrade flow will soon be available on your Organization's Billing settings page, for you to transition into an enterprise account. Stay tuned for the announcement on when that is live.

To learn more, read our documentation about enterprise accounts or about upgrading your account's plan.

See more

The administrator account (ending in _admin) of Enterprise Managed User enterprises is now required to enter sudo mode before taking sensitive actions. As with standard user accounts, the administrator must provide their password or a second factor credential to enter sudo mode.

Sudo mode is a GitHub security feature that validates the user's session before they perform a sensitive action, like creating a personal access token, deleting an organization, or updating their credentials.

Until now this mode was disabled for all Enterprise Managed Users (EMUs), as they had no credentials on GitHub.com and therefore could not provide one for the sudo mode prompt. As a result, EMU accounts are able to take sensitive actions without being asked for a credential. However, the admin for the EMU enterprise does have credentials on GitHub.com and will now be asked for them before taking sensitive actions.

For more information about sudo mode, see "Sudo mode". To learn more about Enterprise Managed Users, see "About Enterprise Managed Users".

See more

The GitHub Enterprise Server 3.10 release candidate is here

GitHub Enterprise Server 3.10 gives customers more control over how their instance is used and run. Here are a few highlights:

  • Code Scanning configuration can be customized per repository, allowing repository owners to decide which languages to analyze by default.
  • Fine-grained personal access tokens (PATs) are now available as a public beta on Enterprise Server, giving developers and administrators granular control over the permissions and repository access granted to a PAT.
  • Assess security risk and coverage data across all organizations in an enterprise via the Code Security tab.
  • Define who can merge pull requests, and how they are merged, to make it easier for you to meet your compliance and security goals.
  • Reduce data transfer required to backup your Enterprise Server by utilizing incremental backups of MySQL data in backup-utils v3.10.0.
  • GitHub Projects is now generally available in Enterprise Server.

If you are upgrading from Enterprise Server 3.8 then this release also includes an upgrade from MySQL 5.7 to 8, which will increase I/O utilization. Please read this page for more details on this increase and how to mitigate it if you see an unacceptable degradation of performance on your instance.

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

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

See more