Skip to content

Code scanning can filter alerts by language and file path

You can now easily find all alerts associated with a specific language with the new language filter on the code scanning alerts page.

To show all the code scanning alerts for a language, type 'language:javascript' in the Filter alerts text box.

Language filter

You can also use a file path filter to see all the alerts located in specific files or directories to sort and manage them efficiently by focusing on a specific part of the code related to the project.
This can be useful to manage lots of alerts on big repositories (monorepos) to review all alerts specific to the part of the code you are responsible for faster.

To apply the file path filter, type 'path:' and the path to the file or directory in the Filter alerts text box.

Path filter

This has shipped to and will be available in GitHub Enterprise Server 3.10.

Learn more about filtering code scanning alerts.

Starting today, you will now receive Dependabot alerts for vulnerabilities associated with your Swift dependencies.

The GitHub Advisory Database now includes curated Swift advisories. This brings the Advisory Database to twelve supported ecosystems, including: Composer (PHP), Erlang, GitHub Actions, Go, Maven, npm, NuGet, pip, Pub, RubyGems and Rust.

The dependency graph now supports detecting Package.resolved files. Swift dependencies from these files will be displayed within the dependency graph section in the Insights tab.

Dependabot security updates support will be added at a later date.

See more

For securely enabling OpenID Connect (OIDC) in your reusable workflows, we are now making the permissions more restrictive.

If you need to fetch an OIDC token generated within a reusable (called) workflow that is outside your enterprise/organization, then the permissions setting for id-token should now be explicitly set to write at the caller workflow level or in the specific job that calls the reusable workflow.

id-token: write # This is required for requesting the JWT

This change would ensure that the OIDC token generated in the called workflow is allowed to be consumed in the caller workflows only when intended.

Learn more about permission settings to enable OIDC in your workflows

See more