GitHub Advanced Security customers using secret scanning can now use the REST API to enable or disable support for non-provider patterns at the repository level.
Non-provider patterns scans for token types from generic providers, like private keys, auth headers, and connection strings.
Secret scanning now detects generic passwords using AI. Passwords are difficult to find with custom patterns — the AI-powered detection offers greater precision for unstructured credentials that can cause security breaches if exposed.
Passwords found in git content will create a secret scanning alert in a separate tab from regular alerts. Passwords will not be detected in non-git content, like GitHub Issues or pull requests, and are not included in push protection. Password detection is backed by the Copilot API and is available for all repositories with a GitHub Advanced Security license. You do not need a Copilot license to enable generic secret detection.
To start detecting passwords, select “Use AI detection to find additional secrets” within your code security and analysis settings at the repository level, or the code security global settings at the organization level.
Over the next few weeks, jobs generating Dependabot pull requests will start running as GitHub Actions workflows on Github.com accounts with GitHub Actions enabled. This migration will include faster Dependabot runs, increased troubleshooting visibility, self-hosted runner support, and other performance and feature benefits. No additional steps are required, and you should not experience service disruptions during the migration. By the beginning of September, repositories with GitHub Actions enabled should expect to see the jobs that generate Dependabot pull requests run as GitHub Actions workflows.
Running Dependabot does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone.
Are you so excited for the Dependabot performance benefits that you want to get started today? You can optionally enroll your repositories and/or organizations before the migration begins! Get started by opting in to run Dependabot PR jobs as GitHub Actions workflows here.
If your organization has disabled GitHub Actions by policy, Dependabot will continue to run on the legacy compute provider. If you want to use Dependabot on GitHub Actions, an organization administrator must update your configuration before opting in to run Dependabot on GitHub Actions.
Check out our docs to learn more about Dependabot on GitHub Actions. For additional information, check out our blog post or previous changelog.
We’re thrilled to announce the general availability of GitHub Artifact Attestations! Artifact Attestations allow you to guarantee the integrity of artifacts built inside GitHub Actions by creating and verifying signed attestations. With this release, you can now easily verify these artifacts before you deploy them in your Kubernetes cluster. Powered by Sigstore, Artifact Attestations help you secure your software’s supply chain by creating an unforgeable link between artifacts and their build process.
“Over the past nine months, Trail of Bits has worked closely with GitHub to make Homebrew one of the earliest public adopters of Artifact Attestations. Software, and especially open source software, is more complicated and interconnected than ever, and we believe strongly that GitHub’s new Artifact Attestations feature is a huge and necessary step towards addressing the problem of complex, opaque, software supply chains.” – William Woodruff, Engineering Director, Trail of Bits
“Using Artifact Attestations, we finished a project in under a week that we originally scoped out for months to complete.” – Mike Place, Director of Software Engineering at Elastic
Adding provenance to a GitHub Actions workflow is simple! You just need to invoke the new attest-build-provenance Action with the path to your artifact:
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 our CLI tool:
gh attestation verify PATH/TO/ARTIFACT -o myorganization
With general availability we are also releasing a new way to build a Kubernetes admission controller that can validate attestations directly within your Kubernetes clusters. This means that only properly attested artifacts can be deployed, adding an extra layer of security and compliance to your software development lifecycle (SDLC). By integrating Artifact Attestations into your GitHub Actions workflows, you enhance the security of your development and deployment processes, protecting against supply chain attacks and unauthorized modifications.
Setting up an admission controller for GitHub Artifact Attestations involves deploying the Sigstore Policy Controller, adding a TrustRoot and ClusterImagePolicy to your cluster, and enforcing those policies on a per-namespace basis. Quickly deploy your own admission controller using our Helm charts.
Learn more about the Kubernetes admission controller
To start using the new features, check out our documentation and watch the video below for a step-by-step guide on integrating artifact attestations into your workflows. This feature supports both public and private repositories, making it easier than ever to secure your projects.
Integrate GitHub Artifact Attestations into your workflows today, and add meaningful security to your SDLC. Please join the discussion in the GitHub Community and share your feedback with us.
Dependabot version updates requires developers to configure and check in a dependabot.yml file. In the past, it was challenging for administrators to configure a dependabot.yml that works for all repositories without per-repo customization. With this change, you can now specify multiple directories of dependency manifests using the directories key. Directories can be configured with wildcards or globbing to make targeting easier as well. This will simplify the process of creating configurations and allow greater flexibility for developers who wish to customize their behavior.
To learn more, visit our dependabot.yml configuration documentation for the directories key.
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.
build-mode. The default value for newly configured C# repositories will be build-mode: none.--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.
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.
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.
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.
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:
cpp/iterator-to-expired-containerto detect the creation of iterator owned by temporary objects that are about to be destroyed.py/header-injection query has been promoted to the main query pack and renamed to py/http-response-splitting.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.
Dependabot can now provide updates to Rust dependencies by accessing Cargo private registries.
To learn more, check out the documentation for configuring private registries for Dependabot.
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!
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“.
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.
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.