Skip to content

security

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

dependabot-core is now open source with an MIT license

We’re excited to announce that the dependabot-core project is being relicensed under the MIT License, making it easier for the community to contribute to Dependabot.

Keeping dependencies updated is a crucial part of securing your software supply chain, and Dependabot has been helping GitHub users do this since 2019. It’s used by millions of developers each month to keep their dependencies up-to-date and free of known security vulnerabilities. We don’t charge anyone to use Dependabot, because we think everyone should be able to use open source without fear of vulnerabilities.

dependabot-core is the component of Dependabot that defines the logic to create pull requests for dependency updates across the 20+ languages and package managers it supports today. The update logic in dependabot-core is tightly integrated with the rest of GitHub’s Dependabot features, such as grouped updates and auto-triage rules, and contributions from collaborators have helped with its support of Swift and improvements to NuGet. By adopting the MIT license, we will simplify the process for members of the community to contribute to Dependabot and innovate together.

Dependabot-core was previously available under the Prosperity Public License 2.0, and has received contributions from more than 300 developers over the past few years. Now, the MIT license will make it easier than ever for members of the community to join our cause to improve the security of all the world’s software. If you’d like to learn more about contributing to dependabot-core, please check out the repository, and drop us an issue or pull request!

See more

[Public Beta] Repository collaborators for Enterprise Managed Users

Enterprise Managed Users can now be added directly to a repository in their enterprise as a collaborator, without becoming a member of the organization. These users function like outside collaborators, with a few differences:
1. Only user accounts from within the enterprise can be added to the repository. This means that users you want to collaborate with must still come from your linked identity provider (IDP).
2. EMU users can only be collaborators on repositories in their enterprise. EMU accounts cannot collaborate outside their enterprise.
3. Repo Collaborator invitations can only be sent by an EMU’s enterprise owner by default, while in non-EMU enterprises and organizations both enterprise and organization owners can manage outside collaborators.

Like outside collaborators – users do not have to SSO authorize their credentials in order to access repositories that they have been granted access to as a repository collaborators. This aligns to the current access model for internal repositories on GitHub.

You can try out repository collaborators by going to the repository policies section of your Enterprise settings and selecting which tiers of administrators are allowed to invite collaborators.

For more information about repository and outside collaborators, see “Roles in an organization“.

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

Artifact Attestations public beta

Create a tamper-proof papertrail for anything you build on Actions

Artifact Attestations lets you sign builds in GitHub Actions, capturing provenance information about the artifact and making it verifiable from anywhere. There are no keys or PKI to manage, and verification happens with the GitHub CLI tool. The solution is based on Sigstore, an open source project that simplifies signing for software artifacts.

To add provenance to a GitHub Actions workflow, you just need to invoke the new attest-build-provenance Action with the path to an artifact. Here’s a simple example:

permissions:
  id-token: write
  contents: read
  attestations: write

#
# (build your artifact)
#

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: 'PATH/TO/ARTIFACT'

Then verify it with the CLI tool:

gh attestation verify PATH/TO/ARTIFACT -o myorganization

To learn more check out the blog and join the discussion in the GitHub Community.

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

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

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

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

What’s new for GitHub Actions hosted runners

Today we are announcing exciting updates for GitHub Actions hosted runners, the cloud-based service that provides powerful virtual machines to developers and teams to integrate their automation and CI/CD workflows within GitHub. These updates mark a significant leap towards enhancing enterprise readiness for GitHub Actions and a testament to our commitment to simplifying the adoption of GitHub Actions hosted runners across all project sizes and complexities.

  • Azure private networking functionality, that was previously in public beta, is now generally available. This feature allows you to run your Actions workflows on GitHub-hosted runners that are connected to your Azure virtual network, without compromising on security or performance.
  • We are introducing additional runner SKUs to our hosted runner fleet including a 2 vCPU Linux runner and a 4 vCPU Windows runner, both equipped with auto-scaling and private networking functionalities. Both these SKUs are generally available starting today and are geared to support scenarios where smaller machine sizes suffice yet the demand for heightened security and performance persists.
  • Apple silicon (M1) hosted runners, specifically macOS L (12-core Intel) and macOS XL (M1 w/GPU hardware acceleration) which were previously in public beta, are now generally available.
  • We are also unveiling a GPU hosted runner (4 vCPUs, 1 T4 GPU) available in public beta. The GPU runners are available on Linux and Windows, and are enabled with auto-scaling and private networking functionalities. These runners empower teams working with machine learning models such as large language models (LLMs) or those requiring GPU graphic cards for game development to run their tests more efficiently as part of their automation or CI/CD process.

Get Started

  • Azure private networking for GitHub-hosted runners is available across Team and Enterprise plans. To get started, navigate to the ‘Hosted Compute Networking’ section within your Enterprise or Organization settings. For more details, consult our documentation. To request support for additional Azure regions, please fill out this form. As a note, Azure private networking for GitHub Codespaces continues to remain in beta.
  • The newly added 2 vCPU Linux and 4 vCPU Windows SKUs are generally available starting today across Team and Enterprise plans. To use these runners, create a GitHub-hosted runner by selecting the ‘2-core’ or ‘4-core’ size options in the runner creation flow.
  • macOS L and macOS XL runners are generally available across Free, Team and Enterprise plans, and can be used by updating the runs-on key to use one of the GitHub-defined macOS runner labels. To learn more about pricing for these SKUs, refer to our documentation.
  • GPU runners are available starting today in public beta across Team and Enterprise plans. To learn more about how to setup the runner, images, and pricing, refer to our documentation. To share your feedback and help us find the right additional GPU SKUs to support, please fill out this form.

We’re eager to hear your feedback on any and all of these functionalities. Share your thoughts on our GitHub Community Discussion.

See more

Dependabot grouped security updates generally available

Dependabot grouped security updates are now generally available. This feature automatically groups Dependabot pull requests, lets you specify several additional options to fine tune your groupings.

You can enable grouped security updates for Dependabot at the repository or organization-level. To enable this feature, go to your repository or organization settings page, then go to the Code security and analysis tab, and click “Enable” for grouped security updates (this also requires each affected repository to enable Dependency graph, Dependabot alerts, and Dependabot security updates). When you enable this feature, Dependabot will collect all available security updates in a repository and attempt to open one pull request with all of them, per ecosystem, across directories.

If you would like more granular control over Dependabot’s grouping, you can also configure the dependabot.yml file in a repository to group by any of the following:

  • Package name
  • Dependency type (production vs development)
  • Semver update level (patch, minor, major)

For additional information, check out the Dependabot configuration file documentation.

For GitHub Enterprise Server users, grouped security updates will be available in Version 3.14.

See more

CodeQL can scan Java projects without a build

With the 2.16.5 release of CodeQL, we’re introducing a new mechanism for creating a CodeQL database for Java codebases, without relying on a build. This enables organizations to more easily adopt CodeQL for Java projects at scale. Note: this release announcement contains details for users of the CodeQL CLI and advanced setup for code scanning. If you’re using GitHub code scanning default setup (which is powered by the CodeQL engine), this related release announcement will likely contain the information you’re looking for.

Previously, CodeQL required a working build to analyze Java projects. This could either be automatically detected or manually specified. Starting with CodeQL 2.16.5, you can now scan Java code without the need for a build. Our large-scale testing has shown that CodeQL can be successfully enabled for over 90% of Java repos without manual intervention.

This feature is currently in public beta and is accessible to all GitHub.com advanced setup for code scanning and CodeQL CLI users scanning Java code:

  • Repositories using advanced setup for code scanning via workflow files will have the option to choose a build-mode. The default value for newly configured Java repos will be build-mode: none.

  • CodeQL CLI users will not experience any change in the default behaviour, for compatibility with existing workflows. Users that want to enable this feature can now use the --build-mode none option. Generally, we also recommend users set the --build-mode option when using the CLI to make it easier to debug and persist the configuration should default behaviour change at any point in the future.
    codeql database create test_no_build_db --language java --build-mode none

  • Repositories containing a mix of Kotlin and Java code still require a working build for CodeQL analysis.

The new mechanism for scanning Java is available on GitHub.com and in CodeQL CLI 2.16.5. While in public beta, this feature will not be available on GitHub Enterprise Server for default setup or advanced setup for code scanning. As we continue to work on scanning Java projects without the need for working builds, send us your feedback.

See more

Java projects no longer require a build when using code scanning via default setup

CodeQL, the static analysis engine that powers GitHub code scanning, can now analyze Java projects without needing a build. This enables organizations to more easily roll out CodeQL at scale. This new way of analyzing Java codebases is now enabled by default for GitHub.com users setting up new repositories with default setup for code scanning.

Previously, CodeQL required a working build to analyze Java projects. This could either be automatically detected or manually specified. By removing that requirement, our large-scale testing has shown that CodeQL can be successfully enabled for over 90% of Java repos without manual intervention.

This feature is currently in public beta and is accessible to all users scanning Java code using default setup for code scanning on GitHub.com:

  • Anyone setting up their repo using code scanning default setup will automatically benefit from this new analysis approach.
  • Repositories containing a mix of Kotlin and Java code still require a working build for CodeQL analysis. CodeQL will default to the autobuild build mode to automatically try and detect the right build command.
  • Repositories with an existing code scanning setup will not experience any changes. If code scanning is working for you today it will continue to work as-is, and there is no need to change your configuration.

GitHub.com users using advanced setup for code scanning and users of the CodeQL CLI will be able to analyze Java projects without needing a working build as part of CodeQL CLI version 2.16.5. While in public beta, this feature will not be available for GitHub Enterprise Server. As we continue to work on scanning Java projects without needing a working build, send us your feedback.

See more

OpenSSF Scorecard info is now available in the Dependency Review Action

Dependency review helps you understand dependency changes and the security impact of these changes at every pull request. We have updated the dependency review action to include information from the OpenSSF Scorecard project into the review, helping you better understand the security posture of the dependencies that you’re using.

See more

Dependabot will now pause scheduled jobs after 15 failures

Previously, if Dependabot encountered 30 consecutive failures, it would stop running scheduled jobs until manual intervention via updating the dependency graph or manifest file. Dependabot will now pause scheduled jobs after 15 failures. This will give an earlier indication of potential issues while still ensuring that critical security updates will continue to be applied without interruption.

Read more in the Dependabot Docs. 

See more

CodeQL 2.16.4: AI-powered autofixes for Java, support for C# 12 & Go 1.22, new queries

CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.16.4 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 Java alerts on pull requests, powered by Copilot. This is automatically enabled for all current autofix preview participants. You can sign up for the preview here and use our public discussion for questions and feedback.

The number of generated autofixes is now also visible in a dedicated security overview tile:

security overview showing a counter of fix suggestions

Furthermore, this release

For a full list of changes, please refer to the complete changelog for version 2.16.4. 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

Secret scanning and push protection are enabled by default on new public repositories

All new public repositories owned by personal accounts will now have secret scanning and push protection enabled by default. Pushes to the repository that include known secrets will be blocked by push protection, and any known secrets that are detected in the repository will generate a secret scanning alert. Secret scanning and push protection can be disabled by the repository administrator after the repository is created.

Existing public repositories are not affected, nor are new public repositories that belong to an organization.

See more

CodeQL 2.16.3: AI-powered autofixes for Python, updated queries, and security fixes

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

Important changes in this release include:

  • CodeQL code scanning now supports AI-powered automatic fix suggestions for Python alerts on pull requests. This is automatically enabled for all current autofix preview participants.
  • A new option has been added to the Python extractor: python_executable_name. This allows you to select a non-default Python executable installed on the system running the scan (e.g. py.exe on Windows machines).
  • A fix for CVE-2024-25129, a low-severity data exfiltration vulnerability that could be triggered by processing untrusted databases or CodeQL packs.
  • Two new queries:
  • The sinks of queries java/path-injection and java/path-injection-local have been reworked to reduce the number of false positives.

For a full list of changes, please refer to the complete changelog for version 2.16.3. 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
View more changes