Updated 57 minutes ago

Share this article

Related News

GitHub stopped repository push emails — the replacement moves consent, secrets and cost to you

Oct 16, 2026

GitHub stopped repository push emails — the replacement moves consent, secrets and cost to you

GitHub no longer sends repository push-event emails. Its suggested Actions replacement restores delivery, but repository owners must now manage recipients, SMTP credentials, failure handling and runner usage.

GitHubGitHub Actionsnotifications

GitHub’s agentic autofix can repair 25 code-scanning alerts in one draft pull request

Oct 16, 2026

GitHub’s agentic autofix can repair 25 code-scanning alerts in one draft pull request

GitHub’s generally available agentic autofix explores related files, proposes changes and reruns CodeQL before opening a draft PR. It works on default-branch alerts and uses AI Credits plus Actions minutes.

GitHubagentic autofixcode scanning

GitHub AI Scan is now generally available — but its findings cannot block merges

Oct 16, 2026

GitHub AI Scan is now generally available — but its findings cannot block merges

GitHub’s AI Scan can find pull-request vulnerabilities beyond CodeQL’s current language coverage. Its alerts are advisory, skip forks and Dependabot, and consume Code Security AI Credits.

GitHubAI Scancode scanning

GitHub’s license compliance can now block dependency merges — start in Evaluate mode — Source: GitHub / official license-compliance product imageSource image

Supply Chain Security

GitHub’s license compliance can now block dependency merges — start in Evaluate mode

By OpenTools Team

GitHub’s enterprise license controls are generally available. Active rulesets can block pull requests, while Evaluate mode lets teams measure policy impact before enforcement.

The general release is limited to Enterprise Cloud repositories with Code Security

GitHub made open source license compliance generally available on October 16, 2026. The feature applies to GitHub Enterprise Cloud, including data‑resident Enterprise Cloud, but a repository needs GitHub Code Security enabled before policy can be enforced.

That scope matters. This is not a new universal block on open source packages, and GitHub is not declaring any particular license acceptable for every company. An enterprise defines its own allow policy, then targets repositories through rulesets. The control evaluates new or changed dependencies in pull requests, including transitive dependencies detected in the dependency graph.

The useful change is timing: a license‑policy conflict can now enter the same review path as the code change that introduced it. Teams no longer need to discover every issue later from an inventory export, but the quality of the result still depends on the enterprise policy and the dependency metadata GitHub can see.

Active mode blocks merges; Evaluate mode exposes the impact first

GitHub’s license‑compliance documentation distinguishes two rollout states. An Active ruleset using Requires license compliance results before merging blocks a pull request until a violation is resolved. An Evaluate ruleset runs the check and annotates the pull request without making the license result a merge gate.

Evaluate mode is the safer first deployment for a large portfolio. It reveals which manifests, package ecosystems and transitive dependencies would trigger the proposed policy, while developers can still merge. The result is evidence for adjusting policy, fixing missing metadata and identifying teams that will need an exception workflow.

There is one interaction to test: GitHub says a branch‑protection rule that requires comment resolution can make annotations actionable even when the license rule itself is only evaluating. A staging repository should therefore test the complete ruleset and branch‑protection combination, not assume that the word Evaluate guarantees zero merge friction.

A failed check has three resolution paths with different governance costs

When a dependency violates policy, the developer can remove or replace the package, the enterprise can amend the policy, or an authorized reviewer can approve a package or license exception. GitHub added an Enterprise Open‑Source License Manager role for the people or teams responsible for those closure requests. Pending requests appear in enterprise security views and can generate email notifications.

Those paths are not interchangeable. Replacing a dependency changes engineering work. Amending the enterprise policy changes the baseline for every targeted repository. An exception preserves the baseline but creates a local decision that needs an owner and rationale. Teams should record which path resolved each alert rather than treating every green check as the same outcome.

A practical rollout needs a service‑level target for exception review and a fallback when the assigned reviewers are unavailable. Without that operating path, Active mode can convert a legal‑policy signal into an unpredictable delivery queue.

Audit events and policy APIs make the control usable outside the pull request UI

The general release adds audit‑log events for license‑policy changes and API endpoints to download, update or replace the enterprise policy. GitHub also added an API that checks whether packages comply with policy, which it says can help coding agents avoid recommending or adding packages that an organization would reject. The dependency graph REST reference remains the broader API entry point for dependency changes, submissions and software bills of materials.

The agent use case is preventive: query policy before proposing a dependency, then show the result to the developer. It should not silently turn a policy response into legal advice or invent an exception. API callers also need to pin the API version, authenticate with the minimum permission, retain the policy revision that produced the answer and fail visibly when the policy service is unavailable.

Audit events solve a different problem. They can feed a system of record when policy changes, but an event stream does not by itself explain why a license was allowed or who accepted the downstream risk. Pair the event with the human decision record and the affected repository scope.

A bounded rollout separates policy quality from enforcement reliability

Start with a representative repository set in Evaluate mode. Include more than one package ecosystem, repositories with and without generated lockfiles, and at least one project whose dependency graph contains transitive packages. Measure unsupported or unknown licenses, false policy conflicts, review time and the number of requested exceptions before enabling a merge gate.

Then promote by repository class rather than all at once. GitHub documents a pattern that uses repository custom properties to distinguish inactive, evaluate and active groups, with enterprise policy as a common baseline and repository‑specific exceptions layered on top. Preserve an emergency bypass process with named authority and audit evidence.

The release gives enterprises a native enforcement path, not proof that their license policy is legally complete. The operational win comes from testing the policy, staffing the exception queue and making both human and agent decisions traceable. Follow further GitHub platform changes on the GitHub organization page.

Image: GitHub’s official license‑compliance interface showing a non‑compliant dependency and its resolution timeline; cropped and resized without generative alteration or artificial upscaling.

Sources

1.github.blog (github.blog)
2.docs.github.com (docs.github.com)
3.docs.github.com (docs.github.com)

Tags

GitHubopen source licensessupply chain securitydependency governancecoding agents