2FA requirement status on the People pages

As part of the two-factor authentication requirement program on GitHub.com, the People pages of enterprises and organizations have been updated to include the 2FA requirement status of members and collaborators. As an administrator, you can see which of your users have not yet enabled 2FA but are required to do so because of an action they have take in one of your organizations, or elsewhere on GitHub.com.

A clock icon will appear as a user's 2FA status will show if the user is required to enable 2FA. When the icon is red, they are past the due date for enabling 2FA, and are at risk of being blocked from accessing GitHub.com until they enable it. Clicking the clock icon will display the user's enrollment date.
256704235-eb7cb75d-2806-4aa6-aa44-aa9148bfb828

You can filter the UI to show only users who have a pending requirement. Enrollment dates are also now included in the CSV and JSON downloads of enterprise and organization memberships.

To learn more about the 2fa enrollment program, see our blog post with more details. For information about viewing your members, see the organization and enterprise documentation.

Organization owners and security managers can now view metrics associated with push protection usage across their organization.

The overview shows a summary of how many pushes containing secrets have been successfully blocked across the organization by push protection, as well as how many times push protection was bypassed.

You can also find more granular metrics, including:

  • the secret types that have been blocked or bypassed the most
  • the repositories that have had the most pushes blocked
  • the repositories that are bypassing push protection the most
  • the percentage distribution of reasons that users give when they bypass the protection

These metrics are found under the Security tab of your organization and are based on activity from the last 30 days.

screenshot of push protection metrics, showing overall secrets blocked and details on most blocked types, repositories with most pushes blocked, and bypassed secret metrics

See more

Code scanning default setup is now available for Swift analysis with CodeQL! Default setup now supports all CodeQL supported languages at the repository level. This includes JavaScript/TypeScript, Ruby, Python, Go, Java, Kotlin, C/C++, C#, and Swift. We're working to support enabling code scanning at the organization level for all CodeQL languages soon.

Default setup automatically detects the languages used in a repository, and automatically analyzes JavaScript/TypeScript, Ruby, Python, and Go. You can also optionally customize the configuration to analyze Java/Kotlin, C/C++, C# and Swift. The configuration can be viewed and edited at any time, during or after set up. You can also use the REST API to include languages in the default setup configuration.

Java, Kotlin, C/C++, C# and Swift are not automatically included in the default setup configuration because they often require more advanced configuration. Code written in these languages needs to be compiled in order for CodeQL analysis to proceed. CodeQL will attempt to build your code automatically but may fail if your code requires bespoke build steps.

If a language fails in default setup, you will see an error message on the repository's settings page, in the code security and analysis section. To resolve the situation you can:

  1. Deselect the language from the configuration and continue to use default setup for the successful languages.
  2. Convert to advanced setup. The advanced setup uses a yml file and allows you to provide the build information required for the CodeQL analysis to succeed.
  3. Debug and fix the cause of the language failure. The Actions log will provide the failure reason so you can resolve this for a successful analysis.

For more information, see the documentation for when a particular language is causing default setup to fail. For more information on code scanning default setup, see Configuring code scanning automatically.

See more