advanced-security

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

Removing hardcoded secrets detection from CodeQL

Starting May 30, 2025, CodeQL will no longer generate code scanning alerts for hardcoded secrets. Instead, we recommend using secret scanning to detect hardcoded secrets in your repositories, which has greater precision and recall than CodeQL. Secret scanning is a feature of GitHub Secret Protection.

Learn more about secret scanning, which scans your repositories for over 300 hardcoded secrets and uses Copilot to detect generic passwords. By using this detection instead of CodeQL, all your alerts for hardcoded secrets can be managed in one place.

What’s changing?

We’re disabling CodeQL detection of hardcoded secrets on May 30, 2025. This aligns with the release of CodeQL 2.21.4. We’ll post a follow-up notice to the GitHub changelog when this is complete. Once these checks are disabled, the next time your repository is analyzed using CodeQL, any code scanning alerts for hardcoded secrets will close. These alerts will stay in your historical security alert backlog.

These changes will also be included with GHES 3.18.

The following CodeQL queries will be disabled:

  • js/hardcoded-credentials
  • swift/hardcoded-key
  • swift/constant-password
  • cs/password-in-configuration
  • cs/hardcoded-credentials
  • js/password-in-configuration-file
  • py/hardcoded-credentials
  • go/hardcoded-credentials
  • rb/hardcoded-credentials
  • cs/hardcoded-connection-string-credentials
  • java/password-in-configuration

Why are we doing this?

The hardcoded secrets queries in CodeQL are redundant to the capabilities of secret scanning, which can result in duplicate alerts for the same secret. This creates unnecessary effort spent on manual deduplication of secret scanning and code scanning alerts. Secret scanning has superior accuracy and recall for detecting hardcoded secrets and provides additional metadata that’s helpful for remediation.

How do I get started?

Check out this introduction to getting started with GitHub Secret Protection:

Watch this video to learn more about deploying and managing Secret Protection at scale:

See more

Dependabot version updates now support Helm

Developers can now use Dependabot to automatically keep their Helm dependencies up to date. For projects that use Helm as a package manager, Dependabot version updates can now ensure dependencies stay current with the latest releases.

See more

Security campaigns are now generally available to help address security debt at scale

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

Dependency graph supports all purl-identified package ecosystems

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

GitHub Secret Protection and GitHub Code Security for GitHub Enterprise

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

Find secrets exposed in your organization with the secret risk assessment

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

GitHub Advanced Security is here for GitHub Team organizations

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

Transitive dependencies are now available for Maven

Following the ship of transitive labeling for npm packages, the same capabilities are now available for Maven packages:

  • Dependabot alerts now contain a direct label if they are associated with a package you’ve directly included. In addition, there’s now a relationship:direct filter in the search bar to only show those alerts caused by your direct dependencies.
  • The direct dependency that led to a package’s inclusion in your dependency graph is visible both in the text of any new Dependabot alerts and the dependency insights page (click the … button, then Show options to view it).
  • A repository’s SBOM will contain a relationships section that uses the SPDX relationshipType: DEPENDS_ON field to express the tree of package dependencies. Similarly, the GraphQL API will now return a relationship field with direct, transitive, or unknown values in the DependencyGraphDependency object.

Ability to refresh Dependabot alerts from the list view

In addition to the Maven-specific additions, the Alert Settings menu on Dependabot alert tables now provides a Refresh Dependabot alerts option which will rescan your repository’s manifest files, rebuild its dependency graph, and refresh its open Dependabot alerts.

New 'Refresh Dependabot alerts' option in the Alert Settings menu on the Dependabot alerts page.

Getting started

To get transitive dependency labeling on your repositories, make sure dependency graph is enabled, and either enable Automatic dependency submission on the same settings page or use a dependency submission action. As a beneficial side-effect of this change, other package ecosystems with actions that create transitive dependency trees – such as go – will also now receive transitive and direct labels.

To see the Dependabot labels, you’ll also need to enable Dependabot alerts.

Join the discussion within GitHub Community.

See more

Dependabot version updates now support uv in general availability

Developers can now use Dependabot to automatically keep their uv dependencies up to date. For projects that use uv as a package manager, Dependabot version updates can now ensure dependencies stay current with the latest releases.

See more

Renaming secret scanning experimental alerts to generic alerts

Alerts for non-provider patterns and Copilot-detected passwords are now categorized as generic instead of experimental. This change applies to alert filters and the secondary inbox in your alert list views.

Non-provider patterns and Copilot secret scanning were made generally available in October 2024, after careful iteration to reach the level of quality you’ve come to know and expect from provider-based patterns. These alerts are not considered experimental and should be remediated in accordance with your organization’s standard policies.

Detection for these secret types are available for repositories with a GitHub Advanced Security license. They can be enabled through your repository settings or organization and enterprise code security configurations.

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

See more

CodeQL adds support for Java 24 and other improvements in version 2.20.6

CodeQL is the static analysis engine behind GitHub code scanning, which finds and remediates security issues in your code. We’ve recently released CodeQL 2.20.6, which brings support for a new version of Java and a variety of other improvements that improve the accuracy of your code scanning results:

Java

  • CodeQL now supports Java version 24
  • We’ve improved the accuracy of the (java/xss) query when javax.servlet.http.HttpServletResponse is used without an exploitable content type

JavaScript / TypeScript

  • We’ve added support for the response threat model, which can be enabled with advanced setup. When enabled, the response data coming back from an outgoing HTTP request is considered a tainted source.
  • We’ve improved the precision of data flow through arrays and call resolution logic, both resulting in improved analysis results

C/C++

  • We’ve improved the accuracy of the cpp/static-buffer-overflow query, resulting in improved results

C#

  • We’ve improved the precision of the cs/call-to-object-tostring query, resulting in improved analysis results

GitHub Actions (Public Preview)

  • We’ve removed the query actions/unversioned-immutable-action from the public suite of queries, which will close any alerts triggered from it

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

See more

Delegated alert dismissal for code scanning and secret scanning now available in public preview

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

Introducing GitHub Secret Protection and GitHub Code Security

GitHub Advanced Security: Introducing GitHub Secret Protection and Code Security

At GitHub, we believe that investing in the security of your codebases should be straightforward, cost-effective, and accessible for everyone. Today, we’re announcing changes to pricing plans and availability of GitHub Advanced Security (GHAS), aligning with our ongoing mission to help organizations of all sizes secure their code with the flexibility they seek.

Announcing new pricing plans for GitHub Advanced Security

Starting April 1, 2025, GitHub Advanced Security will be available as two standalone security products: GitHub Secret Protection and GitHub Code Security. In addition, these products will become available to GitHub Team plan customers for the first time.

GitHub Secret Protection

New customers can purchase GitHub Secret Protection, which includes features that help detect and prevent 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 will be free for GitHub Team and Enterprise organizations.

GitHub Code Security

New customers 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 for 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 distribution of risk across your organization
  • Security findings for third-party tools

Availability for GitHub Team customers

Starting April 1, 2025, customers on the GitHub Team plan can purchase Secret Protection and Code Security. These products will be available through a consumption-based, pay-as-you-go model (i.e., metered billing) to ensure security remains affordable, scalable, and accessible for all customers on GitHub.

Get started today

Existing customers with plans managed with a GitHub or Microsoft sales account team can transition to the new GitHub Advanced Security plans at start time of renewal for renewal dates after April 1, 2025. Please contact your account team for further details. For existing self-serve customers, instructions on how to transition to the new GitHub Advanced Security plans will be announced over the coming months through GitHub’s roadmap and changelog.

GitHub Team customers can choose to purchase Secret Protection or Code Security from their organization settings pages starting April 1, 2025.

If you have any feedback, join the discussion in GitHub Community.

See more

Find secrets in your organization with the secret risk assessment

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

Easily distinguish between direct and transitive dependencies for npm packages

npm’s massive ecosystem of open source packages is one of its greatest strengths. But as a security-conscious developer, it can be tough to keep up with vulnerability reporting and updates once your project has more than a handful of dependencies, each of which has its own set of dependent packages. Dependabot notifies you of vulnerabilities and their fixes as they come in. Unfortunately, it’s hard to distinguish actionable alerts about direct dependencies you’ve added to your manifests from those transitive dependencies that were pulled in along the way… until now, that is.

GitHub’s dependency graph now tracks direct and transitive dependencies for npm packages. This helps you triage, prioritize, and remediate your Dependabot alerts. This capability shows up in user-facing features across the site:

  • Dependabot alerts will now contain a direct label if they are associated with a package you’ve directly included in a manifest. You can filter the list of alerts down to only these direct ones with the relationship:direct filter in the search bar.
  • Alerts for transitive dependencies now show transitive path information – the chain of packages which led from your direct dependency to the transitive one which has the vulnerability.
  • A repository’s dependency graph now distinguishes between direct and transitive relationships. Direct dependencies will have a label in the table UI, whereas indirect dependencies have a disclosure menu that shows the transitive path which led to their inclusion.
  • A repository’s SBOM will contain a relationships section that uses the SPDX relationshipType: DEPENDS_ON field to express the tree of package dependencies. Tools like guac.sh can help explore and visualize this tree.
  • The GraphQL API will now return a relationship field with direct, transitive, or unknown values in the DependencyGraphDependency object. See the API documentation for details.

A table of Dependabot alerts can now be filtered to show only direct dependencies

We started with npm because it’s the most popular package ecosystem in the known universe, but it’s just the beginning. Over the next few months, package types for other programming languages will also get the transitivity treatment. Up next: Maven packages for Java.

To try this out, you’ll need to make sure the dependency graph is enabled. To see the Dependabot labels, you’ll also need to enable Dependabot alerts. If the “Direct” labels aren’t showing up for you immediately, push a commit that updates one of your manifest files, which will trigger an update of the dependency graph.

Join the discussion within GitHub Community.

See more
View more changes