Skip to content

Secret scanning prevents secret leaks with protection on push

Organizations with GitHub Advanced Security can now prevent secret leaks with secret scanning’s new push protection feature.

For repositories with push protection enabled, GitHub will block any pushes where a high-confidence token is detected. Developers can bypass the block by providing details of why the secret needs to be committed via a web UI.

Push protection scans for tokens that can be detected with a very low false positive rate. If you run a service that issues tokens we’d love to work with you to make them highly identifiable and include them in push protection. We changed the format of GitHub’s own personal access tokens last year with this in mind.

For more information:

The code scanning alert page now shows the analysis origin for an alert. Code scanning alerts can originate from different analysis configurations on a repository. These may be using different tools or targeting different languages or areas of the code. For example, an alert generated using the default CodeQL analysis with GitHub Actions will have a different analysis origin from an alert generated externally and uploaded via the code scanning API. If an alert is generated by multiple analysis origins, the alert may be fixed in one origin but remain open in another.


Code scanning now shows the details of the analysis origin of an alert. If an alert has more than one analysis origin, it is shown in the ‘Affected branches’ sidebar and in the alert timeline. You can hover over the analysis origin icon in the ‘Affected branches’ sidebar to see the alert status in each analysis origin. If an alert only has a single analysis origin, no information about analysis origins is displayed on the alert page.

These improvements will make it easier to understand your alerts — in particular those that have multiple analysis origins. This is especially useful for setups with multiple analysis configurations, such as mono repos.

Read more about code scanning analysis configurations

See more

If you manage self-hosted runners for GitHub Actions, you can now specify shell scripts that run before the runner starts running a job from a workflow, and after a job completes.

This allows you to perform a task on your self-hosted runner before a job starts and after a job ends, so you can set up your execution environment and clean up after workflow runs to ensure a consistent state on the runner itself, without requiring users to add that to their workflows.

Learn more about running scripts before or after a job

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

See more