Repository rules now allow you to enforce which merge methods are available when merging pull requests into a specified branch. The merge method rule is available for rulesets at the repository, organization and the enterprise level. Allowing you to choose between merge commit, squash, or rebase to ensure only the selected merge methods are allowed on the targeted branches across the user interface and APIs.
Learn more in the documentation and join the discussion within GitHub Community.
Artifact Attestations now supports attesting multiple subjects simultaneously. When the attest-build-provenance or attest-sbom actions create multiple attestations, a single attestation is created with references to each of the supplied subjects, rather than generating separate attestations for each artifact. This reduces the number of attestations that you need to create and manage. We published these changes as new versions of the respective actions. Please update your workflows to reference the new versions in order to leverage the new functionality.
Learn more about using Artifact Attestations to establish provenance for builds
We are excited to announce the launch of new governance at scale features for enterprise accounts in public preview. This preview includes enterprise custom repository properties, enterprise repository policies and enterprise rulesets to help enterprise administrators manage more at greater scale.
Check out this video on managing your repositories at scale across the enterprise and learn more below.
Enterprise customers can now enrich repositories with metadata and govern protections for branches, pushes, and tags across your entire enterprise using repository custom properties and rulesets.
With custom properties available at the enterprise level, you can ensure consistent properties across organizations without manual synchronization and de-duplication. Enterprise and organization properties share a common namespace to prevent confusion when searching or targeting rulesets with properties.
To learn more about enterprise custom properties, head over to the docs.
Enterprise-level rulesets enforce consistent code governance rules to ensure thorough reviews of critical repositories with pull requests, and protect important locations from unauthorized pushes. Rule insights and push rule bypasses are also available at the enterprise level, providing complete visibility into the rulesets.
We are also introducing repository policies, which allow you to effectively manage repository lifecycle events such as deletions and visibility from the enterprise level. Enterprise administrators can target enterprise polices over repositories in organizations, as well as repositories homed under personal namespaces for any company using enterprise managed users.
Repository policies extend the ruleset framework to help you govern repositories beyond the code itself. These policies manage lifecycle events, enhancing the security, compliance and resilience of your repositories. You can enable repository policies per organization, and the preview launches with five policies:
– Restrict visibility
– Restrict creations
– Restrict deletions
– Restrict transfers
– Restrict names
To learn more about enterprise repository policy, head over to the docs.
To ask questions or share feedback, join our discussion in the GitHub Community.
The enterprise and organization-level audit log events are now created when a code scanning alert is created, fixed, dismissed, reopened, or appeared in a new branch:
– code_scanning.alert_created – a code scanning alert was seen for the first time;
– code_scanning.alert_appeared_in_branch – an existing code scanning alert appeared in a branch;
– code_scanning.alert_closed_became_fixed – a code scanning alert was fixed;
– code_scanning.alert_reappeared – a code scanning alert that was previously fixed reappeared;
– code_scanning.alert_closed_by_user – a code scanning alert was manually dismissed;
– code_scanning.alert_reopened_by_user – a code scanning alert that was previously dismissed was reopened.
The new functionality, which will be included in GHES 3.17, provides more insight into the history of a code scanning alert for easier troubleshooting and analysis.
For more information:
– Learn more about code scanning
– Learn more about audit log events for your enterprise
– Learn more about audit log events for your organization
To help you better understand the state of your pull request and get it merged faster, the merge experience on the pull request page has been improved! This experience is currently in public preview.
We’ve maintained the familiar look of the existing merge experience while incorporating several usability improvements:
For a more complete list of changes visit the feedback discussion.
This improved experience is rolling out gradually and is turned off by default. Once it becomes available to you, a Try the new merge experience link will appear below the merge box on the pull request page:
Click it to switch to the improved experience. A link is also available for easily switching back to the existing experience. You can also toggle the experience via the feature preview dialog.
As this experience is in public preview, you may run into some bugs and missing features (let us know when you do). Some of the known issues include:
For a more complete list of known issues visit the feedback discussion.
We want to hear from you! To provide feedback, ask questions, and see a list of known issues, visit the GitHub Community improved merge box discussion!
When configuring CodeQL security analysis using code scanning’s default setup, you can now specify whether to run the analysis on a standard GitHub-hosted runner, a larger GitHub-hosted runner, or a self-hosted runner. Previously, support for larger GitHub-hosted and self-hosted runners was limited to those with the code-scanning custom label. Now, you can specify any custom label, ensuring the analysis runs on the desired machine(s).
For example, using a custom label you are able to assign more powerful runners to critical repositories for faster analyses, better spread the workload over GitHub-hosted and self-hosted runners, or run the analysis on a particular platform (like macOS).
The new setting is available today on GitHub.com, and can be configured both at the repository level and within code security configurations for deployments at scale. This new setting will also be included in GitHub Enterprise Server (GHES) version 3.16.
Learn more about configuring default setup for code scanning.
GitHub Enterprise Server 3.15 is now available for download. Some key features & highlights you can find in this release include:
Updated minimum server specs recommended to run GitHub Enterprise Server (GHES). For more information, see minimum recommended requirements.
Project status updates using GraphQL and webhooks, unlock new ways to automate how you provide and gather project status update information. For more information, see GitHub Projects.
Custom properties now support new property types: multi select and true/false. Organization repositories can now be queried and filtered via properties via the UI and API. Read about filtering repositories.
Code security configurations are now available in GHES. These configurations simplify the rollout of GitHub security products at scale. They help you define collections of security settings and apply them across groups of repositories. We have retired the old organization-level code security settings UI experience along with the API parameters that complemented it. For more information, see code security configurations.
Secret scanning push protection is now supported for content upload REST API endpoints – create a blob and create or update file contents. Push protection blocks you from pushing secrets to a repository and generates a secret scanning alert whenever you bypass the block.
CodeQL‘s support for Swift and Kotlin is now generally available. CodeQL is the static analysis engine that powers GitHub code scanning.
Organization owners can now grant a user or team access to all of the repositories in their org with a single click. New pre-defined roles have been added to the organization settings, under Organization Roles > Role Management, where all organization owners can view and assign them. These can be further customized as well to grant specific repository permissions across your organization. For more information, see organization roles.
To learn more about GHES 3.15, check out the release notes or download it now. If you have any issues upgrading to version 3.15 or experience any issues using these new features, please contact our Support team.
Join the community discussion to share your feedback and ask questions.
Starting from November 13, 2024 new GitHub Team plan customers will gain access to the enhanced billing platform: a suite of new features designed to help administrators understand and manage GitHub spend for their organization.
Benefits of the new platform include:
Existing Team plan customers will gain access to the enhanced billing platform in the coming months. You will be informed via email and an in-app banner on the billing page in advance of the transition.
Here are some things to know about the transition:
Spending limits will be migrated and renamed as budgets in the new billing platform. For more details about budgets, visit Preventing overspendingFor more information, visit Using the enhanced billing platform for organizations” or join the GitHub Community discussion.
Today, we’re excited to introduce a new, streamlined search experience on npmjs.com! This update provides clear, objective sorting options that make finding the right packages easier.
The new search helps you quickly discover packages that are widely used, relied on by other projects, or recently updated. By removing vague options – i.e. popularity, quality, maintenance – each sorting option is now straightforward and transparent.
Try it out on npmjs.com, and share your feedback in our GitHub Community discussions.
Happy searching!
GitHub Copilot Extensions are now available in public preview for JetBrains IDEs! With Copilot Extensions, you can expand GitHub Copilot’s capabilities and context directly within your preferred JetBrains IDE environment. Use extensions to query third-party tools or private data using natural language, all without leaving your favorite editor.
Developers can also build custom extensions for internal use or publish them to the GitHub Marketplace. For more information, see our documentation on building Copilot Extensions.
To learn more, see our docs on using and installing Copilot Extensions.
A new REST API endpoint lists the secret scanning scan history for a repository, giving you visibility into when different types of secret scanning scans have occurred in your repository. This information can be helpful for auditing purposes and troubleshooting.
To get your repository’s scan history, call the /repos/{owner}/{repo}/secret-scanning/scan-history endpoint. The following table lists the responses returned by the API:
| Response | Description |
|---|---|
incremental_scans |
The latest scan for all patterns on new git content committed to a repository |
backfill_scans |
The latest scan for all patterns on the entire contents of a specific type (git, issues, pull-requests, discussions, wiki) |
custom_pattern_backfill_scans |
The latest scan for a specific custom pattern on the entire contents of a specific type (git, issues, pull-requests, discussions, wiki) |
pattern_update_scans |
The latest scan for a new or updated native pattern on git content in a repository |
Secret scanning covers multiple scan sources, triggers, and methods of scanning. Scans listed in the API are not an exhaustive list of all scans for a repository. The following scans are not included:
– incremental scans and pattern update scans for non-git content types
– non-git backfills for custom patterns set at the repository level
– any pattern update scans completed before September 2024
– scans for passwords detected with Copilot Secret Scanning
A repository must have a GitHub Advanced Security license to get the scan history.
Learn more about how to secure your repositories with secret scanning.
For organization owners, managing the security manager role is now easier and more flexible. These updates empower you to tailor security responsibilities and streamline role assignments to fit your needs:
The addition of custom organization roles with repository permissions takes flexibility to the next level. With these updates, you can customize security roles to balance the right level of responsibility and access for your team. Here’s how you can leverage these features to meet your specific requirements:
This lets you assign security responsibilities without granting the full access of a security manager role.
Expand the security manager role with additional permissions: Using custom organization roles, you can enhance the security manager role by adding additional organization-level or repository-specific permissions. For example, you can grant audit log access or other highly requested capabilities to create a tailored role that fits your team’s specific needs.
These updates are now generally available on GitHub Enterprise Cloud and will be included in GitHub Enterprise Server 3.16.
Learn more about the security manager role, custom organization roles and send us your feedback
You can now export security data for offline analysis, reporting, and archival purposes on the enterprise-level security overview pages. This includes:
Just like at the organization level, exports will respect all filters you’ve applied to the page, making it easy to for you to tailor downloads to your specific needs. Whether you’re focused on enterprise-wide insights or repository-level details, the data is now at your fingertips.
You can download all data where you have an appropriate level of access.
Learn more about security overview and send us your feedback
This update includes several key improvements: Copilot Chat on Mobile now includes beta supports for Copilot Extensions, iOS users can enjoy three new app icons in celebration of Universe, and Android users can pin their favorite repositories to the home screen.
With Copilot Extensions on Mobile, developers can extend Copilot’s capabilities on the go, integrating third-party tools, automating tasks, and receiving personalized code suggestions.
more button in Copilot chat shows the three most recent conversations.Based on customer feedback, we have updated how the created_at timestamp works in the Copilot seat details portion of responses from the following REST API endpoints:
/organization/{org}/billing/copilot/seats/enterprises/{enterprise}/billing/copilot/seats/organization/{org}/members/{username}/copilotThe created_at timestamp now shows when a user received Copilot access, rather than when their team, enterprise team, or organization was granted access. This matches the timestamp of the seat’s corresponding seat_added event in the Audit Log.
Audit logs play a critical role in keeping enterprises secure and auditing enterprise activity for compliance. Since becoming generally available in January 2022, audit log streaming has been used by over 2000 enterprises to transmit audit logs to Enterprises’ preferred streaming endpoints. We are excited to announce three new features that will help you programmatically configure audit log streaming to multiple endpoints of your choosing. In doing so, we aim to empower you to select and employ tools that best support your security and compliance objectives.
You can now enroll in a private preview that allows you to stream your audit logs to a user defined HTTPS event collector. This allows audit logs to written to any endpoint capable of accepting an HTTP post and meets our requirements for streaming GitHub audit logs. By introducing a user defined HTTPs event collector, you are empowered to stream your audit logs to the tool you feel best supports your enterprise’s needs.
This private preview is only available to GitHub Enterprise Cloud customers. Enterprise administrators 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. Let us know what you think by providing feedback on our community discussion post.
You can participate in a public preview to stream your Enterprise’s audit log to two of GitHub’s supported streaming endpoints. You can stream your audit log to two endpoints of the same type, or you can stream to two different providers.
This update allows you to use your preferred choice of tools for log storage and analysis. When managing your Enterprise, you may need to employ multiple tools to ensure compliance and maintain a strong security posture. This can involve different teams, requiring different levels of access, employing different technology to accomplish their objectives in supporting your Enterprise’s security and compliance requirements. By streaming your audit logs to two endpoints, you can employ multiple log storage and analysis tools without the need for a complex log routing architecture or dealing with increased latency.
This public preview is available to all GitHub Enterprise Cloud customers. We plan to ship this feature to GitHub Enterprise Server when this feature is released as generally available. To set up multiple streams, follow the instructions for each provider for setting up audit log streaming.
You can now configure audit log streaming via the REST API. This private beta grants access to new API endpoints for the following audit log streaming actions:
With the introduction of these new REST API endpoints, enterprise owners can programmatically create, update, delete and list their Enterprise’s audit log streams. By allowing programmatic updates to the audit log streaming configuration, customers can automate tasks like rotating your audit log streaming secrets.
These new audit log streaming endpoints will impose a rate limit of 15 API requests per hour protect the availability of the audit log streaming service. For the time being, these endpoints are only accessible via personal access token (PAT) classic and OAuth token with admin:enterprise scope.
This feature is generally available on GitHub Enterprise Cloud (GHEC) and will be included in the release of GitHub Enterprise Server (GHES) version 3.16. To learn more, check out our documentation for the REST API endpoints for enterprise audit logs
You can now enroll in a private preview to use GitHub-owned storage when migrating repositories to GitHub Enterprise Cloud using GitHub Enterprise Importer (GEI). This means that you no longer need to provide GEI with access to a customer-owned storage account via shared access keys to perform repository migrations. Instead, migrations can now be performed with repository archives uploaded directly to GitHub.com.
Once enrolled in the preview, repository migrations can be initiated to use GitHub-owned storage via the gh gei and gh bbs2gh command line extensions by passing in the --use-github-storage flag.
If you’re interested in participating in this private preview, please reach out to your GitHub account manager or contact our sales team to have this feature enabled for your enterprise. For additional technical details, instructions for running repository migrations with GitHub owned storage, or to provide feedback on this feature, please check out our community discussion post.
Enterprises now have more control over their two-factor authentication (2FA) policies for all members of their organization through an enhanced 2FA enrollment experience in GitHub.
With this update, enterprise and organization administrators can ensure that users are maintaining secure 2FA methods when accessing enterprise and org resources. Currently, GitHub defines SMS/text message as an insecure method of 2FA, and TOTP authentication applications, the GitHub Mobile app, security keys, and passkeys as secure methods. Members without a secure method of 2FA configured, or who have insecure 2FA configured, will be prompted to configure secure 2FA before being allowed to access resources.
Enterprises can enable this new 2FA policy alongside a general 2FA requirement for their members, and current enterprises with a 2FA requirement can update their 2FA settings to add this secure methods enforcement. Members who are non-compliant with the new 2FA policy will no longer be removed from organizations, lessening a historical friction around enforcing 2FA policies at an enterprise or organization level, and instead be prevented from accessing enterprise or organization resources while non-compliant.
This new policy enables enterprises to protect their resources by only allowing access for users who meet the required security standards, without compromising organization membership integrity.
Learn more about the new enterprise policy for requiring only secure methods of two-factor authentication and about how GitHub is securing developer accounts using 2FA.
New accessibility enhancements to the security overview data visuals make it easier and more inclusive for everyone to interact with and understand code security insights.
These updates are now generally available on GitHub Enterprise Cloud and will be included in GitHub Enterprise Server 3.16.
Join the discussion in the GitHub Community and read more about GitHub’s commitment to accessibility
Dependabot can now keep you up to date with the latest version of the .NET SDK by updating the global.json file in your repository. You can enable updates for the .NET SDK by adding a dotnet-sdk entry to your dependabot.yml file. At this time, Dependabot will not create security alerts for the .NET SDK, although performing regular version updates will ensure you’re always using the latest .NET SDK.
See our documentation to learn more about configuring Dependabot.