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

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.

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

Scaling your GitHub usage just got easier! We are expanding our pay-as-you-go usage-based billing and licensing reporting interface to include GitHub Enterprise (GHE) and GitHub Advanced Security (GHAS) Server-only usage.

We announced pay-as-you-go billing for GHE and GHAS on August 1, 2024 to give customers flexible self-provisioning and pricing. Since then, enterprise accounts on github.com created on or after that date could generate a GitHub Enterprise Server key for the appropriate license count when license adjustments were needed. This required all users, including Server-only users, to be represented in the enterprise account’s user list on GitHub Enterprise Cloud.

Now, you can track and monitor your Server-only license usage for both Enterprise and Advanced Security as a separate line item on the Billing & Licensing > Licensing page.

Note that it will still be required to add all Server-only users to your GitHub Enterprise Cloud enterprise user list to account for their license usage and generate a license key with the appropriate license count. This update does not change this compliance requirement.

Enterprise Server summary in licensing

For existing customers who already have GHE or GHAS, your plan and existing billing method will remain as-is.

If you are interested in pay-as-you-go usage-based billing and have a GitHub account team, please connect with them to discuss whether switching to this model is an option for you.

Check out our documentation to learn more about usage-based billing for licenses.

See more

CodeQL version 2.20.5 has been released and includes a host of coverage improvements, including extended support for C# 13 and new detection capabilities for Java and GitHub Actions workflow files.

CodeQL is the static analysis engine that powers GitHub code scanning, which finds and remediates security issues in your code.

CodeQL 2.20.5 adds full support for new language features introduced in C# 13 / .NET 9, as well improved coverage for .NET 9. This will improve the detection of alerts and reduce the chance of false negative results.

CodeQL Java analysis is improved with additional support for Cross Site Request Forgery (CSRF). The new analysis capability detects vulnerabilities that occur when using HTTP request types that are not protected against cross site requests by default.

Go analysis has been updated to support Go 1.24, which includes new language features and improvements. This will improve the detection of alerts and reduce the chance of false negative results.

For a full list of changes, please refer to the complete changelog for version 2.20.5. Every new version of CodeQL is automatically deployed to users of GitHub code scanning on GitHub.com. The new functionality in CodeQL 2.20.5 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

We recently launched analysis capabilities for GitHub Actions workflow files in public preview.

With the release of CodeQL 2.20.5, we are expanding the analysis capabilities to detect additional types of security risks associated with Actions workflow files and we have adjusted some of the existing queries.

The analysis coverage is improved with the addition of five new queries that identify additional types of security risks associated with Actions workflow files. The new queries are:

  • actions/envpath-injection/medium detects situations where user-controlled sources (like the text of a GitHub issue) are used to populate the PATH environment variable. This could allow an attacker to alter the execution of system commands.
  • actions/envvar-injection/medium detects situations where environment variables which are not properly sanitized can lead to the injection of additional unwanted variables, using new lines or {delimiters}.
  • actions/code-injection/medium– detects situation where user-controlled input can end up in contexts like run: or script:, leading to malicious code being executed and secrets being leaked.
  • actions/artifact-poisoning/medium detects situations where artifacts are not correctly extracted, stored and verified, which could result in a poisoned artifact being executed, leading to repository compromise.
  • actions/untrusted-checkout/medium detects situations where workflows triggered by events like pull_request_target or issue_comment can execute arbitrary code from untrusted sources, if followed by an explicit checkout.

Because of its lower precision and the large number of alerts it generates, the query actions/unpinned-tag has been moved to the security-extended query suite from the default query suite, and all existing alerts for this query will be automatically closed if the security-extended suite is not being used.

Three queries have been removed from the default and security-extended query suites because they do not produce relevant security alerts. Alerts generated by these queries will be closed automatically.

These changes are now available with the release of CodeQL 2.20.5. For a full list of changes, please refer to the complete changelog for version 2.20.5. Every new version of CodeQL is automatically deployed to users of GitHub code scanning on GitHub.com. The new functionality in CodeQL 2.20.5 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

Push protection for secret scanning blocks any push that contains a secret. By default, this block can be bypassed, which results in a secret scanning alert in the repository. Delegated bypass controls let you choose who is allowed to bypass push protection, and contributors without permissions to bypass must submit a request for approval by the listed reviewers. These controls can reduce the risk of secrets being accidentally exposed in your codebase.

Managing bypass requests is now available with the REST API, offering flexibility for triaging and reviewing by integrating with your existing workflows.

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

Reviewers can review a request and dismiss a response to a request with the following endpoints:

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

See more

Now it is easier to see how many of your historical CodeQL alerts received autofix suggestions and how many of those alerts were resolved across all the repositories in your organization.

Historical alerts are those found in your default and protected branches, indicating potential existing security issues in your code. You can stay informed about the progress of historical alert resolution and expediting this process as it is essential for accurately assessing your security risks.

Screenshot of total alerts fixed with an accepted autofix out of all with a suggested autofix.

The new “Alerts fixed with autofix suggestions” tile on the Security Overview provides you with the total number of fixed vulnerabilities compared to the total suggested autofixes for existing alerts. This will help you stay informed about the security trends in your organization.

Learn more about Copilot Autofix for CodeQL code scanning and security overview.

To leave feedback for Copilot Autofix for code scanning, join the discussion.

See more

Copilot secret scanning, which scans for passwords using AI, offers greater precision for detecting unstructured credentials that can cause security breaches if exposed.

You can now use code security configurations to enable Copilot secret scanning across your enterprise or organization, allowing you to control which repositories are detecting passwords at scale.

Copilot secret scanning is available for all repositories with a GitHub Advanced Security license. You do not need a Copilot license. To give you control over how AI is used across your repositories, Copilot secret scanning is not included in the GitHub Recommended configuration.

Learn more about protecting your repositories with secret scanning and generic secret detection.

See more

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

See more

Copilot Autofix helps you fix code scanning alerts and avoid introducing new security vulnerabilities by using large language models to suggest potential fixes.

We recently expanded the range of CodeQL security alerts where Copilot can suggest an autofix, covering a group that accounts for 29% of all CodeQL alerts. This expansion led to an 8% overall increase in alerts with an available autofix and a 270% increase in autofixes for this specific group of improved alerts. With more autofix suggestions, you can resolve security issues identified by CodeQL more easily—either by applying Copilot’s suggested fix directly or using it as a starting point for your own edits.

We made these improvements by analyzing our usage data to understand the most common types of alerts where Copilot was not suggesting fixes and then made a targeted effort to improve autofix for these alerts. Read more about the testing process that GitHub uses to identify the quality of autofix suggestions.

We continuously evaluate the performance of CodeQL and Copilot Autofix, so look for more improvements in the future.

See more

Dependabot alerts now feature the Exploit Prediction Scoring System (EPSS) from the global Forum of Incident Response and Security Teams (FIRST), helping you better assess vulnerability risks.

EPSS scores predict the likelihood of a vulnerability being exploited, with scores ranging from 0 to 1 (0 to 100%). Higher scores mean higher risk. We also show the EPSS score percentile, indicating how a vulnerability compares to others.

For example, a 90.534% EPSS score at the 95th percentile means:

  • 90.534% chance of exploitation in the next 30 days
  • 95% of other vulnerabilities are less likely to be exploited

You can use EPSS scores to help prioritize dependency vulnerabilities based on exploit likelihood. Only ~0.5% of vulnerabilities have an EPSS score above 50%. This makes EPSS a powerful tool for prioritization based on exploitation likelihood, especially when used in conjunction with exploitation severity (CVSS). For more information on using EPSS and/or CVSS for vulnerability prioritization, check out FIRST’s EPSS user guide.

This feature is available on GitHub.com today, and will be available in GitHub Enterprise Server staring with version 3.17.

Learn more in FIRST’s EPSS User Guide.
Join the discussion within GitHub Community.
Read more about viewing, sorting, and filtering Dependabot alerts in GitHub’s Dependabot docs.

See more

We released a collection of improvements to Artifact Attestations to make the verification of attestations easier and more consistent.

Artifact Attestations let you create provenance signatures, which provide an unforgeable paper trail that links your artifact back to its originating workflow run. By verifying the signature, you can gate deployments to ensure that what you deploy is exactly what you built, guaranteeing that the artifact has not been tampered with.

Today we are announcing multiple improvements based on the user feedback we have received:

  • Attestation verification defaults to build provenance: Build provenance is just one type of information that can be attested to an artifact. It provides a verifiable trail that links the artifact back to its originating workflow run, ensuring its authenticity and integrity. However, other types of information can also be attested to an artifact, for example a Software Bill of Materials (SBOM). Attestations can be verified by running gh attestation verify using the GitHub CLI. Previously, verification succeeded as soon as there was any attestation associated with the artifact. However, we observed that provenance is verified in the vast majority of cases. Therefore, we altered the CLI to default to provenance when no predicate type is specified. This change ensures that verification does not pass merely because, for example, an SBOM was attested to the artifact. To verify an SBOM, the predicate type must be explicitly supplied as a parameter using gh attestation verify with the --predicate-type parameter.
  • CLI outputs evaluated policies during verification: When verifying an attestation, the CLI now outputs all the policies it evaluated to determine whether the verification succeeds or fails. This increases transparency, making it easier to understand the reasons behind the verification outcome.
  • Attest actions support multiple subjects: Following the release to support attesting multiple subjects, we have enhanced our attest, attest-build-provenance and attest-sbom actions to also accept a checksum file that contains a list of artifacts and their corresponding digests as input.
  • Attestation verification is now monotonic: This means that once verification passes for an artifact, the addition of another attestation cannot change that status. Verification now succeeds if at least one attestation passes verification. This ensures that downstream processes, such as gated deployments, are not affected for any legitimate build that has a valid provenance attestation, even if someone adds another attestation that is bad or malformed.

For more information about Artifact Attestations, see Using artifact attestations to establish provenance for builds in the GitHub documentation. If you have any feedback on Artifact Attestations, join the discussion in the GitHub Community.

See more

GitHub continually updates its detectors for secret scanning with new patterns and upgrades of existing patterns, ensuring your repositories have comprehensive detection for different secret types.

GitHub now automatically detects Base64-encoded secrets for the following token types:

  • GitHub personal access tokens
  • GitHub OAuth access tokens
  • GitHub user to server tokens
  • GitHub server to server tokens.

GitHub secret scanning protects users by searching repositories for known types of secrets such as tokens and private keys. By identifying and flagging these secrets, our scans help prevent data leaks and fraud. See the full list of supported secrets in the documentation.

Learn more about secret scanning or join the discussion on our dedicated GitHub community.

See more

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

Support for bun security updates will be added in the future.

See more

CodeQL is the static analysis engine behind GitHub code scanning, which finds and remediates security issues in your code. The CodeQL engine has become faster, covers 28 more security queries, supports more ecosystems, and can now scan GitHub Actions (public preview)—among various other bug fixes and small improvements.

All of these improvements were automatically rolled out to code scanning users in the past few months. For users of the CodeQL CLI, here are some highlights of the past few CodeQL releases:

  • CodeQL 2.20.46 February 2025
    • Analysis support for GitHub Actions workflow files is now in public preview, and therefore the use of the actions language (for analysis of GitHub Actions workflows) no longer requires the CODEQL_ENABLE_EXPERIMENTAL_FEATURES environment variable to be set.
    • All experimental queries for C#, Java, and Kotlin have been migrated to the default query suite in the CodeQL community packs that are managed by GitHub Security Lab.
  • CodeQL 2.20.324 January 2025
    • Resolves a security vulnerability where CodeQL databases or logs produced by the CodeQL CLI may contain the environment variables from the time of database creation. This includes any secrets stored in an environment variables. For more information, see the CodeQL CLI security advisory.
  • CodeQL 2.20.222 January 2025
    • All data flow queries have been standardized on a single data flow library, which may result in differences for JavaScript and TypeScript analysis.
    • CodeQL databases now take 2-3x less space on disk, which makes them faster to transfer and read/manipulate. This is thanks to a new compressed database format.
  • CodeQL 2.20.19 January 2025
    • CodeQL is now easier to set up and roll out: automatic build command detection with automatic dependency installation for C/C++ is now supported on Ubuntu 24.04.
    • A new Server Side Template Injection query for Python has been released, thanks to a community contribution.
    • Swift 6.0.2 is now supported.
  • CodeQL 2.19.42 December 2024
  • CodeQL 2.19.37 November 2024
    • Analysis for .NET 8 and JDK 17 has been improved.
    • The CodeQL Bundle is now available as an artifact that is compressed using Zstandard. This artifact is smaller and faster to decompress than the original, gzip-compressed bundle. The CodeQL bundle is a tar archive containing tools, scripts, and various CodeQL-specific files.
  • CodeQL 2.19.221 October 2024
    • Analysis of Python apps now has significantly faster extraction and analysis times.
  • CodeQL 2.19.14 October 2024
    • Java 23 is now supported.
    • A new command, codeql resolve packs, shows each step in the pack search process, including what packs were found in each step.

Detailed changelogs for every CodeQL release are available in the CodeQL documentation, and new CodeQL releases occur roughly every two weeks.

For GitHub Enterprise Server customers: All new functionality from CodeQL releases 2.19.0 through 2.20.3 will be included in GHES 3.16 and the latest patch versions of 3.12-3.15. Functionality from 2.20.3 and later 2.20.X versions will be included in 3.17. If you use an older version of GHES, you can manually upgrade your CodeQL version.

See more