www.fgks.org   »   [go: up one dir, main page]
Skip to content
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

Secret scanning now automatically performs validity checks for closed alerts

Secret scanning will now continually run validity checks on closed alerts, similarly to the behavior for open alerts today. You can still request on-demand checks for supported secret types from the alert at any time.

Validity checks indicate if the exposed credentials are active and could possibly still be exploited. GitHub Advanced Security customers on Enterprise Cloud can enable validity checks at the repository, organization, or enterprise level from your Code security settings.

Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

Learn how to secure your repositories with secret scanning or become a secret scanning partner.

See more

Code security and secret scanning insights for your enterprise (public beta)

Gain valuable insights and effectively monitor your enterprise’s security landscape and progress with two new enterprise-level pages: the security overview dashboard and secret scanning metrics.

New overview dashboard on the security tab at the organization level

Key features

  • Customizable filters: Select specific time periods and focus areas such as security tool, team, or custom repository property.
  • Comprehensive data: Trending and snapshot data provide a robust security landscape overview.
  • Detailed metrics: Includes metrics such as the average age of security alerts, mean time to remediate, and push protection statistics.

To access these new enterprise-level views, navigate to your enterprise account. In the enterprise account sidebar, click Code Security. The new pages are accessible to organization owners and organization security managers, with data scoped to the repositories and alerts you have access to.

These two pages are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about security overview, managing code security for your enterprise, and send us your feedback

Questions or suggestions? Join the conversation in the community discussion.

See more

Security alerts tool trends on the security overview dashboard

The new Tool group-by option on the security overview trends graph provides a visualization of alert trends, organized by the security tools that detected each vulnerability. It’s designed to improve your ability to track and analyze the effectiveness of your scanning tools, enabling more strategic decision-making.

Example of the alert trends chart grouped by security tool

With this new functionality, you can:
* Pinpoint which tools are detecting the most critical vulnerabilities.
* Monitor the performance of your scanners over time.
* Prioritize your remediation efforts based on detailed insights.

To access this feature, navigate to the Security tab at the organization level on GitHub, and choose the Tool option in the Group by dropdown.

This functionality is now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about the security overview dashboard for your organization and send us your feedback

See more

Secret scanning push protection for file uploads

Secret scanning is expanding coverage for push protection to repository file uploads made via a browser. If push protection is enabled for a repository, secret scanning will now also block contributors from uploading files with detected secrets.

Learn more about push protection or sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

See more

Code Scanning will stop combining runs from a single upload

When uploading a SARIF file that contains multiple SARIF runs for the same tool and category,
Code Scanning combines those runs into a single run.

Combining multiple runs within the same SARIF file is an undocumented feature that was originally intended to simplify uploading multiple analyses for the same commit. Since then, we have introduced the explicit concept of category to be able to upload multiple analysis for the same commit, thus better aligning with the SARIF Specification.

Today, we are starting the deprecation path for the combination of multiple SARIF runs with the same tool and category within the same file. Specifically, in the next few days, the github/codeql-action/upload-sarif action will start showing a deprecation warning when using 3rd party tools that rely on the combination of multiple SARIF runs with the same tool and category within the same file. While showing the deprecation warning, the upload of the SARIF file will succeed.

We expect to fully stop combining multiple SARIF runs with the same tool and category within the same file in June 2025 (for github.com) and in GHES 3.18, at which point the upload of the SARIF file will fail.

How does this affect me?

You are affected if you are using the github/codeql-action/upload-sarif action to upload results from a 3rd party Code Scanning tool and the tool generates multiple runs with the same category in a single SARIF file.
If that is the case, you will start seeing the deprecation warning, and you should work with the tool provider so that each run in the SARIF file has a distinct tool or category.

You are affected if you are using github/codeql-action/upload-sarif action to upload multiple SARIF files from a 3rd party tool. You can end up with multiple SARIF files if the tool either generates multiple SARIF files itself or if you are using a matrix build to run multiple analyses. Specifically, if you are doing a matrix build that generates multiple SARIF files and have a dedicated job to upload all the SARIF files together. For example, your workflow might look like the following if you analyze two apps using a matrix build but then have a dedicated upload job to upload all the SARIF files together:

jobs:
  analyze:
    ...
    strategy:
      matrix:
        app: ['app1', 'app2']

    steps:
    - name: SAST Scan
      ...

    - name: Temporary store SARIF file
      uses: actions/upload-artifact@v4
      with:
        name: sarif-${{ matrix.app }}
        path: "results"

  upload:
      name: Upload SARIF
      needs: analyze
      steps:
      - name: Fetch SARIF files
          uses: actions/download-artifact@v4
          with:
          path: ../results
          pattern: sarif-*
          merge-multiple: true

      - name: Upload Results
          uses: github/codeql-action/upload-sarif@v3

In this case, you need to make the call to the github/codeql-action/upload-sarif action to include a distinct category. For example, you can embed the step in the matrix job and use the matrix variables to generate a unique category. In this way, the example above becomes:

jobs:
  analyze:
    ...
    strategy:
      matrix:
        app: ['app1', 'app2']

    steps:
    - name: SAST Scan
      ...

    - name: Upload Results
      uses: github/codeql-action/upload-sarif@v3
      with:
        category: ${{ matrix.app }}

Note that changing the value of the category causes older alerts to remain open, and you might want to delete the configuration using the previous category value.

You are not affected if you are only using CodeQL via the github/codeql-action action. For the few repositories that rely on this behavior, the CodeQL CLI (starting version 2.17.0) includes backwards compatible logic.

You are not affected if you are uploading multiple SARIF files for the same commit using one of the documented approaches.

What’s next?

In June 2025, SARIF uploads to github.com that contain multiple runs with the same tool and category will be rejected.

See more

Dependabot pull requests jobs are now available to run on self hosted GitHub Actions runners

Previously, developers who used private registries to host their packages on internal networks could not use Dependabot to update the versions of those packages in their code.

With this change, users can choose to run Dependabot pull request jobs on their private networks with self-hosted GitHub Actions runners, allowing Dependabot to access on-premises private registries and update those packages.

A prerequisite for enabling self-hosted runners includes enabling GitHub Actions for the repositories of interest. It’s important to note that running Dependabot does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone.

To get started, check out our documentation on managing self-hosted runners with Dependabot Updates.

If you’re interested in learning more about what it means to run Dependabot as a GitHub Actions workflow, check out our changelog and FAQ or Dependabot on Actions documentation.

See more

Secret scanning supports bypass controls for push protection (public beta)

For GitHub Advanced Security customers that use secret scanning, you can now specify which teams or roles have the ability to bypass push protection. This feature is in public beta on GitHub Enterprise Cloud.

screenshot of the bypass list in settings

This is managed through a new bypass list, where organizations can select which teams or roles are authorized to bypass push protection and act as reviewers for bypass requests. If an individual not included in this list needs to push a commit that is initially blocked, they must submit a bypass request. This request is then reviewed by an authorized individual who can either approve or deny it, determining whether the commit can proceed into the repository.

Please note, this feature is not yet compatible with web UI pushes.

See more

Code scanning now allows configuring rulesets to prevent pull requests from being merged (beta)

The code scanning option for repository rules is now available in public beta. Code scanning users can now create a dedicated code scanning rule to block pull request merges, instead of relying on status checks.
Making it easier than ever to prevent new vulnerabilities from being introduced into your code base.

code scanning rule

Configuring code scanning merge protection with rulesets can be done at the repository or organization levels and for repositories configured with either default setup or advanced setup. Additionally you can also use the REST API to set merge protection with rulesets.

You can use rulesets to prevent pull requests from being merged when one of the following conditions is met:
– A required tool found a code scanning alert of a severity that is defined in a ruleset.
– A required code scanning tool’s analysis is still in progress.
– A required code scanning tool is not configured for the repository.

Note: Merge protection with rulesets is not related to status checks. If the code scanning rule is configured for the repository in parallel with an alert threshold and the merge protection rule for the code scanning check run, the two functionalities will work simultaneously. For more information about status checks, see about status checks.

This beta is now available on GitHub.com and will be available on GHES 3.14. The organisation wide rules is only available for GitHub enterprise. For more information, see Configuring merge protection for all repositories in an organization.

We look forward to your feedback on the code scanning option for repository rules in the GitHub community.

See more

Dependabot multi-directory configuration public beta now available

This public beta enables developers to use a directories key to list multiple directories for the same ecosystem configuration in the dependabot.yml file.

Previously, developers with multiple package manifests for the same ecosystem (e.g. npm, pip, gradle) across multiple directories had to create separate dependabot.yml configurations for each of those directories. This could lead to many duplicated configurations, and high maintenance costs if a developer wished to make a change that spanned multiple directories.

A new dependabot.yml key, directories, is now available in public beta. The directories key accepts a list of strings representing directories, and can be used instead of directory.

Below is an example dependabot.yml multi-directory configuration setup, including how you can use the directories key:

version: 2
updates:
  - package-ecosystem: "bundler"
    directories:
      - "/frontend"
      - "/backend"
      - "/admin"
    schedule:
      interval: "weekly"

This example configuration applies to both security and version updates.

Wildcards and globbing support (i.e. using * to represent a pattern of directories) is coming soon in our next public beta releases, with an expected public beta launch within the next few months. Stay tuned for more!

If a developer still wishes to explicitly enumerate configurations for the same ecosystem using directory, they can still choose to do so; the directory key still accepts single-directory entries. For more information on the directory key, check out the dependabot.yml configuration options for the directory key documentation.

See more

CodeQL 2.17.1: AI-powered autofixes for C#, new Ruby queries and more Java models

CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.17.1 has been released and has now been rolled out to code scanning users on GitHub.com.

CodeQL code scanning now supports automatic fix suggestions for C# alerts on pull requests, powered by Copilot. This is automatically enabled for all private repositories for all GitHub Advanced Security customers. For the first time, autofix covers nearly all security queries for a language, with 49 supported queries for C# from our Default and Extended suites. Use our public discussion for questions and feedback.

Also included in this release:

For a full list of changes, please refer to the complete changelog for version 2.17.1. All new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.

See more

Enterprise enablement trends for security products (public beta)

For enterprise owners and security managers dedicated to managing security products, we are excited to announce a new capability: you can now gain historical insights into security products enablement trends across your GitHub enterprise. This overview helps you understand how security product coverage is being implemented across your company.

Following our March announcement of the public beta of the enablement trends report for organizations, which allowed monitoring of enablement trends for all security products within your GitHub organization, we’ve expanded this capability to the enterprise level. The addition of an owner filter further simplifies the navigation of metrics for repositories owned by specific organizations.

Enterprise enablement trends report

Explore enablement trends and gain historical insights into the activation status of GitHub security features:
* Dependabot alerts
* Dependabot security updates
* Code scanning
* Secret scanning alerts
* Secret scanning push protection

Historical data is available from January 1, 2024, with the exception of Dependabot security updates data, which is available from January 17, 2024.

To access the enablement trends report, navigate to your enterprise account. In the enterprise account sidebar, click Code Security.

This feature is now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about security overview and join the discussion within the GitHub Community

See more

Dependabot Updates on Actions for GitHub Enterprise Cloud and Free, Pro, and Teams Users

Starting today, developers using GitHub Enterprise Cloud (GHEC) and Free, Pro, and Teams accounts can enable their repositories and/or organizations to run Dependabot updates as an Actions workflow. With this change, the job that Dependabot runs to generate pull requests will run in GitHub Actions. This is the start of an effort to consolidate Dependabot’s compute platform to Actions, with further migration plans to be announced later.

Who can opt-in?

GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions today.

What if I’m on Enterprise Server (GHES)?

GitHub Enterprise Server (GHES) and Proxima users already run Dependabot on Actions; no further steps are required to enable Dependabot on Actions for these users.

Why choose to run Dependabot as an Actions workflow today?

Enabling Dependabot on Actions will yield performance benefits like faster Dependabot runs and increased visibility into errors to manually detect and troubleshoot failed runs. Actions APIs and webhooks will also be able to detect failed runs and perform downstream processing should developers wish to configure this in their CI/CD pipelines. There will be no change or impact to the Dependabot functionality, and there will be no impact to billed Actions minutes (i.e. Dependabot runs are free).

Will this count towards Actions minutes or costs?

This does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone. Beginning today, using Dependabot as an Actions workflow is free for everyone and generally available on all repositories.

What’s the next migration phase for Dependabot on Actions?

Over the course of the next year, we are migrating all Dependabot workflows to run on Actions compute infrastructure. You can opt-in today to gain access to these benefits, but they’ll be coming soon to all repos without needing to opt-in as well. We’re excited for faster runs, increased troubleshooting visibility, and other future benefits running Dependabot on Actions will unlock. We’ll be in close contact with those organizations who own repositories with Actions disabled and Dependabot enabled as we kick off the compute infrastructure migration. If you have questions or concerns, please contribute to our community discusson or contact our support team.

How to enable Dependabot on Actions?

GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions runners at either the repository or organization level from the Code security and analysis settings pages. For more information, see our documentation on enabling Dependabot on Actions runners.

When will Dependabot support self-hosted runners and larger GitHub-Hosted runners?

May 2024

When will VNETs be supported?

This work is still in progress; we don’t yet have an estimated date when these will be available.

Can I use Actions workflows and APIs to trigger Dependabot jobs?

Today, Dependabot jobs can only be triggered from the Dependabot UI, and not by Actions workflows or APIs.

If I see a Dependabot job fail in Actions, how can I restart it?

Check out our documentation on re-running a verison updates job or re-running a security updates job.

If I enable Dependabot on Actions, can I later opt-out?

At this time, you can opt out of enabling Dependabot on Actions. However, this ability will change within the next year as we consolidate Dependabot’s compute platform to Actions.

What if I don’t want to turn on Actions for my repository or organization? What happens if Actions is disabled in a repository but Dependabot is enabled to run on Actions?

During this opt-in phase of the compute infrastructure migration, if you enable Dependabot on Actions but disable Actions at the repository or organization level, Dependabot will run on the legacy compute infrastructure. Please enable Actions either in your Dependabot-enabled repository or across your organization if you wish to opt in to run Dependabot on Actions.

Read more about Dependabot on GitHub Actions runners.

Join the discussion within GitHub Community.

See more

Configure organization-level CodeQL model packs for GitHub code scanning

You can now add organisation-level CodeQL model packs to improve code scanning coverage for your GitHub organization. This ensures that custom libraries and frameworks are recognised by CodeQL.

In most cases, the out-of-the-box CodeQL threat models provide the best coverage for identifying potential vulnerabilities in your GitHub repositories using code scanning. The CodeQL team at GitHub keeps a close eye on the most widely-used open-source libraries and frameworks to ensure CodeQL recognizes untrusted data that enters an application. For cases which cannot be covered by default, such as custom-built or inner-sourced frameworks and libraries, you can create custom CodeQL model packs to help CodeQL detect additional security vulnerabilities in your code.

Configuring CodeQL model packs in the organisation code security and analysis settings

When you configure CodeQL model packs at scale, the packs will be used in every code scanning analysis that uses default setup in the organization. By default, code scanning will download the latest version of each model pack, meaning that the latest changes to the pack (such as adding information about new frameworks) will automatically be included. Alternatively, you can configure specific sets of CodeQL models to use by stating a specific version (or version range). For more information, see Editing your configuration of default setup in the GitHub documentation.

You can use the CodeQL model editor in VS Code to easily create custom CodeQL model packs for libraries and frameworks written in C# and Java/Kotlin. Custom CodeQL model packs are also supported for code written in JavaScript and Ruby and we will be adding support for these and other CodeQL-supported languages in the CodeQL model editor in the future.

This functionality is now available on GitHub.com and will be available in GitHub Enterprise Server 3.14.

See more

Secret scanning for historically existing secrets found in GitHub discussions and pull requests

Secret scanning has recently expanded coverage to GitHub discussions and pull requests.

GitHub is now performing a backfill scan, which will detect any historically existing secrets found in GitHub discussions and pull request bodies or comments.

For repositories with secret scanning enabled, if a secret is detected in a discussion or pull request, you will receive a secret scanning alert for it. Public leaks detected in public GitHub discussion or pull requests will also be sent to providers participating in the secret scanning partnership program.

Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

Learn how to secure your repositories with secret scanning or become a secret scanning partner.

See more

Secret scanning changes to detection and validation for Google Cloud Platform, Slack

GitHub secret scanning now supports validity checks for Google Cloud Platform (GCP) account credentials and Slack webhooks. This improvement involves changes to how account credentials for GCP are detected and alerted on.

What’s changing

Secret scanning alerts for Slack webhooks now support validity checks, in addition to previously supported Slack API tokens.

In addition, secret scanning now also alerts on complete GCP service account credential objects which include the fully matched private key, private key ID, and certificate URLs. These alerts support validity checks. As part of this change, you will no longer receive alerts for GCP private key IDs.

About validity checks

Validity checks indicate if the leaked credentials are active and could still be exploited. If you’ve previously enabled validation checks for a given repository, GitHub will now automatically check validity for alerts on supported token types.

Validity checks are available for repositories with GitHub Advanced Security on Enterprise Cloud. You can enable the feature at the enterprise, organization, or repository level from the “Code security and analysis” settings page by checking the option to “automatically verify if a secret is valid by sending it to the relevant partner.”

Share feedback

Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

Learn more about secret scanning or our supported patterns for validity checks.

See more

CodeQL 2.17.0: Support for Java 22, Swift 5.10, TS 5.4, C# 12

CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.17.0 has been released and has now been rolled out to code scanning users on GitHub.com.

Important changes in this release include:

For a full list of changes, please refer to the complete changelog for version 2.17.0. All new functionality will also be included in GHES 3.13. Users of GHES 3.12 or older can upgrade their CodeQL version.

See more

CodeQL threat model settings are now available for C# (beta)

Use CodeQL threat model settings for C# (beta) to adapt CodeQL’s code scanning analysis to detect the most relevant security vulnerabilities in your code.

CodeQL’s default threat model works for the vast majority of codebases. It considers data from remote sources (such as HTTP requests) as tainted. We previously released CodeQL threat model settings for Java to allow you to optionally mark local sources of data (such as data from local files, command-line arguments, environment variables, and databases) as tainted in order to help security teams and developers uncover and fix more potential security vulnerabilities in their code. CodeQL threat model settings are now available for C#, meaning that you can now enable similar local sources of taint in your code scanning analysis of code wriitten in C#.

If your repository is running code scanning default setup on C# or Java code, go to the Code security and analysis settings and click Edit configuration under Code scanning default setup. Here, you can change the threat model to Remote and local sources. For more information, see the documentation on including local sources of tainted data in default setup.

Threat model setting in CodeQL default configuration

If your repository is running code scanning advanced setup on C# or Java code, you can customize the CodeQL threat model by editing the code scanning workflow file. For more information, see the documentation on extending CodeQL coverage with threat models. If you run the CodeQL CLI on the command-line or in third party CI/CD, you can specify a --threat-model when running a code scanning analysis. For more information see the CodeQL CLI documentation.

As part of this work, we made changes to some of the queries included in the default code scanning suite for C# to better align with local and remote threat model settings. As a result you may see slightly fewer alerts when using the default threat model for remote sources. For more information about which queries are impacted, see the changelog for CodeQL 2.17.0.

CodeQL threat model settings (beta) in code scanning default setup is available on GitHub.com for repositories containing Java and C# code. Support for configuring threat model settings for C# will be shipped in GitHub Enterprise Server 3.14. Users of GHES 3.12 or older can also upgrade the version of CodeQL used in code scanning.

See more

Advanced filtering capabilities for the security overview dashboard

Today, we’re releasing security tool-specific filters for the security overview dashboard and secret scanning metrics page.

Security tool-centric filters in the filter bar drop-down on the overview dashboard

Have you ever wondered, “How well is my organization handling SQL injections?” or “How quickly are we responding to [partner name] secret leaks?” Maybe you’re curious about the pace of updating your npm dependencies. Well, wonder no more!

With our new security tool filters, you can tailor your search to the exact details you’re curious about, giving you a more focused and relevant report for your needs.

Discover the new filters that are designed to transform your security analysis:

  • Dependabot filters: Zero in on a specific ecosystem, package, and dependency scope.
  • CodeQL/third-party filters: Drill down to the rule that matters most to you.
  • Secret scanning filters: Get granular with filters for secret type, provider, push protection bypassed status and validity.

These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.14.

Learn more about security overview and send us your feedback

See more

Secret scanning now detects secrets in GitHub wikis

Secret scanning is expanding coverage to GitHub wiki content. If secret scanning is enabled for your repository, you’ll automatically begin to receive alerts for newly introduced secrets found in your GitHub wiki.

Publicly leaked secrets in GitHub wikis will also be sent to secret scanning partners participating in the secret scanning partner program.

Share feedback or learn more

Sign up for a 60 minute feedback session on secret scanning and be compensated for your time.

Learn how to secure your repositories with secret scanning or become a secret scanning partner.

See more
View more changes