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.

Security overview dashboard: Alert age trends, custom repository and severity filters, and date pickers

Starting today, you can take advantage of the new “age” grouping for the alert trends graph and explore enhanced filter options on the security overview dashboard, aimed at improving your analytical process and security management.

alert trends grouped by age

Explore the dynamics of your security alerts with the new alert age grouping on the alert trends graph. This new functionality offers a refined view into the lifecycle of your security alerts, enabling you to better evaluate the timeliness and effectiveness of your response strategies.

New filter options

repository custom property filter on the security overview page

Leverage enhanced filters to fine-tune your security insights on the overview dashboard:
* Custom repository property filters: With repository custom properties, you can now tag your repositories with descriptive metadata, aiding in efficient organization and analysis across security overview.
* Severity filters: Severity-based filters allow you to concentrate on the vulnerabilities that matter most, streamlining the process of security risk assessment and prioritization.
* Improved date picker controls: Navigate through time with ease using the new date picker options, allowing for quick selection of rolling periods like “Last 14 days,” “Last 30 days,” or “Last 90 days.” Bookmark your preferred time window to keep your analysis current with each visit.

You can access these new functionalities in security overview by navigating to the “Security” tab at the organization level.

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

See more

New SSH CAs must sign expiring certificates

SSH CAs uploaded to GitHub.com after March 27th, or in GHES 3.13 and beyond, can only sign certificates that expire. They must expire within 366 days of being created.
While expirations on certificates are not required by signing tools such as ssh-keygen, we are enforcing this best practice in order to protect against a weakness in how SSH certificates are linked to users.

CAs uploaded before the cutoff date or release will be marked in the UI as being allowed to sign non-expiring certificates:

image

An “upgrade” option on the CA lets you enforce expiration of signed certificates. Once you’ve validated that you are indeed using a lifetime on your certificates, we recommend upgrading your CAs. This upgrade step is irreversible, and new CAs cannot be downgraded to allow non-expiring certificates.
If a certificate is signed with no expiration, or a too-long expiration, it will be rejected during SSH connection with an error indicating The SSH certificate used was issued for a longer period than allowed.

This change forces the valid_after issuance timestamp to be written to the certificate, which allows GitHub to detect if the user changed their username after the certificate was issued for that username. This prevents a reuse attack vector where the former holder of a username is able to use certificates issued to them to sign in as the new holder of that username.

To learn more about managing SSH CAs, see “Managing your organization’s SSH CAs” and “Managing SSH CAs for your enterprise.” For information on using SSH CAs, see “About SSH CAs.”

See more
View all changes