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

Security campaigns with Copilot Autofix are now in public preview

Security campaigns with Copilot Autofix are now in public preview. Available as part of GitHub Advanced Security, security campaigns rapidly reduce your backlog of application security debt. By using Copilot Autofix to generate contextual explanations and code suggestions for up to 1,000 historical code scanning alerts at a time, security campaigns help developers and security teams collaborate to fix vulnerabilities with speed and confidence.

Code scanning detection engines such as GitHub’s CodeQL are incredibly effective at automatically notifying developers about potential security vulnerabilities in their code in the form of code scanning alerts. Most developers fix these vulnerabilities with the help of Copilot Autofix when they’re flagged pull requests. However, in situations where these alerts aren’t remediated in a timely manner, security debt can build up and pose a serious risk to deployed applications. Using security campaigns, security teams and developers can easily collaborate to remediate and eradicate security debt at scale, with the help of Copilot Autofix.

A security campaign on GitHub can contain a large number of code scanning alerts, prioritized by your security team to be fixed within a chosen timeframe. When a campaign is created, Copilot Autofix automatically suggests fixes for all supported alerts, and developers who are most familiar with the code are notified. From there, they can review the fixes, open pull requests, and remediate the security debt.

Security teams can monitor the progress of the campaign and track the number of alerts that have been fixed. Using security campaigns, security and developer teams work together with Copilot Autofix to remove security debt in targeted efforts aimed at maximizing impact by focusing on the alerts that matter.

Organization-level view of a security campaign to remediate SQL injection alerts

Security campaigns are available for users of GitHub Advanced Security on GitHub Enterprise Cloud. For more information about security campaigns, see About security campaigns in the GitHub documentation.

If you have any feedback on security campaigns: join the discussion in the GitHub Community.

See more

Copilot Autofix now supports partner code scanning tools

Copilot Autofix now supports fix suggestions for problems detected by ESLint, a partner code scanning tool. Autofixes are available both in pull requests and for historical alerts.

Setting up ESLint using a starter workflow

ESLint is the first partner tool supported by Copilot Autofix. Support for additional partner tools, such as JFrog SAST and Black Duck’s Polaris™ platform powered by Coverity®, will be announced by future changelogs when available. To opt out of fix suggestions for third-party tools, you can disable this feature from the code scanning settings page.

Example of a fix suggestion for an existing ESLint alert

In order for Copilot Autofix to pick up ESLint alerts, you need to enable ESLint as a code scanning tool in the target repository. For reference, you can select an updated starter workflow when setting up a new GitHub Actions workflow in your repository. You can use both ESLint scanning and the CodeQL analysis in the same repository.

Disabling fix suggestions for third-party tools

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

See more

Secret scanning supports delegated bypass for push protection on file uploads (GA)

Secret scanning now supports delegated bypass controls for repository file uploads from the browser.

If delegated bypass is configured for an organization or repository, anyone without bypass permissions will need to submit a bypass request to approved reviewers in order to upload a file that contains a secret. This helps ensure that secrets are not accidentally committed to a repository.

For more information, see “About secret scanning” and “About delegated bypass for push protection.”

See more

Secret scanning support for public leak and multi-repository indicators in webhook and audit log events

Public leak and multi-repository indicators are now 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 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-repo 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-repo 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

Bypass controls for push protection are generally available

Secret scanning bypass privileges for push protection are now generally available.

These controls allow you to choose who is allowed to bypass push protection, and introduce a review and approval cycle for pushes containing secrets from all other contributors. This can ensure push protection blocks are not accidentally bypassed and prevent secrets from being committed to your repositories.

Controls for bypass privileges can be set as part of your organization’s security configurations or at the repository level in your code security settings. You can add specific roles or teams to your bypass list. The individuals in these roles and teams will be able to bypass push protection themselves, and will act as reviewers for any bypass requests submitted by another contributor. The requests can be approved or denied, determining whether the commit can proceed into the repository.

screenshot of bypass privileges within security configurations

Reviewers can view the requests under the Security tab at either the organization level or repository level. Requests can also be accessed through audit log and webhook events.

Learn more about secret scanning and push protection, or join the discussion in the GitHub Community.

See more

Secret scanning: improvements for alerts with known public leaks and enterprise duplicates

You can now view exact locations of known public leaks for a secret scanning alert, as well as any repositories with duplicate alerts across your enterprise. Public leak and duplicate alert labels are now also surfaced via the REST API.

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-repo 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-repo 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

Copilot secret scanning for generic passwords is generally available

Copilot secret scanning is now generally available. Copilot secret scanning, which detects generic passwords using AI, offers greater precision for unstructured credentials that can cause security breaches if exposed. Over 350,000 repositories have already enabled this password detection.

To enable Copilot secret scanning, select “Scan for generic secrets” within your code security and analysis settings at the repository level, or the code security global settings at the organization level. You can also use the Update a repository API endpoint for enablement at the repository level. Support for enablement through your organization’s code security configurations, as well as enablement for organizations and enterprises with the API, will come in a future release.

Password detection is backed by the Copilot API and is available for all repositories with a GitHub Advanced Security license. You do not need a Copilot license to enable generic secret detection. Passwords found in git content will create a secret scanning alert in the “Experimental” tab, separate from regular alerts.

In effort to reduce false positives and detections of secrets that are used in tests, Copilot secret scanning will not:
– detect more than 100 passwords per push
– detect secrets in media files (.svg, .png, .jpeg)
– detect secrets in language files (.js, .py, .ts, .java, .cs, or .rb) that contain test, mock, or spec in the filepath
– detect additional secrets in files where five or more alerts have been marked as false positive

Note that passwords will not be detected in non-git content, like GitHub Issues or pull requests. Passwords are also excluded from push protection, another feature of secret scanning designed to prevent sensitive information from being pushed to your repository.

Learn more about secret scanning and generic secret detection or join our community discussion.

See more

New code security configurations let you set security features at the organization level

Now you can simplify the rollout of GitHub security products within your organization. Code security configurations now allow you to define collections of security settings and apply those settings to groups of repositories. Configurations help you maintain security settings for important features like code scanning, secret scanning, and Dependabot.

As previously announced in August, starting today, you can no longer enable or disable GitHub security features from the organization-level security coverage view, which has been deprecated and replaced with code security configurations for managing these settings.

Learn more about code security configurations and send us your feedback.

See more

Now you can choose a specific branch when using Copilot Autofix for code scanning

When using Copilot Autofix for historical alerts, you can now choose the branch to which you want to commit an autofix. You can also decide whether to then open a pull request, check out the branch locally, or open it in GitHub Desktop.

Copilot Autofix provides automatic fix suggestions for code scanning alerts in your codebase.

Example of committing Copilot Autofix to branch

This update integrates Autofix more closely within the developer workflow, so you can quickly iterate on fix suggestions and collaborate on those with your team.

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

Upcoming replacement of enterprise code security enablement UI and APIs

In the coming months, the current interface for managing code security settings for an enterprise will be deprecated and replaced with new and improved code security configurations that will provide you a more consistent and scalable way to manage security settings across repositories within your enterprise.

The current REST API endpoint to enable or disable a security feature for an enterprise is now deprecated. It will continue to work for an additional year in the current version of the REST API before being removed in September of 2025, but note that it may conflict with settings assigned in code security configurations if the configuration is unenforced, potentially resulting in a security configuration being unintentionally removed from a repository. To change the security settings for repositories at the enterprise level, you can use the current enterprise-level security settings UI or the upcoming code security configurations API.

Send us your feedback!.

See more

Secret scanning non-provider patterns are generally available

Secret scanning support for non-provider patterns is now generally available for all GitHub Advanced Security customers.

Non-provider patterns are generic detectors that help you uncover secrets outside of patterns tied to specific token issuers, like HTTP authentication headers, connection strings, and private keys. You can enable them in your repository’s code security and analysis settings, or through code security configurations at the organization level.

Learn more about secret scanning and non-provider patterns, and join the GitHub Community discussion.

See more

Secret scanning alert lists renamed to “Default” and “Experimental”

The secret scanning alert lists are now named “Default” and “Experimental,” better reflecting the alert categories and making it easier for you to tell experimental alerts from default alerts.

The Default list includes alerts for provider patterns and custom patterns. The Experimental list includes alerts for non-provider patterns and AI-detected passwords. You can view the alert counts of these two lists in the organization-level Security tab in the sidebar, bringing more clarity and visibility into your alerts.

You can filter within the alert list using results:default and results:experimental.

Learn more about secret scanning and the supported patterns.

See more

Code security configurations now support archived repositories

You can now apply code security configurations to archived repositories. This makes it simpler to roll out configurations without having to filter for archived repos, and ensures features like Dependabot, code scanning, and secret scanning are automatically reapplied if a repo is unarchived.

If a repository has configurations applied and later becomes archived, the settings will persist and still apply.

Note: when a repository is archived, the only security feature that will still run is secret scanning. However, if the repository is ever unarchived, all other features in the applied configuration, such as Dependabot or code scanning, will be reapplied automatically.

This release also adds a new filter to the repository table on the code security configurations UI page, allowing you to filter for archived repositories with archived:true.

Learn more about code security configurations, the REST API and send us your feedback.

See more

Secret scanning: on-demand revocation for GitHub PATs (Public Beta)

You can now report compromised GitHub personal access tokens to GitHub, directly from a secret scanning alert. When you let GitHub know that the secret has been compromised, GitHub will treat the token like a publicly leaked token and revoke it. This change simplifies remediation and makes it more easily actionable.

The token owner will receive an email notification when their token is revoked. As a best practice, you should review any associated token metadata and reach out to the token owner, if possible, before reporting the token. Consider rotating the secret first to prevent breaking workflows.

Learn more

Learn more about how to report a compromised GitHub personal access token. Let us know what you think by participating in a GitHub community discussion or signing up for a 60 minute feedback session.

See more

Announcing TISAX for GitHub

GitHub is now a participant in TISAX with an Assessment Level 2 (AL2) label in the ENX Portal. TISAX is a recognized assessment and exchange mechanism for the German automotive industry, ensuring that companies meet specific information security requirements. It is based on the German Association of the Automotive Industry or Verband de Automobile (VDA) Information Security Assessment (ISA) catalog, which aligns most closely with ISO/IEC 27001.

What does this mean for me as a customer?

For our customers, this participation provides additional assurance that GitHub is a trusted partner in managing and securing their data. It opens new opportunities for customers who require TISAX participation to consider using GitHub Enterprise Cloud products, GitHub Copilot, and GitHub Actions.

Participating in the TISAX program at Assessment Level 2 means that GitHub has demonstrated the ability to adequately protect sensitive information in accordance with industry standards. This assessment level focuses on:

  • Information Security: Implementing robust security measures to prevent unauthorized data access and breaches.
  • Risk Management: Continuously identifying, evaluating, and mitigating potential risks to GitHub’s information systems.

The scope of the TISAX assessment, using the newly released VDA ISA version 6, is the same as the GitHub Information Security Management System (ISMS), which has already been assessed against ISO/IEC 27001:2013. To see the scope, you can review GitHub’s ISO/IEC 27001:2013 certification.

Customers who are interested and registered as TISAX participants with ENX can find the details of GitHub’s assessment via the ENX portal by searching for GitHub, our Assessment ID (APC0RT), or our AL2 scope ID (SY52MN).

If you have any questions or need more information about GitHub’s compliance practices, please visit the GitHub Trust Center.

See more
View more changes