security-and-compliance

Subscribe to all “security-and-compliance” 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

On December 13, 2023, we released CodeQL Action v3, which runs on the Node.js 20 runtime. In January 2024, we announced that CodeQL Action v2 would be retired at the same time as GitHub Enterprise Server (GHES) 3.11. This retirement period has elapsed and CodeQL Action v2 is now discontinued. It will no longer be updated or supported, and while we will not be deleting it except in the case of a security vulnerability, workflows using it may eventually break. New CodeQL analysis capabilities will only be available to users of v3.

For more information about this retirement, please see the original retirement announcement from January 2024.

How does this affect me?

Default setup

Users of code scanning default setup do not need to take any action in order to automatically move to CodeQL Action v3.

Advanced setup

Users of code scanning advanced setup need to change their workflow files in order to start using CodeQL Action v3.

Users of GitHub.com and GitHub Enterprise Server 3.12 (and newer)

All users of GitHub code scanning (which by default uses the CodeQL analysis engine) on GitHub Actions on the following platforms should update their workflow files:

  • GitHub.com (including open source repositories, users of GitHub Teams and GitHub Enterprise Cloud)
  • GitHub Enterprise Server (GHES) 3.12 (and newer)

Users of the above-mentioned platforms should update their CodeQL workflow file(s) to refer to the new v3 version of the CodeQL Action. Note that the upcoming release of GitHub Enterprise Server 3.12 will ship with v3 of the CodeQL Action included.

Users of GitHub Enterprise Server 3.11 (and older)

GitHub Enterprise Server 3.11 (and older) is now retired. For more information on using the CodeQL Action on a retired GitHub Enterprise Server version, refer to the relevant sections of the CodeQL Action v2 retirement announcement.

Exactly what do I need to change?

To upgrade to CodeQL Action v3, open your CodeQL workflow file(s) in the .github directory of your repository and look for references to:

  • github/codeql-action/init@v2
  • github/codeql-action/autobuild@v2
  • github/codeql-action/analyze@v2
  • github/codeql-action/upload-sarif@v2

These entries need to be replaced with their v3 equivalents:

  • github/codeql-action/init@v3
  • github/codeql-action/autobuild@v3
  • github/codeql-action/analyze@v3
  • github/codeql-action/upload-sarif@v3

Can I use Dependabot to help me with this upgrade?

Yes, you can! For more details on how to configure Dependabot to automatically upgrade your Actions dependencies, please see this page.

See more

GitHub continually updates the default pattern set for secret scanning with new patterns and upgrades of existing patterns, ensuring your repositories have comprehensive detection for different secret types.

The following new patterns were added over the last few months. Secret scanning automatically detects any secrets matching these patterns in your repositories. See the full list of supported secrets in the documentation.

Provider Token Partner User Push protection
Anthropic anthropic_admin_api_key
Asaas asaas_api_token
Asana asana_legacy_format_personal_access_token  ✓
Azure azure_openai_key
Azure microsoft_azure_common_annotated_security_key
Azure microsoft_azure_entra_id_token
Cfx.re cfxre_server_key
Cockroach Labs ccdb_api_key
Coveo coveo_access_token
Databento databento_api_key
Datastax datastax_astracs_token
Google google_cloud_service_account_credentials
Google google_gcp_api_key_bound_service_account ✓  
Hubspot hubspot_private_apps_user_token
Hubspot hubspot_smtp_credential
Hugging Face hf_user_access_token
Iterative iterative_dvc_studio_access_token
Lichess lichess_personal_access_token
Lichess lichess_oauth_access_token
MongoDB mongodb_atlas_db_uri_with_credentials
Netflix netflix_netkey
OpenRouter openrouter_api_key
Oracle oracle_api_key
Polar polar_access_token
Polar polar_authorization_code
Polar polar_client_registration_token
Polar polar_client_secret
Polar polar_personal_access_token
Polar polar_refresh_token
Replicate replicate_api_token
Scalr scalr_api_token
Sentry sentry_org_auth_token
Sentry sentry_user_auth_token
Sentry sentry_user_app_auth_token
Sentry sentry_integration_token
Shopee shopee_open_platform_partner_key
Siemens siemens_api_token
Sindri sindri_api_key
Tailscale tailscale_api_key

The following existing patterns were upgraded to be included in push protection. When push protection is enabled, secret scanning automatically blocks any pushes that contain a secret matching these patterns.

Provider Token
Contentful contentful_personal_access_token
GitLab gitlab_access_token
Ionic ionic_refresh_token
Orbit orbit_api_token
PyPI pypi_api_token
Thunderstore thunderstore_io_api_token
Yandex yandex_cloud_iam_access_secret

Learn more about securing your repositories with secret scanning.

See more

To enhance auditing and troubleshooting, we’ve introduced new webhook and audit log events to track the completion of certain secret backfill scans on repositories.

The events specify the type of backfill scan completed (e.g., Git backfill or issues backfill) and the secret types scanned, including custom patterns. Note that secrets detected through Copilot Secret Scanning are not included.

Backfill scans cover the entire repository and occur when secret scanning is enabled or patterns are updated. These events do not include information on incremental scans, which focus on new content pushed to a repository.

A repository must have a GitHub Advanced Security license to access these events.

Learn more about how to secure your repositories with secret scanning.

See more

CodeQL build-mode: none scans can now access private dependencies stored in private registries (e.g. Artifactory) for Java and C# projects. This makes your scans more comprehensive, ensuring you receive all important alerts regardless of where your dependencies are stored.

Previously, build-mode: none code scans with the default setup were unable to fetch code for dependent packages stored in private registries, which could result in incomplete analysis. Now, organization administrators can configure access credentials for private registries at the organization level. This enhancement allows CodeQL scans in child repositories to retrieve all necessary dependencies, enabling comprehensive code analysis when using the code scanning default setup.

This feature is currently in public preview for GitHub Advanced Security customers.

See more

You can now more easily filter secret scanning alerts, with new filter options and advanced filtering.

  • Enterprise and organization level list views now include a new menu with commonly used and suggested filter options, like bypassed secrets, publicly leaked secrets, and those with enterprise duplicates. The repository level list view now supports a new “advanced filtering” menu.
  • The experimental toggle has been removed from the alert list header UI, but you can still access it from the sidebar navigation menu and with the results:experimental filter.
  • Public leak and multi-repository indicators are fully supported across list views, including alert list views and the REST API. In the UI, in addition to menu options, you can access these filters with is:multi-repository and is:publicly-leaked. These indicators are also included in webhook and audit log event payloads for secret scanning alerts.

What are public leak and multi-repo labels?

To help you triage and remediate secret leaks more effectively, GitHub secret scanning now indicates if a secret detected in your repository has also leaked publicly with a public leak label on the alert. The alert also indicates if the secret was exposed in other repositories across your organization or enterprise with a multi-repository label.

These labels provide additional understanding into the distribution of an exposed secret, while also making it easier to assess an alert’s risk and urgency. For example, a secret which has a known associated exposure in a public location has a higher likelihood of exploitation. Detection of public leaks is only currently supported for provider-based patterns.

The multi-repository label makes it easier to de-duplicate alerts and is supported for all secret types, including custom patterns. You can only view and navigate to other enterprise repositories with duplicate alerts if you have appropriate permissions to view them.

Both indicators currently apply only for newly created alerts.

Learn more

Learn more about reviewing alert labels and how to secure your repositories with secret scanning. Let us know what you think by participating in our GitHub community discussion or signing up for a 60 minute feedback session.

See more

You can now enable code scanning in your GitHub Actions workflow files. By opting-in to this feature, you can enhance the security of repositories using GitHub Actions.

Actions analysis support includes a set of CodeQL queries developed by the GitHub Security Lab to capture common misconfigurations of workflow files that can lead to security vulnerabilities. You can now easily run these queries as part of Code Scanning’s default or advanced setup and use Copilot Autofix to get remediation suggestions on your findings.

You can opt-in to the public preview by selecting the “GitHub Actions” language via code scanning default setup, or by adding the actions language to your existing advanced setup. New repositories onboarding to default setup after today will start analyzing Actions workflows right away. Existing repositories will not be automatically opted-in as part of the public preview.

Learn more about configuring default setup for code scanning, securing your use of Actions, and vulnerabilities identified with CodeQL.

See more

New REST API endpoints for code scanning allow you to request the generation of Copilot Autofix for code scanning alerts. These endpoints also provide the Autofix generation status, along with metadata and AI-generated descriptions for the fixes, and enable you to apply Autofix to a branch. This functionality can be particularly useful for addressing security vulnerabilities programmatically and for tracking the status of alerts with Copilot Autofixes in your system.

To generate Copilot Autofix, call the POST /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix endpoint.
Additionally, you can retrieve the Autofix and commit it by using the GET /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix endpoint followed by POST /repos/{owner}/{repo}/code-scanning/alerts/{number}/autofix/commits.

For more information, see: About Copilot Autofix for CodeQL code scanning. If you have feedback for Copilot Autofix for code scanning, please join the discussion here.

See more

You can now create and manage code security settings at the enterprise level. This change reduces the need for repetitive setup at the organization level.

Key updates:
– Apply configurations across all repositories in an enterprise, only to repos without existing configurations, or to newly created repos.
– Enforce settings across your enterprise, ensuring security policies are applied consistently.
– Enterprise configurations will also appear on the organization-level page, giving you the flexibility to manage centrally but deploy locally. This also enables you to roll out configurations, organization by organization.

Learn more about enterprise-level code security configurations.

See more

As part of our ongoing efforts to improve flexibility and control for managing the security manager role, we are retiring the security manager API and replacing it with the more robust organization roles API, which provides expanded functionality for managing roles in an organization, including security managers.

Endpoints Affected

The following security manager endpoints will be retired in 12 months:

  • GET /orgs/{org}/security-managers/teams
  • PUT /orgs/{org}/security-managers/teams/{team_slug}
  • DELETE /orgs/{org}/security-managers/teams/{team_slug}

After this period, these endpoints will no longer be available. Instead, you can use the organization roles API to perform the same actions and much more.

Retirement Timeline

  • GitHub.com: 2025-12-31
  • GitHub Enterprise Server: Version 3.20

Replacements

The organization roles API offers enhanced capabilities for managing roles across an organization. Use the following endpoint as a replacement:

  • GET /orgs/{org}/roles
  • GET /orgs/{org}/roles/{role_id}/teams
  • PUT /orgs/{org}/roles/{role_id}/teams/{team_slug}
  • DELETE /orgs/{org}/roles/{role_id}/teams/{team_slug}

You can start transitioning to the organization roles API today on GitHub.com. For GitHub Enterprise Server users, the organization roles API will support the security manager role starting in version 3.16.

Learn more about the organization roles API and send us your feedback

See more

Reviewers can now add comments to push protection bypass requests in secret scanning. These comments help provide context, explaining the reasoning behind approving or denying a request. Requesters gain clarity on why their request was denied, and other reviewers can better understand why a request was approved or denied.

The comment is included in the response email sent to the requester, as well as in the timeline of the resulting alert, the API, the audit log, and webhook responses.

screenshot of an alert that has bypassed push protection, with a reviewer comment in the timeline

Learn more about how to secure your repositories with secret scanning and push protection bypass controls.

See more

The metrics overview for CodeQL pull request alerts now includes enhanced tracking and reporting mechanisms, resulting in greater accuracy and more CodeQL pull request alerts and Copilot Autofixes displayed on the dashboard.

These changes retroactively affect the dashboard numbers, allowing you to effectively monitor your organization’s security posture.

With these insights, you can proactively identify and address security risks before they reach your default branch. The metrics overview for CodeQL pull request alerts helps you understand how effectively CodeQL prevents vulnerabilities in your organization. You can use these metrics to easily identify the repositories where action is needed to mitigate security risks.

The change is now generally available on GitHub Enterprise Cloud.

Learn more about security overview and code scanning.

See more

We are pleased to announce that our most recent SOC reports (1, 2, and 3) are available now and include GitHub Enterprise Cloud for github.com with all new regions like the EU, as well as Copilot Business and Enterprise. These reports are applicable for the 6-month period April 1, 2024 to September 30, 2024 and are available on the GitHub Enterprise Trust Center for our customers.

This represents a significant milestone for GitHub and our customers for multiple reasons:
– Copilot Business and Enterprise are now gaining coverage of control operating effectiveness over the period represented by a Type II report (as opposed to the point-in-time reports represented by the previous Type I reports issued Spring 2024)
– Coverage for Enterprises hosted in either dotcom or the newly launched EU region.
– Future regions launched for GitHub Enterprise Cloud will also be compliant.

These efforts and the culminating SOC 2 Type II reports represent GitHub’s ongoing commitment to provide secure products to our customers, which continues to provide developers the assurance to build software better, together.

Looking forward, bridge letters will be coming mid-January 2025 for the gap period representing October through December 2024. Additionally, the next round of SOC reports covering October 1, 2024 to March 31, 2025 will be available to customers in June 2025.

See more

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

See more

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.

See more

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.

See more