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

The latest GitHub and GitHub Copilot SOC reports are now available

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.

See more

Artifact Attestations now support multiple subjects

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

See more

Code scanning now creates alert-related events in audit log

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:
– Learn more about code scanning
– Learn more about audit log events for your enterprise
– Learn more about audit log events for your organization

See more

Upcoming changes to data retention for Events API, Atom feed, /timeline and /dashboard-feed features

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.

Why are we making changes?

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.

Which APIs will be impacted in this change?

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

When can you expect the changes to occur?

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.

Additional support

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.

Where can I learn more?

If you have concerns, comments, or feedback, please join us in this Discussion in the GitHub Community.

See more

Copilot Autofix for Dependabot now available for TypeScript repositories (private preview)

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.

Why Copilot Autofix for Dependabot?

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.

How to join the private preview

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.

Learn more

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.

See more

New PAT rotation policies preview and optional expiration for fine-grained PATs

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.

Screenshot of the policy UI for fine-grained PATs, showing that fine-grained PATs must expire within 90 days and that enterprise administrators are exempt

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.

Allowing infinite-lifetime fine-grained PATs

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.

See more

EPSS Scores in the GitHub Advisory Database

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:

  • 90.534% chance of exploitation in the next 30 days.
  • 95% of other vulnerabilities are less likely to be exploited.

Learn more in the FIRST’s EPSS User Guide.

This feature will be available in GitHub Enterprise Server version 3.16 and later.

See more

Announcing TISAX for GitHub

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.

What does this mean for me as a customer?

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:

  • Information Security: Implementing robust security measures to prevent unauthorized data access and breaches.
  • Risk Management: Continuously identifying, evaluating, and mitigating potential risks to GitHub’s information systems.

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.

See more

CodeQL 2.19.0: TypeScript 5.6 and Go 1.23 support, new queries for JavaScript and Ruby

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:

  • CodeQL 2.18.2
    • Support for scanning Java codebases without needing a build is generally available.
    • The Python py/cookie-injection query, which finds instances of cookies being constructed from user input, is now part of the main query pack.
    • One new query for Ruby rb/weak-sensitive-data-hashing, to detect cases where sensitive data is hashed using a weak cryptographic hashing algorithm.
  • CodeQL 2.18.3
    • New C# models for local sources from System.IO.Path.GetTempPath and System.Environment.GetFolderPath.
  • CodeQL 2.18.4
    • Support for scanning C# codebases without needing a build is generally available.
    • Support for Go 1.23.
  • CodeQL 2.19.0
    • Support for TypeScript 5.6.
    • One new query for JavaScript js/actions/actions-artifact-leak to detect GitHub Actions artifacts that may leak the GITHUB_TOKEN token.
    • A 13.7% evaluator speed improvement over CodeQL 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.

See more

GitHub security advisories support CVSS 4.0

GitHub security advisories now support the new CVSS 4.0 schema. CVSS, or the Common Vulnerability Scoring System, is an industry standard maintained by FIRST. The CVSS 4.0 standard adds new metrics for a more thorough assessment of the risk of a particular vulnerability.

When creating a repository security advisory, you can now calculate either a CVSS 4.0 or 3.1 base score and view this data on the published global advisory, related Dependabot alerts, and through the API.

Learn more about CVSS scores and GitHub security advisories and the GitHub Advisory Database.

See more

CodeQL code scanning can analyze Java and C# codebases without needing a build (GA)

CodeQL code scanning can now analyze Java and C# code without having to observe a build. This makes it easier to roll out the security analysis on large numbers of repositories, especially when enabling and managing repositories with GHAS security configurations.

CodeQL is the analysis engine that powers GitHub code scanning. When analyzing source code, it is important that the analysis engine has detailed knowledge of all aspects of the codebase. Now, the analysis engine no longer depends on observing the build process for Java and C# code, resulting in higher setup success and adoption rates for CodeQL code scanning (Java and C#).

During the testing of this feature, we validated that the analysis results were as accurate as the previous methodology. This feature was previously in public beta earlier this year (Java, C#), when it became the new default analysis mode for new users of CodeQL code scanning for these languages. Some customers experienced time significant savings as some tasks that previously took weeks now are achievable in minutes.

CodeQL’s new zero-configuration analysis mechanisms for both Java and C# are available on GitHub.com. If you are setting up CodeQL code scanning for these repositories, you will benefit from this analysis mechanism by default. If you set up CodeQL code scanning for Java or C# before their respective public beta releases of this feature, your analysis will remain unchanged (but can be migrated by disabling the current configuration and re-enabling code scanning using default setup). This new functionality will also be released to our GitHub Enterprise Server (GHES) customers starting with version 3.14 for Java and 3.15 for C#.

Repositories that use code scanning advanced setup will continue to use whichever analysis mechanism is specified in the Actions workflow file. The template for new analysis configurations now uses the new analysis mechanism by specifying `build-mode: none`. The old analysis mechanisms remain available. Users of the CodeQL CLI can find more documentation here.

Learn more about GitHub code scanning. If you have any feedback about these new analysis mechanisms for Java and C#, please join the discussion here.

See more

CodeQL 2.18.1: Kotlin & Swift mobile support is generally available, TypeScript 5.5 support, C# build-mode: none public beta

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

Important changes by version include:

For a full list of changes, please refer to the complete changelog for versions 2.17.6, 2.18.0, and 2.18.1. All new functionality will be included in GHES 3.15. Users of GHES 3.14 or older can upgrade their CodeQL version.

See more

Validation on package name when submitting a new GitHub security advisory (GHSA)

To make it easier to submit security advisories, GitHub now validates package names.

When submitting a new GHSA (GitHub Security Advisory) in a repository, the user is prompted to enter the ecosystem (e.g. npm, maven) and package name (e.g. webpack, lodash). Now, when they enter the name, there will be a validation message at the bottom of the form to confirm whether or not the package name they entered has been found in the ecosystem they specified.

To learn more about submitting advisories to our Advisory Database, check out our documentation here.

See more

Enable secret scanning for non-provider patterns on repositories with the REST API

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.

See more

Secret scanning detects generic passwords with AI (public beta)

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.

See more
View more changes