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

Code scanning now supports using CodeQL packs on GitHub.com and GHES

CodeQL comes with a built-in package manager that helps you share and manage custom queries. Last year, we announced the public beta of CodeQL packaging — including direct integration into GitHub code scanning. This makes it easier to roll out custom queries to your repositories and gives you full control over exactly which queries are run.

This functionality will soon be released for users of GitHub Enterprise Server (GHES): it will be available with GHES 3.7. This release also includes support for using packs that are published to GitHub Container Registries (GHCR) hosted on GHES.

How do I use CodeQL query packs in code scanning?

To use CodeQL query packs in code scanning, specify a with: packs: entry in the uses: github/codeql-action/init@v2 section of your code scanning workflow. By default code scanning downloads packs the from GHCR on GitHub.com, so if you want to run one of the standard CodeQL query packs or any other public CodeQL query pack, then simply include the pack scope/name and version requirements here. You can find the full documentation here.

If you want to run packs from the GHCR on GHES, then you need to tell code scanning how to access and authenticate to the appropriate registry. For an example of how to do this in your code scanning workflow, see Downloading CodeQL packs from GitHub Enterprise Server in the GitHub documentation.

How do I publish my own CodeQL packs?

You can publish you own CodeQL packs using the CodeQL CLI. By default, the CodeQL CLI publishes packs to the GHCR on GitHub.com. If you want to publish packs to the GHCR associated with your instance of GHES, you need to tell the CodeQL CLI how to access and authenticate to the registry you want to work with. For a full example of how to specify these details, see Working with CodeQL packs on GitHub Enterprise Server in the CodeQL CLI documentation.

Where can I find more information about CodeQL packaging and code scanning?

This changelog post only provides a brief summary of how you can use CodeQL packs in code scanning. For more information, see:

See more

Private beta introducing innersource restrictions for Enterprise Managed Users

GitHub Enterprise Cloud customers that use Enterprise Managed Users (EMUs) can now participate in a private beta for a new user role that has restricted visibility of internal repositories. This role helps companies to work with contractors and collaborators in a flexible and managed fashion on specific projects, while also sharing code and ideas without restrictions amongst employees.

Users are granted this new role by being marked as "Restricted Users" in your identity provider. Enterprise members granted this role can be added to Organizations as members, and added to Organization teams – but they won't be able to see internal repositories in other Organizations unless explicitly added to those repositories one-by-one.

If you would like to enroll your EMU enterprise in this private beta, please reach out to your account team or contact our sales team for more details.

See more

Display SAML SSO authentication data in audit log – Private Beta

GitHub Enterprise Cloud customers can now participate in a private 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 not only provides increased visibility into the identity of the user, but also enables logs from multiple systems to quickly and easily be linked using a common SAML identity.

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

The GitHub Enterprise Server 3.7 Release Candidate is available

The GitHub Enterprise Server 3.7 release candidate is here

GitHub Enterprise Server 3.7 brings new capabilities to help companies build and deliver secure software, more quickly. With over 70 new features, here are a few highlights.

  • It's easier to deploy GitHub Actions, securely, at scale. Teams looking to standardise their workflows with reusable workflows will benefit from the ability to nest reusable workflows in one another, and build matrixing into reusable workflows. What's more, Actions now supports Google Cloud Storage and security teams will love our enhancements to the OIDC connection patterns for Actions to support cloud deployments at scale
  • Security teams now have a single view of their code security posture. The Security Overview page, an at-a-glance view of your code security alerts and risk, is now available to all customers. And to ensure all repositories are covered by your company's policies, administrators can now restrict new repositories to Organizations only.
  • Forking is clearer and simpler, especially for companies adopting innersource. Developers will benefit from a whole host of enhancements that make working with forks easier, including the ability to fork within an organization and fork internal repositories.
  • Code scanning alerts for GitHub Advanced Security customers are now more collaborative and relevant, with alerts now appearing in pull requests. And, you can now improve Dependabot alert and update coverage by submitting dependencies directly to the Dependency graph via an API.

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.7 in the release notes, or download the release candidate now. If you have any feedback or questions, please contact our Support team.

See more

Introducing fine-grained personal access tokens

Today we're enabling fine-grained personal access tokens (PATs) in Public Beta for all user accounts on GitHub.com. This new type of token gives developers and resource owners more control and visibility around token access. Learn more about this new token type in today's blog post.

These new tokens offer many more permissions to choose from, must be scoped to a specific organization or account, and must expire. Organization owners will also find new tools to manage tokens that can access their organization, and can require approval of those tokens before they may be used.

PATsv2-light2

You can try out the new token creation flow, and provide feedback in our community discussion.

For more information, see "Creating a fine-grained personal access token".

See more

New enterprise policies for code security

Enterprise owners can now configure whether repository administrators can enable or disable Dependabot alerts.

If you are owner of an enterprise with GitHub Advanced Security, you can now also set policies to allow or disallow repository administrators access to enablement for:

  • GitHub Advanced Security
  • Secret scanning

image

Learn more about enterprise policies for code security and send us your feedback

See more

Audit Log Streaming to Datadog is generally available

GitHub Enterprise Cloud customers can now stream their audit log to a Datadog endpoint. Enterprise owners need to be able to use the right tools for their job, whether that be short-term investigation or longer-term threat analysis and prevention. With audit log streaming to Datadog, customers can be assured that:

  • no audit log event will be lost,
  • they may satisfy longer-term data retention goals, and
  • they can analyze GitHub's audit log data using Datadog products.

For GitHub Enterprise Server customers, this feature is planned to come to GHES 3.8.

For additional information, read our documentation about setting up streaming to Datadog.
“

See more

Display Authentication Token Data in your Enterprise Audit Log – Beta

GitHub Enterprise Cloud customers can now participate in a private beta enabling authentication token data to display for audit log events. In doing so, enterprise owners will be able to query their audit logs for activity associated with specific authentication tokens. With the introduction of this feature, enterprise owners will be better equipped to detect and trace activity associated with corrupt authentication tokens, which have the potential to provide threat actors access to sensitive private assets.

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 owners can find guidance and provide feedback at the displaying authentication token data in enterprise audit log events community discussion..

See more

Stream audit log to AWS S3 with OpenID Connect (OIDC)

The functionality for GitHub Enterprise Cloud customers to configure audit log streaming to AWS S3 with OpenID Connect (OIDC) is now generally available. Audit log streaming configured with OIDC eliminates storage of long-lived cloud secrets on GitHub by using short-lived tokens exchanged via REST/JSON message flows for authentication.

For additional information, please read about setting up audit log streaming to AWS S3 with OpenID Connect.

See more

Enhancements to Audit Log Exports

GitHub's audit log allows admins to quickly review the actions performed by members of their Enterprise. It includes details such as who performed the action, what the action was, and when it was performed. GitHub's audit log provides users with the ability to export audit log activity for your enterprise as a JSON or CSV file download. Moving forward, customers can expect to see the following enhancements to their audit log exports:

  • Audit log exports will contain the same fields as the REST API and audit log streaming, bringing consistency across these three audit log consumption modalities.
  • actions events will be present in audit log exports.
  • For Enterprises who have enabled the feature to display IP addresses in their enterprise audit logs, IP addresses will be present in audit log exports.
  • Audit log exports will be delivered as a compressed file.
  • Audit log JSON exports will be formatted with each line of the JSON file contains a single event, rather than a single JSON document with an array containing all the events as array elements.

This feature will be gradually enabled for an increasing percentage of GitHub Enterprise Cloud customers with a goal of 100% enablement by October 28, 2022. Should you encounter a problem with your audit log exports, please reach out to GitHub Support for assistance.

See more

Enterprise members CSV Report Now Available in Public Beta

GitHub Enterprise Cloud enterprise owners may now download an enterprise members CSV report, which is now available as a public beta. This new CSV report provides an extensive list of members associated with their Enterprise Cloud environment, including members synced from a GitHub Enterprise Server instance. To download the report, navigate to the enterprise's people page: https://github.com/enterprises/<enterprise>/people.

To learn more about this report, read our exporting membership information for your enterprise documentation.

See more

Enterprise fork policies for organizations

Previously, we announced the ability for enterprise owners to limit where private and internal repository forks can be created. We heard from some customers that they need a more granular control over fork permissions for each organization within the enterprise.

Now, we've added the ability for enterprise organization admins to set fork policy at the organization level, further restricting enterprise policy. Forking can be limited to organizations within the enterprise, within the same organization, user accounts and organization within the enterprise, user accounts, or everywhere. Fork policies cascade from the enterprise policy to organization policy to repository policy. Enterprise policies dictate the policy options available for organizations, i.e. an organization admin can only set a more restrictive forking policy than the enterprise allows.

Screenshot of organization fork policy settings

See more

Automatic Single Sign On for Enterprise Managed Users – Public Beta

Enterprise administrators can now choose to redirect signed-out Enterprise Managed Users to their company's single sign-on (SSO) page. This feature is available as a public beta.
By default, enterprises with Managed Users enabled are hidden, showing a 404 error page any time an enterprise resource is visited by a user that isn't already signed in to the enterprise.
If you enable this feature for your enterprise, visitors to resources in your enterprise, org, or user namespaces will immediately be presented with an SSO redirect if not already signed in to your enterprise.
This redirect helps users sign in to the correct account, rather than giving them the impression that the link they were given no longer works.

You can find this setting in the Authentication security section of your Enterprise Settings, below the single sign-on configuration sections.
image

Read more about this settings at "Automatic redirection for Enterprise Managed Users".

See more

New Audit Log events and event context

GitHub's audit log allows admins to quickly review the actions performed by members of their Enterprise. It includes details such as who performed the action, what the action was, and when it was performed. To ensure the audit log can be used as an effective security and compliance tool, GitHub is constantly evaluating new audit log events and ensuring those events have the necessary fields to provide meaningful context. GitHub has made the following enhancements to the Enterprise audit logs:

  • business.sso_response and org.sso_response events will be displayed in the REST API and audit log streaming payloads for GitHub Enterprise Cloud (GHEC) and GitHub Enterprise Server (GHES) version 3.8 or later.
  • repo.rename, project.rename, and protected_branch.update_name events will now include the old_name field make clear the current and past name of renamed repos, projects, and protected branches.
See more
View more changes