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 shows the health of tools enabled on a repository

The new code scanning tool status page allows users to view the status of CodeQL and other code scanning tools.
The page shows all the tools that are enabled on the repository and provides information about their setup types, configurations, and any relevant failures or warnings. If a tool is not working as expected, this is a good place to start troubleshooting the issue.

You can visit the new tool status page by using the button at the top of the repository's Code Scanning page.

code-scanning-tool-status-page-access

Statuses for the tool

The page indicates three possible statuses for the tool: all configurations are working, some need attention, and some are not working.

Code scanning needs to have received at least one analysis for the default branch to provide a tool status. Only the status of the default branch is reported.

The page shows the latest state of all analysis configurations for the tool. For instance, if you created two separate workflows to scan two distinct parts of the repository independently, the page displays the most recent state of the tool by combining the statuses of both.

The page structure

For each tool, the page provides actionable information about misconfigurations and errors, the number of scanned files per language, the setup types and configurations, the list of rules the tool checks against, and detailed CSV reports.

code-scanning-tool-status-page-detailed

Error messages

To help you with debugging, the tool status page shows error messages gathered from multiple code scanning system components during tool setup and analysis execution. These include errors from CodeQL, code scanning workflows, SARIF upload limits, and the internal code scanning system.

Third party code scanning tools are not yet able to deliver tool related errors to the page. In the future, these tools will be able to submit error messages to code scanning via SARIF uploads.

Scanned files

A Scanned Files section shows the number of analysed files per language compared to the number of files in the repository.

The section helps you determine whether code scanning tools are operating correctly on your repository and only shows information about languages supported and analysed by the tool while ignoring languages that are present in the repository but are not supported or being analysed by the tool.

This section is not yet displayed for third party code scanning tools. In the future, third party tools will be able to submit error messages to code scanning via SARIF uploads.

Delivery dates

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

Learn more about code scanning and the tool status page.

Learn more about GitHub Advanced Security.

See more

Incremental improvements to the security coverage enablement slide-out panel

We've recently released a few improvements to the slide-out enablement panel on the security coverage page in security overview:

  • Active committers for the repository are now visible, providing insight into the number of Advanced Security licenses being utilized. For repositories where Advanced Security is not enabled, the number indicates the number of licenses required to enable the feature.
  • Unsaved changes are now clearly labeled with a "Modified" tag. Additionally, the "Save security settings" button now displays the total number of enablement changes being made.
  • While a security feature is being enabled, the coverage page will show a status of "Updating…" to keep you informed of the ongoing process.

    Security coverage slide-out panel

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

Organization APIs for fine-grained PATs management

Organization owners can now automate the approval and auditing of fine-grained personal access tokens (PATs) in their organization using a GitHub app. New APIs and webhook events allow a GitHub app to be notified of new PAT requests in an organization, review the request, and then approve or deny the PAT. They also provide a view of all approved fine-grained PATs for an organization, with the ability to revoke their authorization as well. These APIs and events are part of the ongoing fine-grained PAT public beta that launched last year.

Mermaid diagram indicating how a request from a user triggers a webhook event to an app, who can then review the request and choose to approve it. Later, the application can review all approved PATs, and choose to revoke one, resulting in an email notification to the user who created the PAT.

Details included in the webhook event and API listings include the repositories and permissions requested, the expiration time of the token, and the user's explanation for what they plan to do with the PAT. The personal_access_token_request events are generated when a request is created, approved or denied by an administrator or application, or cancelled by the requesting user.

Only a GitHub app is able to call these APIs, either acting on its own or on behalf of a signed-in organization administrator.
The organization_personal_access_tokens permission is needed to manage the active tokens, while the organization_personal_access_token_requests permission enables the app to recieve webhooks about requests and call the request management APIs.

Organizations must have the personal access token approval flow enabled in order to manage these requests, otherwise fine-grained personal access tokens are automatically approved for the organization (which generates a personal_access_token_request: approved event).

To learn more about these APIs, see "List requests to access organization resources with fine-grained PATs" and the "personal_access_token_request webhook event". To learn more about fine-grained PATs, and how to enable them for your organization, see "Setting a personal access token policy for your organization".

If you have feedback or bugs to report about fine-grained PATs, please let us know in the dedicated feedback discussion.

See more

Code scanning API to enable default setup with CodeQL on a repository

Code scanning have shipped an API for repositories to programmatically enable code scanning default setup with CodeQL.

The API can be used to:

  • Onboard a repository to default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=configured
  • Specify which CodeQL query suite to use in the default setup configuration: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f query_suite=extended
  • View the current default setup configuration for a repository: gh api /repos/[org]/[repo-name]/code-scanning/default-setup
  • Offboard a repository from default setup: gh api -X PATCH /repos/[org-name]/[repo-name]/code-scanning/default-setup -f state=not-configured

When you onboard a repository via the API, you will recieve a workflow run ID which can be used to monitor the setup progress. This can be used to see the status and conclusion of the run: gh api repos/[org-name]/[repo-name]/actions/runs/[run-id] --jq '.status, .conclusion'

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

For more information, see "Get the code scanning default setup configuration" and "Update the code scanning default setup configuration".

See more

You can now use the “security extended” query suite in code scanning default setup with CodeQL

You can now enable the "security extended" query suite for repositories using code scanning default setup with CodeQL. This query suite can be selected during set up, or changed at any time by viewing and editing the CodeQL configuration.

Code scanning's default query suites have been carefully designed to ensure that they look for the security issues most relevant to developers, whilst also minimizing the occurrence of false positive results. However, if you and you developers are interested in seeing a wider range of alerts you can enable the security extended query suite. This suite includes the same queries as in the default query suite, plus:

  • extra queries with slightly lower severity and precision.
  • extra experimental queries.

If you enable the security extended suite you may see more CodeQL alerts in your repository and on pull requests. For more information, see "About code scanning alerts".

Code scanning default setup query suites

Code scanning default setup view configuration

Read more about code scanning default setup.

See more

Enable code scanning default setup with CodeQL at the organization level (public beta)

Enabling CodeQL analysis with code scanning default setup for eligible repositories in your organization is now as easy as a single click from the organization’s settings page or a single API call.

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 and Ruby. We plan to add support for additional languages soon.

To help you identify which repositories are eligible for the “enable all” feature, two new security coverage filters have been added:

  • code-scanning-default-setup: returns a list of enabled, eligible or not eligible repositories
  • advanced-security: returns a list of repositories with GitHub Advanced Security enabled or not enabled

This feature has been released as a public beta on GitHub.com and will also be available as a public beta on GitHub Enterprise Server 3.9.

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

Code scanning shows more accurate and relevant alerts on pull requests

Code scanning is now using a new way of analysing and displaying alerts on pull requests. The change ensures code scanning only shows accurate and relevant alerts for the pull request.

Previously, code scanning presented all alerts unique to the pull request branch, even if they were unrelated to the code changes the pull request introduced. Now, the tool reports only alerts inside the lines of code that the pull request has changed, which makes it easier to fix these contextualised alerts in a timely manner.

code scanning on the slide-out enablement panel on the security coverage page

The complete list of code scanning alerts on the pull request branch can be seen on the Security tab of the repository.

code scanning on the slide-out enablement panel on the security coverage page

In addition, code scanning will no longer show fixed alerts on pull requests. Instead, you can check whether an alert has been fixed by your pull request on the Security tab of the repository by using search filters: pr:111 tool:CodeQL. If you fix an alert in the initial commit in the pull request, it will not be present on the PR branch.

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

Learn more about viewing an alert on your pull request.

Learn more about GitHub Advanced Security.

See more

SSH Certificate requirement update

The "Require SSH certificates" policy now allows GitHub apps to call Git APIs using a user-to-server token, bringing them up to parity with OAuth app support.

The SSH certificate requirement mandates that users in your organization call Git APIs using an SSH certificate issued by your organization, in place of their own SSH key or a PAT.
To support automation, it has an exception in place for OAuth apps and GitHub app server-to-server tokens, which allows applications you've approved to call Git APIs for your organization.
With this change, we are extending that exception to GitHub app user-to-server tokens, for when a user has signed into a GitHub app that's installed in your organization.

Screenshot of the SSH Certificate requirement checkbox

This change also applies when the enterprise-level setting requires SSH certificates across all organizations in the enterprise.

To learn more, see "Managing your organization's SSH certificate authorities" or "Managing SSH certificate authorities for your enterprise".

See more

Organization Audit Logs include IP addresses – Public Beta

GitHub organization owners can now opt-in to a public beta to display organization members' IP addresseses in audit logs events. When enabled, IP addresses will be displayed for all audit log events performed by organization members on organization assets other than public repositories, which will be treated differently due to privacy obligations.

The inclusion of IP addresses in audit logs helps software developers and administrators protect their systems and data from potential threats and improve their overall security posture by providing the source of an action or event within a system or network. This information is crucial for troubleshooting issues or investigating security incidents. IP addresses are often used in forensic investigations to trace the origin of cyberattacks, unauthorized access, or other malicious activities.

For additional information and instructions for enabling this feature, read about displaying IP addresses in the audit log for your organization.

See more

Delete stale code scanning configurations to close outdated alerts

Code scanning configurations can now be deleted from the code scanning alert page. This could be used to delete stale configurations causing alerts to remain open, or delete old configurations which are no longer used.

Code scanning can be configured to use different tools, target different languages, or even analyze different parts of the codebase in the same repository. In certain circumstances more than one of these configurations may produce the same alert. However, if one of the configurations is no longer used and becomes 'stale' you may find that the alert is fixed in one configuration but not in the stale configuration, which is potentially confusing. Today we are releasing a new feature that allows you to easily delete stale configurations which cause alerts to remain open after they've been fixed.

In the code scanning alert page, the counter in the 'Affected branches' sidebar shows the number of configurations for the branch. Click a branch to view the configuration details, and delete configurations as required. A configuration is deleted for a branch, so may have an impact on the status of other alerts on the same branch. When a configuration is deleted, a timeline entry is recorded on the alert, and repositories in an organization also record an audit log entry. If a configuration is deleted by mistake, re-run the analysis to update the alert and reinstate the configuration.

Delete code scanning configurations

Read more about removing stale code scanning configurations and alerts.

See more

GitHub Enterprise Server 3.8 is now generally available

The GitHub Enterprise Server 3.8 is generally available

GitHub Enterprise Server 3.8 brings new capabilities to help companies build and deliver secure software. We've added over 100 features, and here are a few highlights:

  • GitHub Projects, the adaptable and flexible tool for planning and tracking work on GitHub is now available on Enterprise Server as a public beta.
  • GitHub Actions support organization-wide required workflows. You can define mandated workflows to run during the lifecycle of a repository’s pipeline.
  • Code scanning now supports Kotlin. We are launching a public beta for support of Kotlin, with this support enabled for all new code scanning users and any existing users that have already configured a Java analysis.
  • The Management Console now supports multiple users. We are introducing a multi-user concept with a user management interface to the Management Console to allow admins to invite new users with different types of access roles.

To learn more about about GitHub Enterprise Server 3.8, read the release notes, and download it now.

See more

Custom repository roles API GA and breaking change

The Custom Repository Roles REST API has moved to general availability, with a breaking change to the path used.
Previously, the API was found at /orgs/{org}/custom_roles – it has been moved to /orgs/{org}/custom-repository-roles. With organization-level custom roles in progress, we found that the custom_roles path was wasn't specific enough and could generate confusion.
The deprecated beta API will be removed from api.github.com in 6 months, on September 7th, 2023.
On GitHub Enterprise Server, the API will be available at its new path in version 3.9. The previous API to list roles was added in GHES 3.4, and will be removed with the next API version.

To learn more about custom repository roles, see "About custom repository roles" and "Custom repository roles REST API".

See more

Code scanning default setup on the security coverage page (public beta)

Code scanning default setup can now be easily enabled for a single repository from the slide-out panel on your organization's "Security Coverage" page, without needing to navigate to the repository's "Settings" tab.

The feature automatically detects the languages in your repository and enables analysis for pull requests and pushes, without requiring you to commit a workflow file. Default setup currently supports JavaScript, Python, and Ruby, with more languages to come. The feature is available for repositories using GitHub Actions and can be accessed by organization owners, repository administrators and security managers. Expect one-click enablement functionality for all organization repositories to be rolled out next.

This has shipped as a public beta to GitHub.com and will be available in GitHub Enterprise Server 3.9.

code scanning on the slide-out enablement panel on the security coverage page

Learn more about automatically setting up code scanning for a repository and send us your feedback

Learn more about GitHub Advanced Security

See more

More love for innersource collaboration and enterprise fork policies

In June 2022 we updated fork capabilities to include forking a repository into the same organization as its upstream repository, forking internal repositories to enterprise organizations, and for enterprise owners to limit where forks can be created. This opened up a lot of new possibilities for collaboration!

We recently updated fork capabilities again to unblock an additional workflow: fork repositories into another organization more than once. Before, when you tried to fork a repository into another organization that already had a fork of that repository, your option to finish forking into that organization was grayed out and GitHub let you know that a fork already exists in the target organization. With this update, you will have the option to continue forking it using a unique name.

screenshot of forking when the repo already exists and has a red warning triangle

screenshot of forking when the fork has been renamed and has a green check

We welcome your feedback on this in GitHub’s public feedback discussions.

See more
View more changes