GitHub Advanced Security customers can now view bypasses of secret scanning's push protection in the enterprise and organization audit logs. The GitHub REST API and webhooks now also contain bypass information.
GitHub Advanced Security customers can now perform dry runs of their custom patterns when editing a pattern. Dry runs allow admins to understand a pattern's impact across an organization and to hone the pattern before publishing and generating alerts.
Admins can compose a new pattern or edit a published pattern then 'Save and dry run' to retrieve results from their selected repositories. Scan results will appear on screen as they're detected, but admins can leave the page and later come back to their saved pattern's dry run results.
For more information:
GitHub Advanced Security customers can now opt to receive a webhook event that triggers when any feature in “Code security and analysis” is enabled or disabled.
The new security_and_analysis webhook event includes information about any changes and the affected repositority.
Today, we're shipping the ability to select multiple Dependabot alerts to reopen or dismiss from the index page UI. For example, from the Closed alerts tab, you can now select multiple alerts that have been previously dismissed, and then reopen them at once.
For more information, see our documentation for Dependabot alerts.
GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, we help protect users from data leaks and fraud associated with exposed data.
We have partnered with redirect.pizza, a domain redirection service, to scan for their API tokens and help secure our mutual users. Their API keys allow users to create, update, and delete redirects. We'll forward API tokens found in public repositories to redirect.pizza, who will notify the user by email and automatically revoke the token. More information about redirect.pizza’s API tokens can be found here.
GitHub Advanced Security customers can also scan for redirect.pizza API keys and block them from entering their private and public repositories via secret scanning’s push protection feature.
GitHub Advanced Security customers can now use sort and direction parameters in the GitHub REST API when retrieving secret scanning alerts. API users can sort based on the alert’s created or updated fields. The new parameters are available at the enterprise, organization, and repository level API endpoints.
Learn more about the secret scanning REST API
Learn more about private repository scanning with Advanced Security
Code scanning flags up potential security vulnerabilities in pull requests — well before code is merged and deployed. Starting today, such alerts will be more visible: they will appear as a review on the pull request Conversation tab. As with any review, developers can then have a conversation about specific areas of the code that was changed.
And of course, from the code review by the GitHub code scanning bot, you can dive deeper into the alert: view the details, check the data flow paths, and dismiss an alert.
Code scanning and branch protection rules
Users were already able to configure code scanning as a required check in the branch protection settings in a repository.
With the new code scanning functionality, developers can start a conversation about code scanning alerts. Branch protection rules that require all conversations to be resolved before a PR can be merged apply equally to conversations about code scanning alerts: as soon as a code reviewer comments on a code scanning alert, the PR can not be merged until the conversation is marked as resolved. This helps ensure comments made on alerts are addressed prior to merging.
As you'd expect, when an alert is fixed, the conversation around the alert gets resolved and the PR can be merged.
Learn more about GitHub Advanced Security and code scanning.
Users can now add a comment when dismissing a code scanning alert.
It is optional to provide a dismissal comment. Dismissal comments are recorded in the alert timeline. They can also be set via the code scanning REST API when updating an alert, and retrieved through the new dismissed_comment attribute.
This feature is now available to all users on GitHub.com and will be released in GHES 3.6.
The enterprise and organization level audit logs now record an event when a secret scanning alert is created, closed, or reopened. This data helps GitHub Advanced Security customers understand actions taken on their secret scanning alerts for security and compliance audits.
Dependabot alerts now show all affected files if your repository code is calling known vulnerable functions from the dependency’s vulnerability. Previously, we only highlighted one of these matches on an alert’s detail page, but now users can view all affected files.
This feature supports our public beta of exposure detection for Python alerts. After beta testing with Python we will add support for other ecosystems. Keep an eye on the public roadmap for more information.
For more information, see our product documentation.
GitHub Advanced Security customers can now see an overview of Dependabot alerts at the enterprise level. This page provides a repo-centric view of application security risks, as well as an alert-centric view of all secret scanning and now Dependabot alerts. The views are in beta and will be followed in the coming months by alert-centric views for code scanning.
Learn more about security overview
Learn more about GitHub Advanced Security
GitHub secret scanning protects users by searching repositories for known types of secrets. By identifying and flagging these secrets, we help protect users from data leaks and fraud associated with exposed data.
We have partnered with DigitalOcean to scan for their API keys, which allow users to manage Droplets and resources. We'll forward API keys found in public repositories to DigitalOcean, who will revoke valid keys and email the affected user.
GitHub Advanced Security customers can also scan for DigitalOcean API keys and block them from entering their private and public repositories via secret scanning’s new push protection feature.
GitHub Advanced Security customers can now dry run custom secret scanning patterns at the enterprise level (in addition to the organization and repository levels previously available). Dry runs allow admins to understand a pattern's impact across the entire enterprise and hone the pattern before publishing and generating alerts.
Admins can compose a pattern then 'Save and dry run' to retrieve results from their selected repositories. Scan results will appear on screen as they're detected, but admins can leave the page and later come back to their saved pattern's dry run results.
For more information:
Organizations with GitHub Advanced Security can now prevent secrets leaked in code committed via the command line and the GitHub web editor with secret scanning’s push protection feature.
For repositories with push protection enabled, GitHub will block any pushes where a high-confidence token is detected in a commit made via the web editor. Developers can bypass the block by providing details of why the secret needs to be committed via the 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:
On March 30, 2022, we released CodeQL Action v2, which runs on the Node.js 16 runtime. The CodeQL Action v1 will be deprecated at the same time as GHES 3.3, which is currently scheduled for January 2023.
How does this affect me?
Users of GitHub.com, GitHub AE, and GitHub Enterprise Server 3.5 (and later)
All users of GitHub code scanning (which by default uses the CodeQL analysis engine) on GitHub Actions on the following platforms should update their workflow files:
- GitHub.com (including open source repositories, users of GitHub Teams and GitHub Enterprise Cloud)
- GitHub AE
- GitHub Enterprise Server (GHES) 3.5 and later
Users of the above-mentioned platforms should update their CodeQL workflow file(s) to refer to the new v2 version of the CodeQL Action.
Users of GitHub Enterprise Server 3.4 (and older)
Users of GitHub Enterprise Server 3.4 (and older) are not recommended to update their configuration to use the v2 version of the CodeQL Action:
- GHES 3.3 (and older) does not support running Actions using the Node 16 runtime and is therefore unable to run the
v2version of the CodeQL Action. Please upgrade to a newer version of GitHub Enterprise Server prior to changing your CodeQL Action workflow files. - While GHES 3.4 does support Node 16 Actions, it does not ship with
v2of the CodeQL Action. Users who want to migrate tov2on GHES 3.4 should request that their system administrator enables GitHub Connect to downloadv2onto GHES before updating their workflow files.
The upcoming release of GitHub Enterprise Server 3.5 will ship with v2 of the CodeQL Action included.
Exactly what do I need to change?
To upgrade to the CodeQL Action v2, open your CodeQL workflow file(s) in the .github directory of your repository and look for references to:
github/codeql-action/init@v1github/codeql-action/autobuild@v1github/codeql-action/analyze@v1github/codeql-action/upload-sarif@v1
These entries need to be replaced with their v2 equivalents:
github/codeql-action/init@v2github/codeql-action/autobuild@v2github/codeql-action/analyze@v2github/codeql-action/upload-sarif@v2
Can I use Dependabot to help me with this upgrade?
Yes, you can! For more details on how to configure Dependabot to automatically upgrade your Actions dependencies, please see this page.
What happens in January 2023?
In January 2023, the CodeQL Action v1 will be officially deprecated (at the same time as the GHES 3.3 deprecation). At that point, no new updates will be made to v1, which means that new CodeQL analysis capabilities will only be available to users of v2. We will keep a close eye on the migration progress across GitHub. If many workflow files still refer to v1 of the CodeQL Action we might consider scheduling one or more brownout moments later in the year to increase awareness.