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

CodeQL, the static analysis engine that powers GitHub code scanning, can now analyze C# projects without needing a build. This public beta capability enables organizations to more easily roll out CodeQL at scale. Previously, CodeQL required a working build to analyze C# projects. By removing that requirement, our large-scale testing has shown that CodeQL can be successfully enabled for over 90% of C# repos without manual intervention.
This new way of analyzing C# codebases is now enabled by default for all code scanning users on GitHub.com. CodeQL CLI users can enable this feature using the build-mode: none flag, starting with version 2.17.6.

Repositories with an existing code scanning setup, default or advanced, 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.

  • Repositories using code scanning default setup will automatically benefit from this new analysis approach.
  • 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 C# repositories 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, you should 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.

The new mechanism for scanning C# is available on GitHub.com and will be available with CodeQL CLI 2.17.6. 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 C# projects without the need for working builds, send us your feedback.

See more

GitHub is committed to a secure software ecosystem and requires most developers who contribute code on GitHub.com to enable one or more forms of two-factor authentication (2FA).To ensure that all users stay up to date with their account security configurations, we are now improving the checkup experience using various global banners that guide users to review and update their settings on a more regular basis.

These banners replace the security checkup interstitials that were previously displayed every 3 months for 2FA users. Each banner calls out the specific security configuration that needs attention (ex: user only having a single verified email), and will also include a quick link to the corresponding settings page to modify the required settings.

To learn more about the 2FA program, see our April 2024 blog post about how GitHub is securing millions of developers using 2FA, as well as the “About the mandatory 2FA program” documentation.

See more

CodeQL is the static analysis engine that powers GitHub code scanning. CodeQL version 2.17.5 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/C++ alerts, powered by Copilot. This is automatically enabled for all private repositories for all GitHub Advanced Security customers. Autofix covers all security queries for C/C++ from our Default suite. Use our public discussion for questions and feedback.

Also included in this release:
– C/C++ now supports adding models for sources, sinks and summaries in data extension files, making it easier to expand support to new libraries.
– Python adds support for opml library and C/C++ adds partial support for Boost.Asio network library.
– All the CodeQL CLI commands that produce SARIF will output a minified version to reduce size.

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

See more

Secret scanning’s delegated bypass for push protection allows you to specify which teams or roles have the ability to bypass push protection, and requires everyone else to submit a request to bypass. These requests are reviewed by designated approvers.

A new webhook event, bypass_request_secret_scanning, is now created when:
* bypass requests are created or cancelled
* bypass responses are submitted or dismissed
* bypass requests are completed

Delegated bypass for push protection is available for GitHub Advanced Security customers on Enterprise Cloud, and will be available on GitHub Enterprise Server 3.14.

See more

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

This changelog combines significant updates from the release of CodeQL 2.17.2,2.17.3, and 2.17.4:

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

See more

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

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

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

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

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

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 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

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