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.
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:
actions language (for analysis of GitHub Actions workflows) no longer requires the CODEQL_ENABLE_EXPERIMENTAL_FEATURES environment variable to be set.bottle web framework for Python is now supported.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.
As of February 5, 2025, Dependabot no longer supports Python 3.8, which has reached its end-of-life. If you continue to use Python 3.8, Dependabot will not be able to create pull requests to update dependencies. If this affects you, we recommend updating to a supported release of Python. As of February 2025, Python 3.13 is the newest supported release.
View Python’s official documentation for more information about supported releases.
Starting today, Dependabot offers full support for pnpm workspace catalogs.
pnpm workspace catalogs are widely used in monorepos, and improper dependency handling can lead to:
Starting today, Dependabot fully supports pnpm workspace catalogs. This means that Dependabot now:
Learn more about Dependabot
Learn more about pnpm catalogs
Join the community discussion to share feedback and tips
GitHub Code Scanning powered by CodeQL now supports dependency caching for Java, Go, and C# projects. This feature ensures that scans can deliver meaningful results even if registries are temporarily unavailable, while also reducing overall scanning time after the cache is established.
Dependency Caching Availability:
This is now available on github.com.
CodeQL build-mode: none scans can now access private dependencies stored in private registries (e.g. Artifactory) for Java and C# projects. This makes your scans more comprehensive, ensuring you receive all important alerts regardless of where your dependencies are stored.
Previously, build-mode: none code scans with the default setup were unable to fetch code for dependent packages stored in private registries, which could result in incomplete analysis. Now, organization administrators can configure access credentials for private registries at the organization level. This enhancement allows CodeQL scans in child repositories to retrieve all necessary dependencies, enabling comprehensive code analysis when using the code scanning default setup.
This feature is currently in public preview for GitHub Advanced Security customers.
We are pleased to announce that our most recent SOC reports (1, 2, and 3) are available now and include GitHub Enterprise Cloud for github.com with all new regions like the EU, as well as Copilot Business and Enterprise. These reports are applicable for the 6-month period April 1, 2024 to September 30, 2024 and are available on the GitHub Enterprise Trust Center for our customers.
This represents a significant milestone for GitHub and our customers for multiple reasons:
– Copilot Business and Enterprise are now gaining coverage of control operating effectiveness over the period represented by a Type II report (as opposed to the point-in-time reports represented by the previous Type I reports issued Spring 2024)
– Coverage for Enterprises hosted in either dotcom or the newly launched EU region.
– Future regions launched for GitHub Enterprise Cloud will also be compliant.
These efforts and the culminating SOC 2 Type II reports represent GitHub’s ongoing commitment to provide secure products to our customers, which continues to provide developers the assurance to build software better, together.
Looking forward, bridge letters will be coming mid-January 2025 for the gap period representing October through December 2024. Additionally, the next round of SOC reports covering October 1, 2024 to March 31, 2025 will be available to customers in June 2025.
Artifact Attestations now supports attesting multiple subjects simultaneously. When the attest-build-provenance or attest-sbom actions create multiple attestations, a single attestation is created with references to each of the supplied subjects, rather than generating separate attestations for each artifact. This reduces the number of attestations that you need to create and manage. We published these changes as new versions of the respective actions. Please update your workflows to reference the new versions in order to leverage the new functionality.
Learn more about using Artifact Attestations to establish provenance for builds
The enterprise and organization-level audit log events are now created when a code scanning alert is created, fixed, dismissed, reopened, or appeared in a new branch:
code_scanning.alert_created – a code scanning alert was seen for the first time;code_scanning.alert_appeared_in_branch – an existing code scanning alert appeared in a branch;code_scanning.alert_closed_became_fixed – a code scanning alert was fixed;code_scanning.alert_reappeared – a code scanning alert that was previously fixed reappeared;code_scanning.alert_closed_by_user – a code scanning alert was manually dismissed;code_scanning.alert_reopened_by_user – a code scanning alert that was previously dismissed was reopened.The new functionality, which will be included in GHES 3.17, provides more insight into the history of a code scanning alert for easier troubleshooting and analysis.
For more information:
Currently, you are able to query back up to 90 days worth of events from data tables you have access to when reviewing or utilizing specific events features: Events API (including push events), Atom feed, /timeline, or /dashboard-feed. On January 30th, 2025, we will be modifying the window of data retention for these features from 90 days to 30 days.
We are making this change to help GitHub continue to scale for all our users, while continuing to provide existing customers of these features with the ability to still query and view recent important event information.
The relevant APIs that will be affected are:
– /events : List public events
– /networks/{owner}/{repo}/events : List public events for a network of repositories
– /orgs/{org}/events : List public organization events
– /repos/{owner}/{repo}/events : List repository events
– /users/{username}/events : List events for the authenticated user
– /users/{username}/events/orgs/{org} : List organization events for the authenticated user
– /users/{username}/events/public : List public events for a user
– /users/{username}/received_events : List events received by the authenticated user
– /users/{username}/received_events/public : List public events received by a user
– /feeds : Get feeds
On January 30th, 2025, we will be reducing the window that can be queried across those specified events features from 90 days to 30 days. In advance of that, we will test this change for 24 hours on December 3rd, 2024.
The Dormant Users feature report will also be impacted a result of this change. As of 1/31/25, users who are 31+ days without activity will fall into the dormant category and would appear in the Dormant Users report.
As part of this change, we are adding an additional event (DiscussionEvent) as a new EventType for the Events API. This will allow you to query for an event related to Discussions that was not previously available.
We recommend leveraging a workflow that uses weekly or daily exports if you require further historical access.
If you have concerns, comments, or feedback, please join us in this Discussion in the GitHub Community.
Copilot Autofix for Dependabot is now available in private preview for TypeScript repositories.
This new feature combines the power of GitHub Copilot with Dependabot, making it easier than ever to automatically fix breaking changes introduced by dependency updates. With Copilot Autofix, you can save time and minimize disruptions by receiving AI-generated fixes to resolve breaking changes caused by dependency upgrades in Dependabot-authored pull requests.
Dependency updates can introduce breaking changes that lead to failing CI tests and deployment delays. Identifying the exact cause of these breaks and implementing the correct fix can require significant time and effort, making it challenging to stay on the most up-to-date and secure version of a dependency.
Dependabot can now leverage the power of Copilot Autofix to analyze dependency updates that fail CI tests and suggest fixes, all within the pull request. Copilot Autofix for Dependabot not only helps keep your dependencies up to date, but also keeps your CI green. Staying up-to-date on dependencies upgrades with breaking changes is now easier and faster than ever.
To sign up for the feature waitlist, fill out the form to express your interest. We’ll notify selected participants as we roll out the feature over the coming weeks.
This feature is available in private preview to GitHub Advanced Security customers on cloud deployments. Starting today, we support TypeScript repos with tests set up in GitHub Actions. As we continue to develop this feature, we will expand coverage for additional languages and testing requirements.
Please keep an eye on future changelogs for more updates as the feature moves to public preview and general availability.
To learn more, please join the waitlist or check out the latest GitHub feature previews.
To hear what others are saying and offer your own take, join the discussion in the GitHub Community.
Enterprise and organization administrators can now set limits on token lifetimes for the personal access tokens (PATs) used against their resources. These policies mandate token rotation on a regular basis and reduce how long a compromised token is good for, while also providing a lever to reduce the use of less-secure PATs in your company. This public preview is available for all enterprises and organizations, and will be included in GHES 3.16.
Administrators can choose a maximum lifetime between 1 and 366 days for fine-grained PATs and PATs (Classic).
The policies for each token type are distinct, so you can promote the use of fine-grained tokens with a longer lifetime while driving down PAT (Classic) usage with a very short lifetime requirement.
The policies apply when tokens are created, regenerated, or used.
If you want to create a PAT for a specific organization, but that organization or enterprise has a lifetime policy, your lifetime options will be restricted. Additionally, if you try to use an already-created PAT in an organization or enterprise with a policy, the call will fail if the token has too long a lifetime.
If your enterprise has audit log streaming enabled, you’ll be able to track when this policy has blocked a PAT from being used.
With this change, developers can now create fine-grained tokens with no expiration for personal projects, an option that developer feedback said was needed to migrate from PATs (Classic) to more secure fine-grained PATs.
Enterprises and organizations have a 366 day expiration policy for fine-grained tokens by default, so developers still can’t create infinite lifetime fine-grained PATs for use against an organization they’re a member of, unless the administrator relaxes the policy.
For more information, see our documentation on Enterprise and Organization PAT policies.
Join the discussion within GitHub Community for feedback and questions.
The GitHub Advisory Database now features 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:
Learn more in the FIRST’s EPSS User Guide.
This feature will be available in GitHub Enterprise Server version 3.16 and later.
GitHub is now a participant in TISAX with an Assessment Level 2 (AL2) label in the ENX Portal. TISAX is a recognized assessment and exchange mechanism for the German automotive industry, ensuring that companies meet specific information security requirements. It is based on the German Association of the Automotive Industry or Verband de Automobile (VDA) Information Security Assessment (ISA) catalog, which aligns most closely with ISO/IEC 27001.
For our customers, this participation provides additional assurance that GitHub is a trusted partner in managing and securing their data. It opens new opportunities for customers who require TISAX participation to consider using GitHub Enterprise Cloud products, GitHub Copilot, and GitHub Actions.
Participating in the TISAX program at Assessment Level 2 means that GitHub has demonstrated the ability to adequately protect sensitive information in accordance with industry standards. This assessment level focuses on:
The scope of the TISAX assessment, using the newly released VDA ISA version 6, is the same as the GitHub Information Security Management System (ISMS), which has already been assessed against ISO/IEC 27001:2013. To see the scope, you can review GitHub’s ISO/IEC 27001:2013 certification.
Customers who are interested and registered as TISAX participants with ENX can find the details of GitHub’s assessment via the ENX portal by searching for GitHub, our Assessment ID (APC0RT), or our AL2 scope ID (SY52MN).
If you have any questions or need more information about GitHub’s compliance practices, please visit the GitHub Trust Center.
CodeQL version 2.19.0 has been released and has now been rolled out to code scanning users on GitHub.com. CodeQL is the static analysis engine that powers GitHub code scanning.
Important changes by version include:
py/cookie-injection query, which finds instances of cookies being constructed from user input, is now part of the main query pack.rb/weak-sensitive-data-hashing, to detect cases where sensitive data is hashed using a weak cryptographic hashing algorithm.System.IO.Path.GetTempPath and System.Environment.GetFolderPath.js/actions/actions-artifact-leak to detect GitHub Actions artifacts that may leak the GITHUB_TOKEN token.2.17.0 release.For a full list of changes, please refer to the complete changelog for versions 2.18.2, 2.18.3, 2.18.4 and 2.19.0.
All new functionality from 2.18.Z releases will be included in GHES 3.15, while functionality from 2.19.0 will be included in GHES 3.16. If you use GHES 3.14 or older, you can upgrade your CodeQL version.