GitHub’s Stronger Security Lock Is Not Proof of Repository Coverage
GitHub’s September 15, 2026 changelog announces a real expansion of enterprise authority: enterprise administrators can prevent both organization and repository administrators from overriding settings defined at the enterprise level. Previously, enforcement addressed repository-level owners; the new strongest option adds the organization-administrator boundary.
That improvement answers who may change enterprise-defined settings. It does not prove that every targeted repository successfully attached the configuration, inherited every setting, or can run code scanning. GitHub documents attachment states, partial failures, execution prerequisites, and licensing consequences separately.
The operational control objective should therefore be:
Enterprise-defined settings are immutable to the intended roles, explicitly configured, successfully attached, runnable, and verified at repository level.
The first clause is a confirmed GitHub capability. Treating the complete statement as the control objective is an engineering recommendation, not a GitHub guarantee.
What changed on September 15
GitHub says enterprise administrators can now enforce GitHub Advanced Security configurations across their organizations so that organization and repository administrators cannot override enterprise-defined settings.
A secondary release index, releases.sh, reports three choices in the configuration’s enforcement control:
- Don’t enforce
- Enforce for repository owners
- Enforce for repository and organization owners
The third is the newly significant boundary: it removes override authority from both lower administrative layers. The release index is useful corroboration, but the GitHub changelog remains the primary evidence for the capability and date.
Stronger enforcement does not make every field in a configuration mandatory. It protects the settings the configuration actually governs.
Enforcement protects explicit choices, not omissions
GitHub describes a security configuration as a collection of enablement settings for its security products. In current configuration screens, administrators can choose to enable, disable, or keep the existing settings for individual controls under GitHub Secret Protection, GitHub Code Security, dependency scanning, and private vulnerability reporting.
GitHub’s configuration guide is explicit about the boundary: enforcement blocks changes to features that the configuration sets as enabled or disabled, while features that are not set are not enforced. A stronger administrator lock therefore cannot compensate for an incomplete configuration.
This produces two different questions:
- Policy completeness: Did the configuration explicitly set every control the enterprise intends to govern?
- Policy immutability: Can organization or repository administrators change those explicit choices?
The September 15 change strengthens the second. Teams must still inspect the configuration fields to establish the first.
Repository status is the coverage ledger
GitHub assigns each repository a configuration status representing its current relationship with the applied configuration. The documented statuses are attached, attaching, updating, enforced, removed, removed_by_enterprise, failed, and detached. These states are visible through the repository table, with status information also available through the REST API.
Additional comparison 1
- Status: attached — What GitHub documents: The configuration is actively applied; the repository inherits its settings. — Coverage consequence: Central configuration is active but not necessarily enforced.
- Status: attaching — What GitHub documents: Application is in progress. — Coverage consequence: Do not treat as a completed postcondition.
- Status: updating — What GitHub documents: Configuration changes are being applied. — Coverage consequence: The repository has not yet reached a stable updated state.
- Status: enforced — What GitHub documents: The configuration is applied and enforced. — Coverage consequence: Controlled feature enablement cannot be changed by repository administrators; the September announcement adds the stronger enterprise option for organization administrators.
- Status: removed — What GitHub documents: A repository-level conflict occurred on an unenforced configuration. — Coverage consequence: The configuration remains associated, but the repository no longer inherits every setting.
- Status: removed_by_enterprise — What GitHub documents: An enterprise-level change conflicted with the organization-level configuration. — Coverage consequence: The relationship requires enterprise and organization remediation.
- Status: failed — What GitHub documents: Existing repository settings prevented attachment. — Coverage consequence: Some settings may have applied, but the configuration did not attach successfully.
- Status: detached — What GitHub documents: No configuration is applied; settings are managed individually. — Coverage consequence: Existing settings remain, but central configuration management is absent.
The most important failure behavior is failed. GitHub says an attachment conflict can result in only some settings being applied, and the affected repository will not inherit later configuration changes. A configuration object targeting a repository is therefore insufficient evidence that the repository has complete or continuing coverage.
removed and detached also differ materially. A removed configuration remains associated with the repository but no longer supplies all settings; a detached repository has no applied configuration, although its existing security settings are left unchanged. GitHub also states that a removed repository no longer counts toward that configuration’s coverage metrics.
The practical consequence is straightforward: coverage must be assessed from repository relationships and resulting feature states, not from the existence of an enterprise configuration alone.
Code scanning can remain non-applied under a locked policy
GitHub’s configuration-enforcement reference lists cases where code-scanning enablement will not apply to a repository:
- GitHub Actions was initially enabled and is later disabled.
- GitHub Actions capabilities required by the code-scanning configuration are unavailable.
- The definition of languages that should not be analyzed using code-scanning default setup is changed.
These are documented non-application conditions, not Tech Trend Insight test results. They establish that override resistance and executable scanning are separate properties: a policy can remain protected against administrative changes while its configured scanner is unable to apply as intended.
Existing advanced setup creates a separate attachment conflict
GitHub also documents a conflict when a security configuration sets code-scanning default setup to Enabled and a target repository already has an active advanced setup. In that situation:
- Default setup is not enabled.
- The existing advanced setup continues to run.
- Other enabled security features in the configuration are applied.
- The security configuration does not attach because only part of it applied.
GitHub provides Enabled with advanced setup allowed for mixed repository populations. With this option, an active advanced setup is left unchanged, while default setup is enabled where advanced setup is inactive or absent.
There is an important condition behind “active.” GitHub considers advanced setup inactive if the latest CodeQL analysis is more than 90 days old, all CodeQL configurations have been deleted, or—when Actions runs the advanced setup—the workflow file has been deleted or disabled. A repository thought to be protected by advanced setup may therefore receive default setup if GitHub classifies that setup as inactive.
This option is compatibility logic, not universal preservation of any historical advanced configuration. Repository-level verification remains necessary.
An apparently successful REST call may change nothing
GitHub states that when a user attempts to change a feature’s enablement status through the REST API while that feature is controlled by an enforced configuration, the API call may appear to succeed, but no enablement status changes.
The documentation retrieved for this behavior does not define:
- a specific HTTP status code;
- a guaranteed response-body shape;
- an audit event for the attempted mutation; or
- endpoint-specific polling semantics.
Those details should not be inferred.
Engineering recommendation: automation that changes security enablement should perform a read-after-write check against the resulting feature state and, where relevant, the repository’s configuration status. This recommendation follows from GitHub’s documented no-change behavior; it is not a GitHub statement that one particular endpoint or retry strategy is sufficient.
Request completion is therefore not mutation evidence. The postcondition is the resulting protected state.
Wider enforcement can widen licensed usage
As displayed on GitHub’s Advanced Security plans page on September 16, 2026, the standalone products and public rates are:
| Product | Displayed rate | Billing unit |
|---|---|---|
| GitHub Secret Protection | $19 USD | Per active committer per month |
| GitHub Code Security | $30 USD | Per active committer per month |
GitHub’s current product names are GitHub Secret Protection and GitHub Code Security. Its billing documentation describes them as the two Advanced Security license SKUs; organizations with an older combined GitHub Advanced Security license may encounter different configuration labels.
The displayed rates are public list-page values, not a customer-specific quote. Contract terms and billing models may differ.
GitHub calculates licensed usage from unique, active committers to repositories where the relevant product is enabled. A committer is active when one of that person’s commits has been pushed to an enabled repository within the preceding 90 days, regardless of when the commit was authored. GitHub App bots are ignored.
The documentation adds two important boundaries:
- The active committer must have a GitHub Team or GitHub Enterprise license relationship with the organization or enterprise, including qualifying members, enterprise-managed users, external collaborators, or users with a pending invitation.
- Usage is deduplicated across the organization or enterprise so that contributing to several enabled repositories does not, by itself, consume several licenses for the same product.
Some Advanced Security features are available free for public repositories on GitHub.com. Paid licensing applies to private repositories on GitHub.com and to repositories hosted on GHE.com or GitHub Enterprise Server under the conditions described in GitHub’s billing documentation.
Repository count and employee headcount are therefore poor cost proxies. The billing change depends on product selection, repository scope, contributor overlap, visibility, and billing model. GitHub says its enablement and disablement flow displays an overview of the expected usage change; use that product-specific preview before applying a configuration broadly.
The documentation boundary is still uneven
The September 15 changelog uses the expanded formulation: both organization and repository administrators can be prevented from overriding enterprise-defined settings.
However, current GitHub documentation pages retrieved on September 16 still contain narrower language. The general enforcement reference says enforcement means repository owners cannot change controlled feature enablement, while the enterprise configuration guide describes Enforce configuration as blocking repository owners and does not yet spell out the new organization-administrator option in the same passage.
That wording gap supports a limited conclusion: the changelog establishes the new enterprise authority boundary, while some documentation surfaces have not yet converged on it.
It does not establish a universal tenant rollout schedule, identical user-interface availability in every account, or a complete authorization matrix for every operation—such as feature mutation, detachment, retargeting, and configuration editing. Those remain open until GitHub documents them or they are observed in a specific tenant.
Proposed validation tests
The following are proposed tests that Tech Trend Insight has not performed. Results should be reported as tenant-specific observations, not generalized product benchmarks.
1. Record the tenant’s enforcement options
In a non-production GitHub Enterprise Cloud environment, capture the date, enterprise context, plan, and exact enforcement choices shown. Compare the observed options with the September 15 changelog and the three choices reported by releases.sh.
2. Audit explicit fields before applying the lock
Export or record every security-configuration field and classify it as enabled, disabled, or left at its existing setting. Flag any control that policy owners expect to be mandatory but that the configuration does not explicitly set.
3. Exercise each repository relationship
Apply a benign configuration to controlled repositories representing compatible settings, an attachment conflict, an existing active advanced setup, and no applied configuration. Record the resulting configuration status and feature state without assuming a convergence duration.
4. Preserve the REST evidence
Attempt an otherwise valid feature-state change against an enterprise-enforced setting from an authorized test role. Preserve the raw status, headers, and body, then read the resulting feature state and configuration status separately. Do not predict the HTTP response or audit record in advance.
5. Test default-setup prerequisites independently
Evaluate GitHub Actions availability, later Actions disablement, advanced-setup activity, and language-exclusion changes as separate cases. A single successful attachment test does not cover all documented non-application conditions.
6. Preview each product’s usage change
Run the enablement preview separately for GitHub Secret Protection and GitHub Code Security. Reconcile the result with repository visibility, unique active committers, contributor overlap, the 90-day condition, and the organization’s metered or subscription billing model.
A defensible enforcement decision
Use the strongest enterprise enforcement option only when evidence shows that every repository in scope satisfies five postconditions:
- Explicit: Required controls are enabled or disabled in the configuration rather than left unchanged.
- Related: Each repository has reached the intended stable configuration status—normally
enforcedfor a locked policy—notfailed,removed,removed_by_enterprise, ordetached. - Runnable: GitHub Actions, CodeQL setup, runner selection, and other documented prerequisites support the configured behavior.
- Verified: Resulting feature states are read back after administrative or API operations.
- Licensed intentionally: The product, repository population, active-committer scope, and billing preview match the approved deployment.
If one of these conditions fails, the remedy is not a stronger lock. It is to correct the omitted setting, attachment conflict, execution prerequisite, repository targeting, or licensing decision first.
GitHub’s September 15 change makes enterprise intent harder to override. Only repository-level state and execution evidence show whether that intent became operational protection.
Official Sources
- Enforce GitHub Advanced Security configurations — GitHub Changelog
- Creating a custom security configuration for your enterprise — GitHub Docs
- Security configuration enforcement — GitHub Docs
- Security configuration statuses — GitHub Docs
- Diagnosing security configuration issues — GitHub Docs
- A repository is using advanced setup for code scanning — GitHub Docs
- GitHub Advanced Security plans
- GitHub Advanced Security license billing — GitHub Docs
