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

In April, we announced that GitHub Enterprise Cloud customers could join a public beta for streaming API request events as part of their enterprise audit log. As part of that release, REST API calls against enterprise's private and internal repositories could be streamed to one of GitHub's supported streaming endpoints.

However, we've discovered the need to expand our api call coverage against private and internal repositories in order to capture other security significant api routes. Additionally, we've determined several api routes targeting internal and private repositories generate significant event volumes with little auditing or security value. To address these concerns, we partnered with GitHub's security team to define a set of auditing and security significant controllers to serve as the basis for the public beta. These adjustments to the beta should increase signal and decrease the noise generated by the api request event being streamed.
image (4)

Note: hashed_token and token_id have been redacted for security reasons.

Enterprise owners interested in the public beta can still follow the instructions in our docs for enabling audit log streaming of API requests. We welcome feedback on the changes made to this feature on our beta feedback community discussion post.

See more

With GHES 3.9, you and your organization can better manage your Dependabot alerts thanks to more granular enablement controls. You can now enable Dependabot alerts at the repository, organization, and enterprise level, rather than having to enable Dependabot alerts across an entire enterprise at once.

This release also adds support for “automatically enable for new repositories” at the organization and enterprise levels.

Enterprise admins still need to opt in to Dependabot alerts via GitHub Connect, which approves outbound calls for advisories to sync.

Learn more about changes for GHES 3.9 for Dependabot.

See more

GitHub provides Enterprise customers with the ability to programmatically retrieve enterprise and organization audit log events in near real-time using the audit log API. A high-quality audit log is an essential tool used by enterprises to ensure compliance, maintain security, investigate issues, and promote accountability. To support these objectives, the audit log API needs to be highly reliable, consistently available, and extremely scalable.

Recognizing the audit log API's importance as a data source to enterprises, each audit log API endpoint will impose a rate limit of 15 queries per minute per enterprise or org starting August 1st, 2023. Based on a thorough analysis of event generation data, we are confident that the new rate limit will continue to support customers in accessing near real-time data via the audit log API. Additionally, query cost is a crucial consideration, and in the future, the audit log may impose further rate limiting for high-cost queries that place significant strain on our data stores.

What can you do to prepare for these changes? First, programs or integrations querying the audit log API should be adjusted to query at a maximum frequency of 15 queries per minute. Additionally, applications querying the audit log API should be updated to be capable of honoring HTTP 429 responses, enabling them to dynamically adjust to the back-pressure exerted by our systems. Alternatively, Enterprises seeking access to near real-time data should consider streaming your enterprise audit log.

See more

Today we are announcing the general availability of our organization and enterprise-level security risk and coverage pages.

Additionally, the alert-centric pages for Dependabot, code scanning, and secret scanning are also now generally available at both the organization and enterprise levels.

The enterprise-level security overview page has been replaced by the risk and coverage pages as previously announced. The risk page is designed to help you assess security exposure, and the coverage view is intended to help you manage security feature enablement.

To access the new enterprise-level risk and coverage pages, follow these steps:

  1. Navigate to your profile photo in the top-right corner of GitHub.com.
  2. Click Your enterprises.
  3. From the list of enterprises, select the enterprise you wish to view.
  4. In the enterprise account sidebar, click on Code Security.

These improvements have shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about the new risk and coverage pages and send us your feedback

See more

Enterprise users will now notice added functionality where Dependabot security and version updates may be paused for repositories.

If you are an enterprise user that uses Dependabot updates and there has been no activity in a repository, such as merging, closing, or any other interaction, with Dependabot pull requests for a period exceeding 90 days, the updates will be paused. To resume activity, simply merge or close one of Dependabot's pull requests, or modify the Dependabot config file in the repository.

This change will help Dependabot be more focused to the repositories you care about and reduce use of GitHub Actions minutes on inactive Dependabot pull requests.

If you are using security overview with GitHub Advanced Security, you will be able to see which repositories in your organization have been paused from the security coverage view.

You will also be able to see whether Dependabot has been paused for a repository by querying the /repos/{owner}/{repo}/automated-security-fixes REST API endpoint, which will return both the enablement status and paused status of the repository.

When will Dependabot become paused?

This change only applies to repositories where Dependabot pull requests exist but remain untouched. If no Dependabot pull requests have been opened, Dependabot will never become paused.

The following must be true for at least 90 days:

  • Has not had a Dependabot PR merged
  • Has not had changes made to the Dependabot config file
  • Has not had any @dependabot comment-ops performed
  • Has not had any Dependabot PRs closed by the user
  • Has received at least one Dependabot PR before the 90 day window
  • Has at least one Dependabot PR open at the end of the 90 day window
  • Has had Dependabot enabled for this entire period

How will Dependabot let me know?

Dependabot will add a notice to the body of all open Dependabot pull requests and add a dependabot-paused label to them. Dependabot will also add a banner notice in the UI of your repository settings page (under “Dependabot”) as well as your Dependabot alerts page (if Dependabot security updates are affected).

Who can use this feature?

This change does not apply to Dependabot alerts or subsequent notifications. So, only repositories that have automated Dependabot version updates or security updates, but haven't interacted with these pull requests for a while, will be affected.

Learn more about this change
Learn more about how to interact with the REST API

See more

Code scanning default setup is now available for all CodeQL supported languages, excluding Swift. This includes supporting JavaScript/TypeScript, Ruby, Python, Go, Java/Kotlin, C/C++, and C# at the repository level. We will extend support to include Swift soon. We are also working to extend all CodeQL language support to the organization level.

Default setup detects the languages in the repository and automatically analyzes JavaScript/TypeScript, Ruby, Python, and Go. With this enhancement, you can customize the configuration to also analyze Java/Kotlin, C/C++, and C#. The configuration can be viewed and edited at any time, during or after set up.

You can also use the REST API to include CodeQL supported languages in the default setup configuration.

What if the analysis for a language fails in default setup?

It is possible for the CodeQL analysis for a particular language to fail, such as when the code can't be compiled. If the CodeQL analysis for a language fails in default setup, you will see an error message on the repository's settings page, in the code security and analysis section. To resolve the situation you can:

  1. Deselect the language from the configuration and continue to use default setup for the successful languages.
  1. Convert to advanced setup. The advanced setup uses a yml file and allows you to provide the build information required for the CodeQL analysis to succeed.
  1. Debug and fix the cause of the language failure. The Actions log will provide the failure reason so you can resolve this for a successful analysis.

Why aren't some languages automatically included in the default setup configuration ?

Java (including Kotlin), C/C++, and C# are not automatically included in the default setup configuration because they often require more advanced configuration. Code written in these languages needs to be compiled in order for CodeQL analysis to proceed. CodeQL will attempt to build your code automatically but may fail if your code requires bespoke build steps.

Java (including Kotlin), C/C++, and C# are not included in bulk code scanning setup from the organization level. We are working to extend all CodeQL language support to the organization level soon.

For more information on code scanning default setup, see Configuring code scanning automatically.

See more

The Enterprise and Organization audit log UI and user security logs UI now include an expandable view that displays the full audit log payload of each event.

Customers can now see the same event metadata when searching your audit log via U/I, exporting audit logs to a JSON file, querying the audit log API, or streaming your audit logs to one of our supported streaming endpoints.

See more

Code scanning default setup now automatically updates when the languages in a repository change.

If a repository that uses default setup changes to include the languages JavaScript/TypeScript, Ruby, Python, or Go, the configuration will automatically update to include these languages. If the new configuration fails, we’ll resume the previous configuration automatically so that the repository does not lose coverage. The configuration will also automatically update if a repository removes a language.

You can always view the repository’s default setup configuration from the Code security and analysis settings page. Additionally, you can use the tool status page to view useful information about your setup and debug any failed languages.

Default set up makes it easy to get started with code scanning. The supported languages are currently JavaScript/TypeScript, Python, Ruby and Go and the list is constantly evolving. For more information on code scanning default setup, see Configuring code scanning automatically.

See more

Today we are announcing the general availability of code scanning default setup enablement at the organization level.

Code scanning enable all default setup button on the organization's 'Settings' page

You can use code scanning default setup to enable CodeQL analysis for pull requests and pushes on eligible repositories without committing any workflow files. Currently, this feature is only available for repositories that use GitHub Actions and it supports analysis of JavaScript/TypeScript, Python, Ruby and Go. We plan to add support for additional languages soon.

This feature is also available as a public beta in GitHub Enterprise Server 3.9 and will be generally available in GitHub Enterprise Server 3.10.

Learn more about configuring code scanning at scale using CodeQL and the "Enable or disable a security feature for an organization" REST API
Learn more about GitHub Advanced Security

See more

In late 2022 we launched a private beta of innersource restricted users allowing customers with enterprise managed users (EMU) to assign an IdP-defined role to users who should not be granted access to internal repositories in any organization they are not expressly a member. We have made improvements to align product behavior with beta customer feedback and are updating the feature name to "guest collaborators" to better reflect the expected use cases. Guest collaborators are distinct from outside collaborators because they are always IdP-defined users intended to be fully managed within an enterprise's security boundary.

Existing private beta customers will see visual changes reflecting the transition from "restricted users" to "guest collaborators" over the coming days. We have also submitted Azure AD and Okta app changes to support a "guest collaborator" role to replace "restricted user". While the guest collaborators feature remains in private beta, we are working toward an upcoming public beta release adding the ability to selectively add guest collaborators to individual repositories without granting organization membership. At public beta release, we will have more information on how to transition your existing app integration without any breaking change.

We are still accepting private beta enrollments for customers if you would like to test the existing capabilities of the feature. Please reach out to your account team or contact our sales team for more details.

See more

You can now easily find all alerts associated with a specific language with the new language filter on the code scanning alerts page.

To show all the code scanning alerts for a language, type 'language:javascript' in the Filter alerts text box.

Language filter

You can also use a file path filter to see all the alerts located in specific files or directories to sort and manage them efficiently by focusing on a specific part of the code related to the project.
This can be useful to manage lots of alerts on big repositories (monorepos) to review all alerts specific to the part of the code you are responsible for faster.

To apply the file path filter, type 'path:' and the path to the file or directory in the Filter alerts text box.

Path filter

This has shipped to GitHub.com and will be available in GitHub Enterprise Server 3.10.

Learn more about filtering code scanning alerts.

See more

Code scanning now has the option to enable default setup for a subset of languages in a repository. This lets you customize the configuration to suit your repository's needs, for example deselecting a language which is failing the analysis.

Default set up makes it easy to get started with code scanning. The supported languages are currently JavaScript/TypeScript, Python, Ruby and Go and the list is constantly evolving.

When you choose default setup, we automatically tailor a code scanning configuration for the repository. By default we will enable the best CodeQL configuration for all languages in your repository. However, if there is a language that you'd prefer to disable in code scanning, you can now customize the languages in your default setup configuration.

Use the 'edit configuration' page or REST API to edit the default setup configuration for a repository. You can customize the languages and query suites used in the analysis. The configuration can be viewed and edited at any time, during or after set up.

{
  "state": "configured",
  "languages": ["javascript-typescript", "ruby"],
  "query_suite": "default", 
  "updated_at": "2023-02-24T20:00:42Z"
}

For more information on code scanning default setup, see Configuring code scanning automatically.

See more

GitHub Enterprise Cloud customers with enterprise managed users (EMU) can now integrate with Ping Federate as a formally supported SSO and SCIM identity provider in public beta. 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.

PIC-Square-Logo-Primary

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

Repositories in the user namespace of enterprise-managed users (EMU) can now be seen and accessed by enterprise administrators. All repositories in the user namespace (e.g. https://github.com/mona_tenantName/scratch) can now be navigated to from the Repositories enterprise policies page: https://github.com/enterprises/<enterprise>/settings/member_privileges. From this new view, administrators can temporarily grant themselves administrative rights to these repositories. This action will trigger alerts to the repository owner as well as audit log events.

This public beta feature set is intended to increase visibility of namespace repositories to administrators while also empowering administrators to audit these repositories as needed.

To learn more, check out our documentation about viewing user-owned repositories in your enterprise and accessing user-owned repositories in your enterprise.

See more

All eligible GitHub Enterprise accounts can now try GitHub Advanced Security for free for 14 days. GitHub Advanced Security provides integrated security with unparalleled access to curated security intelligence. This unlocks your ability to keep your code, supply chain, and secrets secure before pushing the code to production. During the trial, you can try features such as:

  • Code scanning to help find and remediate security issues in your code
  • Secret scanning to prevent and detect secret exposures across your organization
  • Dependency review to catch vulnerable dependencies before introducing them to your environment

Explore our documentation to learn more about GitHub Advanced Security features and how to deploy them in your organization.
GitHub Advanced Security on Enterprise Cloud

See more