Codespaces now offers organization policies to restrict port visibility settings

Currently, forwarded ports within codespaces can be set to private in which case they can be accessed only by the owner of the codespace, be shared with members of the organization or be set to public at which point anyone the URL is shared with can view the port. We heard from many organization admins that they want to disable public ports for organization-owned codespaces with the goal of ensuring that company assets can only be shared and accessed by members of the organization for security purposes.

With this feature, we have added the ability for organization admins to add port visibility constraints that enable them to control which visibility settings are available within organization-owned codespaces. For instance, admins will be able to disable the 'public' visibility port setting for desired repositories within their organization and enable developers to continue sharing ports only with members of their organization. This would be done to help preventing codespaces users from accidentally exposing company owned assets to unauthorized individuals.
port visibility policy constraint image

We will continue adding additional policy constraints based on feedback, some of which include setting a maximum idle timeout, setting maximum retention periods, setting allowed container images, and more. We'd love your feedback on additional policies that will help your scenarios.

For more information, see Restricting the visibility of forwarded ports

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:

See more

Code scanning alerts now show their analysis origin

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-analysis-origins

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
View all changes