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

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

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

Organization-level code scanning default setup for CodeQL is now generally available

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

EMU innersource restricted users private beta is now guest collaborators

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

Code scanning can filter alerts by language and file path

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

Choose which languages to enable in code scanning default setup for your repository

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

Enterprise managed users connector support for Ping Federate is now in public beta

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

EMU Namespace Repo Visibility & Access Public Beta

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

GitHub Advanced Security trial now available on GitHub Enterprise Cloud

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

The GitHub Enterprise Server 3.9 Release Candidate is available

The GitHub Enterprise Server 3.9 release candidate is here

GitHub Enterprise Server 3.9 brings new capabilities to help companies create and ship secure software, more often. Here are a few highlights:

  • Autoscaling with self-hosted runners – Actions administrators can configure auto scaling self-hosted actions runners using the actions runner controller and runner scale sets.
  • The Projects public beta has seen numerous improvements – We're continuing to add more functionality to Projects in GitHub Enterprise Server, to make planning and tracking your work in GitHub even more effective.
  • REST API now has versioning – API releases will be named with the date on which they are released (for example, 2021-04-01). Users will pick what version they want to use on a request-by-request basis, and each version will be supported for two years.
  • Establishing semantic conventions for logging – As part of GitHub's gradual migration to internal semantic conventions for OpenTelemetry, we have updated many of the field names in our logging statements. This makes it clearer what each statement is referencing and allows you to troubleshoot problems quicker.

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. Read more about the release candidate process.

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

See more

CodeQL code scanning now supports Swift (beta)

Today, we're extending CodeQL code scanning support to Swift! Developers working on Swift libraries and apps on Apple platforms can now benefit from our best-in-class code security analysis. We currently identify issues such as path injection, unsafe web view fetches, numerous cryptographic misuses and other types of unsafe evaluation or processing of unsanitized user-controlled data. During this beta, we’ll gradually increase our coverage of distinct weaknesses.

Swift joins our existing supported languages (C/C++, Java/Kotlin, JS/TS, Python, Ruby, C#, and Go), which in sum run nearly 400 checks on your code, all while keeping false positive rates low and precision high.

Set up code scanning on your Swift repositories today and receive actionable security alerts right on your pull requests. Read more about our supported Swift versions and platforms here.

Swift support is available starting with CodeQL version 2.13.3. GitHub.com users are automatically updated, while GitHub Enterprise Server users can update using these guidelines. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.

This is just the start for Swift support in GitHub Advanced Security, keep an eye on the main GitHub blog for further announcements. If you have any feedback or questions about the Swift beta, consider joining our community in the #codeql-swift-beta channel in the GitHub Security Lab Slack. Thanks to all Swift community members who have participated in the private beta.

See more

Secret scanning’s push protection now generally available for GitHub Advanced Security

Secret scanning's push protection feature is now generally available for GitHub Advanced Security customers.

Customers can enable push protection for any private repository that has GitHub Advanced Security. Push protection can also be enabled for any public repository, for free. To bulk enable push protection, customers can visit their organization and enterprise's "Code security and analysis" settings in the UI or REST APIs.

Push protection is also available for any custom pattern defined at the repository, organization, and enterprise level. See step 11 under "Defining a custom pattern for a repository" for more details in our documentation.

See more

Secret scanning summary email for historical scans

If you are an organization or enterprise owner, you will now receive a secret scanning summary email when the historical scan completes. The email notification will tell you how many, if any, secrets were detected across all repositories within your organization or enterprise. You'll also receive a link to your security overview page for each secret, where you can view details for each detected secret.

Previously, secret scanning would send one email per repository where secrets were detected, provided that you were watching the repository and had email notifications enabled in your user settings enabled. While repository administrators will still receive an email notification per repository, organization and enterprise owners will now receive only a single notification upon the historical scan's completion.

To receive notifications:

  • For the first historical scan after you enable secret scanning, you must have email notifications enabled in your user settings. You do not need to watch any repositories to receive the secret scanning summary email.
  • For future historical scans, such as for newly added patterns, you will receive an email notification for each repository where a secret was found. You must be watching the repository where the secret was detected and have email notifications enabled in your user settings.

summary email after backfill scan

See more

Dependabot alerts now automatically dismiss false positives for npm (public beta)

Starting today, Dependabot will be able to auto-dismiss npm alerts that have limited impact (e.g. long-running tests) or are unlikely to be exploitable. With this ship, Dependabot will cut false positives and reduce alert fatigue substantially.

On-by-default for public repositories, and opt-in for private repositories, this feature will result in 15% of low impact npm alerts being auto-dismissed moving forward – so you can focus on the alerts that matter, without worrying about the ones that don’t.

What’s changing?

When the feature is enabled, Dependabot will auto-dismiss certain types of vulnerabilities that are found in npm dependencies used in development (npm devDependency alerts with scope:development). This feature will help you proactively filter out false positives on development-scoped (non-production or runtime) alerts without compromising on high risk devDependency alerts.

Dependabot alerts auto-dismissal list view

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. Today’s ship, our first application, leverages GitHub-curated vulnerability patterns to help proactively filter out false positive alerts.

Why auto-dismissal, rather than purely suppressing these alerts?

Auto-dismissing ensures any ignored alerts are 1) able to be reintroduced if alert metadata changes, 2) caught by existing reporting systems and workflows, and 3) extensible as a whole to future rules-based actions, where Dependabot can decision on subsets of alerts and do things like reopen for patch, open a Dependabot pull request, or even auto-merge if very risky.

How does GitHub identify and detect low impact alerts?

Auto-dismissed alerts match GitHub-curated vulnerability patterns. These patterns take into account contextual information about how you’re using the dependency and the level of risk they may pose to your repository. To learn more, see our documentation on covered classes of vulnerabilities.

How will this activity be reported?

Auto-dismissal activity is supported across webhooks, REST, GraphQL, and the audit log for Dependabot alerts. In addition, you can review your closed alert list with the resolution:auto-dismissed filter.

How will this experience look and feel?

Alerts identified as false positives will be automatically dismissed without a notification or new pull request, and appear as 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.

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.

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 can I enable or disable the feature?

This feature is on-by-default for public repositories and opt-in for private repositories. Repository admins can opt in or out from your Dependabot alerts settings in the Code Security page.

Is this feature available for enterprise?

Yes! In addition to all free repositories, this feature will ship immediately to GHEC and to GHES in version 3.10.

What’s next?

Next, we’ll expose our underlying engine – which enables Dependabot to perform actions based on a rich set of contextual alert metadata – so you can write your own custom rules to better manage your alerts, too.

How do I learn more?

How do I provide feedback?

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

See more

Try our new expandable event payload view in your audit log – Private Beta

GitHub Enterprises and Organzations can now join a private beta to try our new expandable event payload view in their audit log.

Screen_Recording_2023-04-27_at_12_22_29_PM_AdobeExpress (2)

We have gotten a lot of feedback that the information available in the audit log U/I is not the same as the data available in the audit log's exports, API and streaming payloads. In response, GitHub is adding a new expandable view of an event's payload in the audit log U/I. This brings data consistency to all the ways of consuming audit logs.

Enterprise and Organization 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. Make sure to let us know what you think using our beta feedback community discussion post.

See more

Team Sync no longer invites or removes organization members by default

For GitHub Enterprise Cloud customers, team sync no longer invites members to organizations by default. For existing team sync customers we have added a configuration option to disable automatic organization provisioning for users that are synced from your identity provider groups. Team sync will not remove users from an organization when they are removed from a team.

For additional information and instructions to opt out of the default behavior, learn more in our team sync documentation.

See more

Enable security features for multiple repositories from your organization-level security coverage page

Available in public beta today, the security coverage page now includes multi-repository enablement, which lets you enable or disable security features across several repositories at once. This feature improves upon the “enable all” feature that only allows you to enable one security feature at a time for all repositories within the organization.

Multi-repository enablement also allows you to filter repositories based on attributes such as team or repository topic, and to enable or disable security features for only those repositories in just a few clicks.

 

multi-repository enablement panel on security coverage page

The following security features can be enabled/disabled using multi-repository enablement:

  • Dependency graph
  • Dependabot alerts
  • Dependabot security updates
  • GitHub Advanced Security
  • Code scanning default setup
  • Secret scanning
  • Push protection

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

Learn more about multi-repository enablement and send us your feedback

Learn more about GitHub Advanced Security

See more

Repository topics and team filters for enterprise-level Dependabot, secret scanning, and code scanning pages

You can now filter by repository topic or team on the enterprise-level Dependabot, code scanning, and secret scanning pages in security overview.

Code scanning enterprise-level page filtered by repository topic and showcasing the team drop-down

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

Learn more security overview and send us your feedback

Learn more about GitHub Advanced Security

See more

Secret scanning now detects secrets leaked historically in issues

GitHub Advanced Security customers using secret scanning can now view any secrets exposed historically in an issue's title, description, or comments within the UI or the REST API. This expanded coverage will also detect and surface secrets matching any custom pattern defined at the repository, organization, or enterprise levels.

See more

Code scanning default setup is available for Go

Code scanning default setup is now available for Go!

Default setup automatically finds and sets up the best CodeQL configuration for your repository. It detects the languages in the repository and enables CodeQL analysis for every pull request and every push to the default branch and any protected branches. A repository is eligible for default setup if it uses GitHub Actions and contains JavaScript/TypeScript, Python, Ruby or Go.

You can use default setup on your repository's "Settings" tab under "Code security and analysis".

Code scanning default setup Go

This new feature is available on GitHub.com today, and will also ship with GHES 3.10. More language support will be provided soon, and all other CodeQL-supported languages continue to work using a GitHub Actions workflow file. The options to set up code scanning using API uploads or third party analysis tools remain supported and are unchanged.

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

See more
View more changes