GitHub Enterprise Server 3.7: New automation, security, and policy controls
GitHub has made version 3.7 of its self-hosted Enterprise Server (GHES) generally available. The release focuses on expanding automation capabilities, improving security visibility, and giving administrators more control over repository management across their organizations.
Actions expands its automation toolbox
Reusable workflows, first introduced in GHES 3.5, get two significant upgrades in this release. Teams can now nest reusable workflows inside one another, allowing for quick assembly of compliant automation from existing building blocks. Additionally, reusable workflows now support matrix job definitions, making it possible to run a single CI job across multiple environments (like different operating systems) with one configuration.
GitHub Pages users can also deploy sites directly from a repository using GitHub Actions. This positions Actions as a single CD provider for both applications and Pages, complete with deployment gates and environments.
Administrators gain a new storage option: Google Cloud Storage can now be configured from the management console to hold Actions logs, artifacts, and caches.
New policies for healthier repository ownership
GHES 3.7 introduces several changes aimed at supporting innersource practices while keeping repositories within auditable, policy-compliant structures. Developers can now fork a repository into the same organization and name the fork at the same time; the fork retains the visibility (private, public, or internal) of its upstream repository.
Two new enterprise-wide policies complement this workflow. Administrators can restrict all new repository creation to organizations only, and can likewise restrict forks to organizations only. Together these policies prevent the sprawl of repositories in personal namespaces, which can create audit gaps and long-term maintenance problems when developers leave.
Streamlined identity and access management
A private beta of SCIM user management is now available, addressing the disconnect between SAML SSO and user lifecycle management. Administrators can provision and suspend user accounts automatically through new SCIM APIs, and populate team membership directly from an identity provider like Azure Active Directory or Okta. This removes much of the manual, time-sensitive work involved in offboarding.
The management console itself has also been hardened with stricter password policies and a complete audit log.
A consolidated view of security posture
Security overview is now available to every enterprise customer. Found in the Code Security tab of the enterprise account, it aggregates Dependabot alerts, code scanning alerts, secret scanning alerts, and related findings into a single interface for security teams, engineering leaders, and developers.
More complete dependency and alert visibility
The dependency graph has historically had a blind spot with certain manifest formats—Gradle, Scala SBT, and Maven cannot always be scanned statically or may not include transitive dependencies. The dependency submission API lets CI workflows submit dependencies from recent builds to the dependency graph in a simplified software bill of materials (SBOM) format. Once submitted, those dependencies appear in the graph and can trigger Dependabot alerts for vulnerabilities.
Code scanning alerts are now displayed directly on a pull request's Conversation tab as interactive annotations. Developers can comment on the annotations and use existing triage features such as showing paths, dismissing alerts, and viewing details.
For upgrade guidance, GitHub points administrators to the Upgrade Assistant, which maps a path from the current GHES version to 3.7. The release notes and download are available on the GitHub Enterprise site.
