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

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

Dependabot migration to GitHub Actions for Enterprise Cloud and Free, Pro, and Teams accounts with Actions enabled

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.

See more

Artifact Attestations is generally available

GitHub Artifact Attestations is generally available

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

Enhance your SDLC’s security with a Kubernetes admission controller

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

Get Started

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.

See more

Simplified dependabot.yml configuration with multi-directory key (directories) and wildcard / glob (*) support

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.

See more

CodeQL can scan C# projects without requiring working builds (public beta)

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

2FA security checkup experience is now improved

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
View more changes