Skip to content

Improvements to security overview insights, secret scanning metrics

Today, we’re releasing a host of new insights to the security overview dashboard, as well as an enhanced secret scanning metrics page.

New dashboard insights

overview dashboard with third-party tools, the trend indicator for age of alerts, and reopened alerts tile highlighted

  • Third-party alerts integration: Beyond GitHub’s own CodeQL, secret scanning, and Dependabot security tools, you can now view alert metrics for third-party tools directly on the overview dashboard. Use tool:[third-party-tool name] to view metrics for a specific third-party security tool, or tool:third-party to view metrics for all third-party security alerts.
  • Reopened alerts tracking: Uncover recurring vulnerabilities with the new reopened alerts metric tile, which identifies vulnerabilities that have resurfaced after being previously resolved. This data point helps assess the long-term effectiveness of your remediation efforts.
  • Trend indicators: Review changes over time with trend indicators for key metrics like age of alerts, mean time to remediate, net resolve rate, and total alert count. These indicators offer a clear view of performance shifts and trends between a given date range and that same range reflected backward in time.
  • Advisories tab: Stay informed with the new advisories table, which details the top 10 alert advisories affecting your organization, including the advisories’ CVE IDs, ecosystems, open alert counts, and severities.

Secret scanning metrics page enhancements

secret scanning metrics page with filter bar highlighted

You can now refine your insights with filters for dates, repository custom properties, teams, and more on the secret scanning metrics page. These new filters empower you to pinpoint specific repositories and view changes over time, enabling a more targeted analysis. Additionally, if you are an organization member, you can now view metrics for the repositories you have access to.

These features are now available as a public beta on GitHub Enterprise Cloud and will be available in GitHub Enterprise Server 3.13.

Learn more about security overview and send us your feedback

GitHub Copilot General Availability in the CLI

GitHub Copilot in the CLI banner demonstrating "ghcs" alias for supporting command execution

GitHub Copilot in the CLI is now generally available

We are excited to announce Copilot in the CLI is now generally available (GA) for all our Copilot Individual, Business, and Enterprise customers.

Copilot in the CLI allows users to access the power of GitHub Copilot to get command suggestions and explanations without leaving the terminal. Starting today, developers can also use GitHub Copilot to execute suggested commands based on feedback shared during the public beta.

GitHub Copilot in the CLI has also gained a couple of helper aliases for Bash, PowerShell, and Zsh. The new gh copilot alias command generates shell-specific configuration for ghcs and ghce aliases. These aliases use fewer keystrokes to jump into the gh copilot experience. Additionally, the new ghcs alias streamlines the process for executing commands suggested while making them available for later reuse!

How to get started?

If you were already using Public Beta:

  • Update the extension to v1.0.0 by running gh extension upgrade gh-copilot.

If you haven’t enabled Copilot in the CLI yet or coming from the GitHub Next technical preview

  • Copilot Individual users: You automatically have access to the Copilot in the CLI.
  • Copilot Business and Enterprise users: Your organization admins will need to grant you access to Copilot in the CLI.

After receiving access to Copilot in the CLI, consult our guide on how to install the tool and get started.

How to give us your feedback?

We are dedicated to continuous improvement and innovation. Your feedback remains a crucial part of our development process, and we look forward to hearing more about your experiences with GitHub Copilot in the CLI. Please use our public repository to provide feedback or ideas on how to improve the product.

See more

Java projects no longer require a build when using code scanning via default setup

CodeQL, the static analysis engine that powers GitHub code scanning, can now analyze Java projects without needing a build. This enables organizations to more easily roll out CodeQL at scale. This new way of analyzing Java codebases is now enabled by default for GitHub.com users setting up new repositories with default setup for code scanning.

Previously, CodeQL required a working build to analyze Java projects. This could either be automatically detected or manually specified. By removing that requirement, our large-scale testing has shown that CodeQL can be successfully enabled for over 90% of Java repos without manual intervention.

This feature is currently in public beta and is accessible to all users scanning Java code using default setup for code scanning on GitHub.com:

  • Anyone setting up their repo using code scanning default setup will automatically benefit from this new analysis approach.
  • Repositories containing a mix of Kotlin and Java code still require a working build for CodeQL analysis. CodeQL will default to the autobuild build mode to automatically try and detect the right build command.
  • Repositories with an existing code scanning setup 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.

GitHub.com users using advanced setup for code scanning and users of the CodeQL CLI will be able to analyze Java projects without needing a working build as part of CodeQL CLI version 2.16.5. While in public beta, this feature will not be available for GitHub Enterprise Server. As we continue to work on scanning Java projects without needing a working build, send us your feedback.

See more
View all changes