platform governance

Subscribe to all “platform governance” 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

CodeQL is the static analysis engine behind GitHub code scanning, which finds and remediates security issues in your code. We’ve recently released version 2.21.1 of CodeQL. Here’s what’s new and improved in this release.

GitHub Actions

  • This CodeQL release coincides with the general availability of support for analyzing GitHub Actions workflows. Learn more in the dedicated changelog post.
  • We’ve improved alert fix suggestions for the actions/missing-workflow-permissions query, making it easier for you to resolve alerts.

JavaScript/TypeScript

  • We’ve added new detections of sources and sinks in Next.js and DOM element references, improving the detection of XSS issues.
  • We’ve enhanced path injection detection for several additional methods.
  • We’ve fixed an issue where tsconfig.json files containing array literals and trailing commas weren’t correctly extracted.

Ruby

  • We’ve improved the rb/useless-assignment-to-local query, so you’ll see fewer false positives and will get helpful documentation for alerts.
  • The rb/uninitialized-local-variable query now only generates an alert when a variable is used as a method call receiver. This should reduce noise. In addition, new help content is available for this query.
  • Calls to super without explicit arguments now have their implicit arguments generated, resulting in more accurate analysis.

For a full list of changes, check out the complete changelog for version 2.21.1. Every new version of CodeQL is automatically deployed to users of GitHub code scanning on github.com. The new functionality in CodeQL 2.21.1 will also be included in GitHub Enterprise Server (GHES) version 3.18. If you’re using an older version of GHES, you can manually upgrade your CodeQL version.

See more

For customers affected by ongoing grace periods, GitHub will automatically update the enable for new repositories security configuration setting for customers not opted out. This change helps you avoid unexpected billing charges without manual effort needed from your part.

Team and Enterprise customers with a configuration applied before April 1, 2025 enabling paid security features for newly created private repositories will see one of the following two changes applied:

  • Configurations with enable for new repositories set to for all public and private repositories will be adjusted to for all public repositories only.
  • Configurations with enable for new repositories set to for all private repositories will be adjusted to for no newly created repositories.

Customers who haven’t yet opted out with a representative from GitHub will see these settings enabled on the follow dates:

  • Team customers will see this change on April 23, 2025.
  • Enterprise customers will see this change on April 28, 2025.

Have questions? Reach out to GitHub for support.

See more

GitHub code scanning now offers enhanced security protection for your GitHub Actions workflow files through CodeQL analysis, which is now generally available. This feature enables you to identify and remediate security vulnerabilities in your Actions workflows through automated code scanning, helping prevent potential security issues before they impact your CI/CD pipeline. CodeQL automatically analyzes your workflows to detect common security vulnerabilities, including missing required permissions, dangerous inputs without proper validation, and script injection vulnerabilities.

During the public preview period, we’ve helped secure over 158,000 repositories, detecting more than 800,000 potential vulnerabilities in Actions workflows, with approximately 15% of these issues being fixed by repository maintainers. This strong adoption demonstrates the value of automated security analysis for CI/CD workflows that use GitHub Actions.

For repositories using code scanning’s default setup, we will now automatically enable Actions workflow analysis when workflow files are detected in the default branch. For repositories using advanced setup, simply add the actions language to your existing configuration to enable this protection.

We’ve also added Copilot autofix functionality for the actions/missing-workflow-permissions query, one of the most frequent findings in Actions workflows. When this vulnerability is detected, you’ll receive automated fix suggestions to implement the principle of least privilege in your workflows, making remediation faster and easier.

To improve analysis quality, we’ve moved the actions/unversioned-immutable-action query to the extended query suite, allowing for more targeted and comprehensive analysis. If you’re using default setup, you can configure your scanning options to include extended queries. For repositories with advanced setup, you can specify this query suite in your CodeQL configuration. You can find more information about this change in the CodeQL release notes for 2.20.6.

Code scanning’s analysis of GitHub Actions workflow files will be available in GitHub Enterprise Server 3.18.

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

See more

With delegated alert dismissal for secret scaning alerts, you can require a review process before alerts are dismissed. This helps you better manage your security risk as well as meet audit and compliance requirements.

Managing alert dismissal requests is now available with the REST API, offering flexibility for triage and reviews by integrating with your existing workflows.

Reviewers can retrieve dismissal requests for an organization or repository with the following endpoints:

Reviewers can review a dismissal request with the following endpoint:

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

See more

When CodeQL scans repositories with Java and/or C# code that depend on packages in private registries—but don’t include those registry addresses in their Maven, Gradle, or NuGet configuration files—the analysis now uses private registry addresses configured at the organization level. This makes it even easier to roll out CodeQL’s Java and C# analysis at scale.

Last year we enabled CodeQL build-mode: none scans to access private dependencies stored in private registries (e.g. Artifactory) for Java and C# projects. This required the addresses of the private registry to be defined in the project configuration. With this change, projects that relied on configurations defined in the build systems or locations external to the project will be able to use private registries.

This makes your scans more comprehensive, ensuring you receive all important alerts regardless of where your dependencies are stored.

This officially marks the end of the preview phase for CodeQL Java/C# private registry support; this feature is now generally available on GitHub.com. It will also roll out with GitHub Enterprise server version 3.18.

See more

CodeQL version 2.21.0 has been released and includes TypeScript 5.8 support, a new Java query to detect exposed Spring Boot actuators, and support for new JavaScript libraries.

TypeScript 5.8 support

CodeQL can now analyze code written in TypeScript version 5.8, helping you find and automatically remediate security issues in the latest TypeScript projects, all without additional configuration.

Improved Java analysis

The community-contributed query java/spring-boot-exposed-actuators by @ggolawski has been promoted out of experimental status and is now included in the default code scanning query pack. This query helps you identify publicly accessible Spring Boot actuators, preventing unintended information disclosure.

Expanded JavaScript framework coverage

We’ve extended our JavaScript analysis to include popular modern frameworks and libraries:

  • Apollo Server: Added support for analyzing data coming from GraphQL when using @apollo/server.
  • React Relay: Added analysis support for React applications using the react-relay library.
  • SAP ecosystem: Added CodeQL support for analysis of SAP packages, including @sap/hana-client, @sap/hdbext, and hdb.
  • TanStack: Added support for analyzing applications using the @tanstack/angular-query-experimental package.

For a full list of changes, please refer to the complete changelog for version 2.21.0. Every new version of CodeQL is automatically deployed to users of GitHub code scanning on github.com. The new functionality in CodeQL 2.21.0 will also be included in GitHub Enterprise Server (GHES) version 3.18. If you use an older version of GHES, you can manually upgrade your CodeQL version.

See more

Push rules are great for maintaining the integrity of your codebase by preventing unauthorized changes to critical files such as actions workflows. However, they can sometimes slow down the development process. With delegated bypass, developers can easily request exceptions to these push rules. This process is reviewed and audited within GitHub, helping to ensure that every exception is properly documented and approved.

We are also bringing a preview of the delegated bypass flow to repository policies. This provides additional reviews when deleting repositories as well as visibility changes to prevent accidents and help ensure good governance.

Finally we’re also introducing regex support for custom properties.

Push rule delegated bypass

Unlock efficiency with our push rule delegated bypass. Now, developers can:

  • Request push rule exceptions directly within GitHub.
  • Ensure every request is reviewed and audited for maximum transparency.
  • Receive notifications via email for real-time updates on approval status.

Learn more about push rule delegated bypass in the documentation.

Repository policy delegated bypass in preview

Extend the delegated bypass functionality to your repository policies. This feature is designed to:

  • Offer additional reviews for critical actions such as deleting repositories or changing visibility settings.
  • Prevent accidental changes that could compromise your project.
  • Submit bypass requests directly from the repository’s danger zone.

Learn more about repository policy delegated bypass in the documentation.

Custom properties regular expression matching

When using Text types for custom properties you can require new values to match a regular expression pattern, like an email address.

  • Test your regex pattern against sample values from the new property creation screen.
  • Supports the RE2 syntax, for more information see the syntax guide.

Join the discussion and share your feedback, questions, and thoughts within our GitHub Community discussion.

See more

Security campaigns are now generally available

Security campaigns with Copilot Autofix are now generally available. As part of GitHub Code Security, you can use security campaigns to prioritize and rapidly reduce your backlog of application security debt. Copilot Autofix generates contextual explanations and fixes for historical code scanning alerts in a security campaign, which help developers and security teams collaborate to fix vulnerabilities with speed and confidence.

With the help of GitHub’s CodeQL and Copilot Autofix, it has never been easier to prevent new vulnerabilities from being added to your code. However, if you don’t address vulnerabilities discovered in already-merged code, security debt can build up and pose a serious risk to deployed applications.

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, and developers who are most familiar with the code are notified. From there, they can review the fixes, open pull requests, and remediate security debt. Security teams can monitor the progress of the campaign and track the number of fixed alerts. 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.

Starting today, you can also access these new features to plan and manage security campaigns more effectively:

  • Draft security campaigns: Security managers can now iterate on the scope of campaigns and save them as draft campaigns before making them available to developers. With draft campaigns, security managers can ensure that the highest priority alerts are included before the work goes live.
  • Automated GitHub issues: Security managers can optionally create GitHub issues in repositories that have alerts included in the campaign. These issues are created and automatically updated as the campaign progresses and can be used by teams to track, manage, and discuss campaign-related work.
  • Organization-level security campaign statistics: Security managers can now view aggregated statistics showing the progress across all currently-active and past campaigns.

Security campaigns are available for users of GitHub Code 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 GitHub Community.

See more

GitHub’s dependency graph now supports a wider range of package ecosystems, including transitive path information and the registered name of the ecosystem. This change increases the accuracy and usefulness of GitHub’s dependency insights, SBOMs, and API results.

The Package URL project provides a registry of software package ecosystems, with a standardized format for package type, namespace, version, and human-readable identifiers. With this release, graphs posted to the dependency submission API that include purl identifiers will now:

  • Correctly preserve transitive and direct relationships, if they were submitted.
  • Show the package ecosystem name in the Dependency Graph insights page.
  • Include the submitted package url in the GraphQL DependencyGraphDependency object, in the field packageUrl.

For searching and filtering, note that the top-level ecosystem type for all purl-identified packages is now other. These packages used to have the unknown type.

To begin using this feature, add a dependency submission action for a purl-supported package ecosystem you’re using in your repository. Then navigate to the repository’s Insights tab and select Dependency graph.

The dependency graph insights page, showing an ecosystem filter of other with three packages in a list.

See more

Secret Protection and Code Security here for GitHub Enterprise

At GitHub, we believe that investing in the security of your codebases should be straightforward, affordable, and scalable. Today, we’re rolling out standalone GitHub Advanced Security products for GitHub Enterprise customers. This aligns with our ongoing mission to help organizations of all sizes secure their code with the flexibility they seek.

Getting started as an existing GitHub Advanced Security customer

Existing GitHub Advanced Security customers with plans subscription-based plans can choose to transition at renewal. Customers with pay-as-you-go, metered-based plans can transition at any time. Please reach out to your GitHub or Microsoft sales account team for details.

Customers on subscription billing can migrate to either a standalone subscription or a standalone metered plan. For pricing details, please contact your account representatives.

How do I right-size enablement for my enterprise?

Customers transitioning before May 2025 can work with their account teams on right-sizing enablement for their enterprise across both Secret Protection and Code Security. All repositories will have both Secret Protection and Code Security enabled at the time of transition, regardless of your contractual plan.

Customers on contractual plans limited to secret scanning features will be able to optionally choose to transition with only Secret Protection enabled (and Code Security disabled) for their enterprise starting in May 2025.

When will the standalone plans be available for Enterprise Server?

Standalone SKUs will be available for Enterprise Server customers starting with GHES 3.17. To use metered billing, GitHub Connect is required.

Getting started as an existing GitHub Advanced Security self-serve customer

For existing self-serve customers, instructions on how to transition to the new GitHub Advanced Security plans will be announced over the next 30 days. You’ll receive an email notification when the new plans are available to your enterprise. Transitioning to the standalone plans will be self-serve and optional.

Getting started for new customers

Starting today, GitHub Enterprise customers without an existing GitHub Advanced Security plan can self-serve purchase both Secret Protection and Code Security. To get started, admins can navigate to Advanced Security under their enterprise, organization, or repository settings. From this page, you can choose to enable and purchase Secret Protection or Code Security features.

Learn more about enabling GitHub Advanced Security for your enterprise.

Trialing GitHub Advanced Security

You can try the new standalone SKUs before committing. Contact your account team for more details. Alternatively, you can get started with a GitHub Enterprise trial.

Talk to someone from GitHub

In addition, Enterprise customers are welcome to reach out to their existing account team or request a demo from someone at GitHub.

Learn more and share feedback

Learn more about Secret Protection and Code Security, or share feedback by joining the discussion in GitHub Community.

See more

Secret risk assessment

GitHub is committed to empowering the developer community by helping organizations recognize and address the risks of secret leaks. That’s why we’re launching a new free tool which will help provide clear insights into your organization’s exposure, along with actionable steps to strengthen your security and protect your code.

Starting today, you can scan your organization for aggregate insights on public leaks, private exposures, and token types.

Find secrets in your organization

What will this dashboard include?

Available in the Security tab, organization and security admins will be able to run a scan to understand how their organization is affected by secret leaks and exposures. Once a scan is initiated, GitHub will look for secret leaks and exposures across your organization, returning a collection of insights including:

  • The number of secrets leaked per type.
  • The number of publicly visible secrets in your public repositories.
  • The number of repositories affected for each secret type.

No specific secrets will be stored or shared.

Once enabled, GitHub will run a point-in-time scan across all public, private, internal, and archived repositories in your organization. Results are static and will not be automatically updated. You’ll also be able to download results as a CSV file.

For organizations ready to adopt a continuous monitoring tool, we recommend enabling secret scanning for detection and incident management of specific secrets. Learn more about GitHub Secret Protection.

Why are we doing this?

GitHub is committed to making a meaningful impact on the developer community by helping organizations recognize their secret leak footprint across their GitHub perimeter. Our goal is to provide clear insights into organizations’ potential secret exposure and a clear path to stronger security.

Who can use this feature?

This feature will be available for free to organizations with a GitHub Team or Enterprise plan. Organization admins and security managers will be able to run the report and review any results. This feature will be available for Enterprise Server starting with GHES 3.18.

Share feedback while the feature is in public preview

This feature is available in public preview and is subject to improvement. Have feedback? Let us know what you think by joining our discussion in GitHub Community — we’re listening.

See more

Here for GitHub Team plans

At GitHub, we believe that investing in the security of your codebase should be accessible for organizations of all sizes.

Starting today, GitHub Team plan customers can purchase GitHub Secret Protection and GitHub Code Security without upgrading your organization to GitHub Enterprise. This makes it easier to secure your codebase with GitHub Advanced Security products.

GitHub Secret Protection

GitHub Team organizations can purchase GitHub Secret Protection, which detects and prevents secret leaks (e.g. secret scanning, AI-detected passwords, and push protection for secrets).

Secret Protection will be available for $19 per month per active committer, with features including:

  • Push protection, to prevent secret leaks before they happen.
  • AI detection with a low rate of false positives, so you can focus on what matters.
  • Secret scanning alerts with notifications, to help you catch exposures before they become a problem.
  • Custom patterns for secrets, so you can search for sensitive, organization-specific information.
  • Security overview, which provides insight into distribution of risk across your organization.
  • Push protection and alert dismissal enforcement for secrets, which supports governance at enterprise scale.

In addition, we’re launching a new scanning feature to help organizations understand their secret leak footprint across their GitHub perimeter. This feature is free for GitHub Team organizations.

GitHub Code Security

GitHub Team organizations will also be able to purchase Code Security, which detects and fixes vulnerabilities in your code before it reaches production.

Code Security will be available for $30 per month per active committer, with features including:

  • Copilot Autofix for vulnerabilities in existing code and pull requests to provide developer-first security management.
  • Security campaigns to address security debt at scale.
  • Dependabot features for protection against dependency-based vulnerabilities.
  • Security overview, which provides insight into the distribution of risk across your organization.
  • Security findings for third-party tools.

Get Started

To get started, admins can navigate to Advanced Security under their organization or repository settings. From this page, you can choose to enable and purchase Secret Protection or Code Security features.

For example, from your organization settings, you can navigate to Security / Advanced Security / Configurations in order to create a new configuration with Secret Protection features enabled. Learn more about enabling GitHub Advanced Security.

In addition, admins can enable Secret Protection features in one click from their organization’s Security tab. Once the secret risk assessment has been run for your organization, you’ll be able to enable Secret Protection in one click from the system banner.

Purchase Secret Protection from your organization's risk assessment

Learn more about Secret Protection and Code Security, or share feedback by joining the discussion in GitHub Community.

See more

GitHub’s Payment Card Industry Data Security Standard (PCI DSS) v4.0 service provider Attestation of Compliance (AoC) as well as the corresponding shared responsibility matrix has been completed. This report is the first time GitHub has provided a PCI DSS service provider report for our customers. This enables customers to meet their own PCI DSS compliance needs using GitHub as part of their development environment.

Going forward, GitHub intends to provide this attestation of compliance each year.

If you’re an Enterprise customer and need to obtain copies of GitHub’s AoC or Shared Responsibility Matrix, please reach out to your account manager.

See more

Keep control over the security posture of your organization with delegated alert dismissal. With this feature, you can require a review process before alerts are dismissed in code scanning and secret scanning. This helps you manage security risk better, as well as meet audit and compliance requirements.

While this feature adds oversight and control, organizations should carefully balance security needs with development velocity. Things to consider include:

  • Who can close alerts
  • When and how alerts should be closed
  • Who should review and approve dismissal requests.

This feature can be configured and managed at scale using security configurations or at the repository level.

Each dismissal request requires a mandatory comment explaining the rationale, with email notifications sent to both approvers and requesters throughout the process. If rejected, the alert remains open.

People with the organization owner or security manager role can review and approve dismissal requests by default. The state of previously dismissed alerts does not change when enabling this feature.

The dismissal and approval process is visible on the alert timeline, included on the audit log, and accessible through both the REST API and webhooks.

You can enable this feature today for code scanning and secret scanning in GitHub Enterprise Cloud. It will also be available in version 3.17 of GitHub Enterprise Server.

See more

Find secrets in your organization with the secret risk assessment

GitHub is committed to empowering the developer community by helping organizations recognize and address the risks of secret leaks. That’s why we’re launching a new free tool next month which will provide clear insights into their exposure, along with actionable steps to strengthen their security and protect their code.

Scan your organization for aggregate insights on public leaks, private exposures, and token types.

The secret risk assessment provides insights about secret leak exposures

When will this feature be available?

The secret risk assessment will be available on April 1, 2025 as part of the launch of Secret Protection for GitHub Team and Enterprise plans.

What will this dashboard include?

Available in the ‘Security’ tab, organization and security admins will be able to run a scan in order to understand how their organization is affected by secret leaks and exposures. Once a scan is initiated, GitHub will look for secret leaks and exposures across your organization, returning a collection of insights including:

  • Number of secrets leaked per type
  • Number of publicly visible secrets in your public repositories
  • Number of repositories affected per secret type

No specific secrets will be stored or shared. The scan will be a point-in-time assessment across all public and private repositories. For organizations ready to adopt a continuous monitoring tool, we recommend enabling secret scanning for detection and incident management of specific secrets.

Why are we doing this?

We’re launching this feature to help organizations understand their secret leak footprint across their GitHub perimeter.

GitHub is committed to making a meaningful impact on the developer community by helping organizations recognize their risk from secret leaks. Our goal is to provide clear insights into their exposure and a clear path to stronger security.

Who can use this feature?

This feature will be available for free to organizations with a GitHub Team or Enterprise plan. Organization admins and security managers will be able to run the report and review any results.

To learn more about the launch of GitHub Secret Protection, please refer to this changelog. Have questions? Let us know what you think by starting a discussion in GitHub Community — we’re listening.

See more