Managing GitHub Advanced Security Policies Across an Enterprise

Managing security for a few repositories is relatively simple. Managing it across hundreds or thousands of repositories is a different problem.

Large organizations often have multiple teams, programming languages, repository types, and security requirements. If every repository configures GitHub security features independently, security coverage can quickly become inconsistent.

One repository may have code scanning enabled, another may rely only on Dependabot, and another may have secret scanning configured differently.

GitHub provides security configurations, enterprise policies, and organization-level controls to help administrators standardize security settings across repositories. GitHub's current documentation describes security configurations as collections of security enablement settings that can be applied across organizations and enterprises.

This article explains how these controls fit together and how administrators can approach enterprise-wide GitHub Advanced Security management without creating unnecessary configuration complexity.

Why Enterprise Security Policies Matter

A large GitHub environment can contain repositories with very different characteristics.

For example:

Enterprise
|
+-- Organization A
|     +-- 120 repositories
|
+-- Organization B
|     +-- 75 repositories
|
+-- Organization C
      +-- 300 repositories

If security settings are managed individually, administrators have to track hundreds of configurations.

That creates several risks:

Security features may be missing from new repositories.
Different teams may use different configurations.
Security settings can drift over time.
Administrators may not know which repositories are protected.
Updating a security requirement becomes difficult.

Centralized policies help reduce this configuration drift.

What Is GitHub Advanced Security?

GitHub Advanced Security brings together security capabilities designed to help organizations identify and prevent vulnerabilities in their source code and development workflow.

Depending on the GitHub plan and configuration, organizations can use capabilities such as:

Code scanning
Secret scanning
Push protection
Dependency-related security features
Dependabot security capabilities
Security configurations
AI-assisted security features

The exact features available depend on the organization's GitHub plan and configuration.

For enterprise environments, GitHub provides controls for managing security features across organizations and repositories.

Security Configuration vs Enterprise Policy

These two concepts are easy to confuse.

A security configuration defines a collection of security settings that can be applied to repositories.

An enterprise policy controls how organizations and repository administrators can use certain security capabilities.

A simplified model is:

Enterprise Policy
       |
       v
Who can use or change security features?
       |
       v
Security Configuration
       |
       v
Which security settings are enabled?
       |
       v
Repositories

They solve different problems.

Enterprise Policy

Policies control availability and administrative behavior.

For example, an enterprise can control whether organizations are allowed to use certain security products or whether repository administrators can change particular security settings.

Security Configuration

A configuration defines the actual collection of security settings applied to repositories.

GitHub allows security configurations to be created at enterprise and organization levels and attached to repositories.

What Can an Enterprise Policy Control?

GitHub provides enterprise policies for areas such as:

Availability of Advanced Security features
Dependency insights
Dependabot alerts
Advanced Security features in repositories
AI detection for secret scanning
Copilot Autofix
AI Scan

GitHub documents these as enterprise-level policies that can control security capabilities across organizations owned by an enterprise.

This is particularly useful when an enterprise wants consistent governance.

For example:

Enterprise
|
+-- Security Policy
|     |
|     +-- Approved organizations
|     +-- Approved security features
|
+-- Organization
      |
      +-- Security Configuration
            |
            +-- Code scanning
            +-- Secret scanning
            +-- Dependency features

Creating a Security Configuration

A security configuration is a reusable collection of security settings.

For example, an organization might create:

Configuration: Standard Engineering

Code Security: Enabled
Secret Scanning: Enabled
Push Protection: Enabled
Dependency Graph: Enabled
Dependabot Alerts: Enabled

Another configuration could be designed for repositories with stricter requirements:

Configuration: High Security

Code Security: Enabled
Secret Scanning: Enabled
Push Protection: Enabled
Dependency Graph: Enabled
Dependabot Alerts: Enabled
Additional protections: Enabled

The actual options available depend on the GitHub security products enabled for the enterprise.

GitHub's documentation provides support for creating custom configurations at enterprise and organization levels.

Why Use Multiple Configurations?

One configuration does not necessarily fit every repository.

Consider an enterprise with:

Public open-source repositories
Internal applications
Customer-facing APIs
Financial systems
Experimental projects
Archived repositories

Applying exactly the same security settings to every repository may not be practical.

A better approach is to define a small number of meaningful security profiles.

For example:

Configuration	Intended repositories
Standard	General engineering repositories
High Security	Sensitive production applications
Open Source	Public repositories
Legacy	Repositories requiring transitional settings

The objective should be consistency without creating dozens of nearly identical configurations.

Applying a Configuration to Repositories

GitHub allows enterprise security configurations to be attached to repositories through the REST API.

For example, an enterprise configuration can be attached to repositories using an endpoint similar to:

curl -L \
  -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/enterprises/ENTERPRISE/code-security/configurations/CONFIGURATION_ID/attach \
  -d '{"scope":"all"}'

GitHub documents this enterprise configuration attachment operation and returns an accepted response when the request is processed.

The exact token type and permissions required depend on the operation.

Never place a real access token directly in source code or a committed workflow.

Setting Defaults for New Repositories

One of the most useful enterprise controls is setting a security configuration as a default.

This helps address a common problem:

Existing repositories
        |
        +-- Protected

New repository
        |
        +-- Security settings forgotten

An enterprise-level default can apply a selected configuration to new repositories matching a specified repository visibility.

GitHub supports default configuration values such as:

All
Public
Private and internal
None

The exact precedence rules matter when both enterprise and organization defaults are configured.

Why New Repository Coverage Matters

Security teams often focus on existing repositories and forget repository creation.

Suppose an enterprise has 500 protected repositories.

A new team creates repository number 501.

If security configuration is entirely manual, repository 501 may temporarily have different security coverage.

This creates a gap:

Repository Created
       |
       v
Security Configuration
       |
       +-- Automatically applied
       |
       v
Protected Repository

Default configurations reduce this manual step.

Enterprise Enforcement

A security configuration can be configured as enforced.

When a configuration is enforced, repository owners cannot change the enablement status of features controlled by that configuration. GitHub documents enforcement as a mechanism for preventing repository-level changes to enforced security settings.

This is useful when security requirements are mandatory.

For example:

Enterprise Requirement
        |
        v
Secret Scanning Must Be Enabled
        |
        v
Enforced Configuration
        |
        v
Repository Administrators
        |
        X
Cannot disable controlled setting

Without enforcement, repository administrators may have more freedom to modify their security settings.

Enforcement Requires Careful Planning

Enforcement should not be treated as simply switching everything on.

GitHub documents situations that can affect enforcement, including cases involving GitHub Actions availability and code scanning requirements.

For example, code scanning configurations may depend on GitHub Actions.

If Actions are unavailable or disabled for a repository, the expected code scanning configuration may not operate as intended.

Before enforcing a configuration, verify:

Required Actions are available.
Repositories meet the configuration requirements.
Required permissions exist.
Repository visibility is covered.
The configuration has been tested.
Exceptions are understood.

Enterprise Policy Precedence Matters

Large GitHub environments can have controls at multiple levels.

A simplified model is:

Enterprise
   |
   +-- Enterprise policy
   |
   +-- Enterprise security configuration
          |
          v
     Organization
          |
          +-- Organization policy
          |
          +-- Organization configuration
                 |
                 v
             Repository

The actual precedence depends on the specific setting.

GitHub documents cases where an enterprise-enforced configuration takes precedence over an organization-level default for the same repository visibility.

This is why administrators should understand the hierarchy before troubleshooting a setting that appears to be "stuck."

Enterprise and Organization Configurations

Security configurations can exist at different scopes.

An enterprise administrator can create an enterprise configuration.

An organization can also create organization-level configurations.

For example:

Enterprise Configuration
       |
       +-- Organization A
       +-- Organization B
       +-- Organization C

An organization can also maintain configurations specific to its repositories.

This allows central governance while still supporting organization-specific requirements.

Managing Security at Scale With the REST API

For large enterprises, the GitHub REST API can reduce repetitive administration.

The API supports operations for:

Listing configurations
Creating configurations
Updating configurations
Attaching configurations
Setting defaults
Inspecting configuration details
Removing configurations

GitHub's current REST API documentation includes enterprise configuration endpoints for these operations.

A typical automation workflow might look like:

Security Policy
      |
      v
Configuration Definition
      |
      v
API Automation
      |
      +---- Organization A
      +---- Organization B
      +---- Organization C
      |
      v
Repository Coverage

Example: Discover Enterprise Configurations

A request to list enterprise configurations follows the pattern:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/enterprises/ENTERPRISE/code-security/configurations

GitHub requires enterprise administrator permissions for the enterprise configuration endpoint. The required authentication scope also depends on the authentication mechanism.

For automation, use a dedicated credential with only the permissions required for the operation.

Example: Inspect a Configuration

Once you have a configuration ID:

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/enterprises/ENTERPRISE/code-security/configurations/CONFIGURATION_ID

The response contains configuration information such as:

{
  "id": 1325,
  "name": "Standard Security",
  "code_security": "enabled",
  "dependency_graph": "enabled",
  "dependabot_alerts": "enabled",
  "secret_scanning": "enabled",
  "secret_scanning_push_protection": "enabled",
  "enforcement": "enforced"
}

The fields available depend on the configuration and current GitHub API behavior. GitHub's API documentation provides the current response schema.

Do Not Hard-Code Security Assumptions

A common automation mistake is assuming that every enterprise has the same configuration ID.

For example:

CONFIGURATION_ID=1325

should not be treated as a universal value.

Configuration IDs belong to specific GitHub environments.

A better approach is:

1. Discover configuration
2. Identify configuration ID
3. Validate configuration
4. Apply configuration
5. Verify repository status

This makes automation more portable.

Monitoring Repository Coverage

Creating a configuration is only the beginning.

Security administrators should regularly check:

Which repositories are attached
Which repositories failed to attach
Which repositories are unmanaged
Which repositories have exceptions
Which configurations are enforced
Whether required security features are active

GitHub provides security coverage management capabilities for enterprise and organization environments.

A useful internal report might look like:

Repository	Configuration	Enforcement	Status
Orders API	Standard	Yes	Attached
Payments API	High Security	Yes	Attached
Internal Tool	Standard	No	Attached
Legacy App	Legacy	No	Review
New Service	Standard	Yes	Attaching

This makes gaps easier to identify.

Handling Legacy Repositories

Not every repository can immediately adopt the same security configuration.

Legacy applications may have:

Unsupported languages
Old build systems
Disabled Actions
Custom scanning workflows
Infrastructure limitations
Existing security tooling

Instead of ignoring these repositories, define a migration path.

For example:

Legacy Repository
       |
       v
Assess
       |
       +-- Fully compatible
       |       |
       |       v
       |   Standard Configuration
       |
       +-- Partially compatible
       |       |
       |       v
       |   Remediation Plan
       |
       +-- Exception required
               |
               v
          Documented Exception

An exception should be visible and reviewed rather than becoming permanent undocumented drift.

Common Mistakes

Mistake 1: Creating Too Many Configurations

If every team receives a slightly different configuration, centralized management becomes difficult.

Keep the configuration model small and understandable.

Mistake 2: Enforcing Before Testing

An incorrectly designed enforced configuration can affect many repositories at once.

Test with a representative subset first.

Mistake 3: Ignoring GitHub Actions Dependencies

Some security capabilities depend on Actions.

Check repository Actions availability before applying configurations that depend on it. GitHub specifically documents this as a factor that can break enforcement.

Mistake 4: Forgetting New Repositories

Protecting existing repositories does not automatically solve future repository coverage.

Use appropriate defaults and monitor new repositories.

Mistake 5: Treating Security Configuration as a One-Time Task

Security requirements change.

Configurations should be reviewed when security policies, GitHub capabilities, or organizational requirements change.

Mistake 6: Using Excessive API Permissions

Automation should use credentials with the minimum permissions required.

Do not give a repository workflow enterprise-administrator credentials simply because an API script needs to read configuration information.

Troubleshooting Configuration Problems

A Repository Did Not Receive the Configuration

Check:

Repository visibility.
Configuration scope.
Enterprise or organization policy.
Whether another configuration is already attached.
Whether required GitHub features are available.
Configuration status.

GitHub provides configuration status information that can help administrators identify attachment problems.

Repository Administrator Cannot Change a Setting

First determine whether the configuration is enforced.

An enforced configuration intentionally prevents repository-level changes to controlled enablement settings.

Configuration Exists but a Feature Is Disabled

Inspect the actual configuration rather than relying on the configuration name.

For example:

Configuration: Standard Security

does not tell you what is enabled.

Inspect the individual settings.

REST API Reports Success but Nothing Changes

GitHub documents that attempts to change the enablement status of a feature controlled by an enforced configuration can appear successful through the REST API while the enablement status remains unchanged.

Check whether enforcement is responsible before troubleshooting the API request itself.

Best Practices

Define a Security Baseline

Create a documented baseline that explains the minimum expected security coverage.

For example:

Minimum Baseline

[✓] Dependency Graph
[✓] Dependabot Alerts
[✓] Code Scanning
[✓] Secret Scanning
[✓] Push Protection

The actual baseline should reflect the organization's requirements and available GitHub products.

Use Configurations Instead of Manual Repository Changes

Security configurations make repeated settings easier to manage at scale. GitHub recommends security configurations as a way to apply security settings across repositories.

Separate Standard and High-Security Workloads

Not every repository necessarily requires identical settings.

Use a small number of clearly defined profiles.

Automate Coverage Checks

Use the GitHub API where appropriate to identify repositories that are:

Unmanaged
Misconfigured
Missing required protection
Attached to outdated configurations

Review Exceptions Regularly

If a repository is excluded from the standard configuration, record why.

Set a review date where appropriate.

Test Before Enforcement

Start with a controlled group of repositories.

Verify that:

Builds continue to work.
Security scans run.
Alerts appear correctly.
Actions workflows work.
Developers understand the new controls.

Then expand coverage.

Advantages and Disadvantages

Advantages	Disadvantages
Centralizes security management	Requires careful initial design
Reduces configuration drift	Enforcement can affect many repositories
Supports enterprise-wide standards	Legacy repositories may require exceptions
Helps automate repository coverage	Policies and configurations can be complex
Supports consistent security controls	GitHub Actions availability can affect some configurations
Enables API-based administration	API automation requires careful permission management

A Practical Enterprise Security Model

A manageable enterprise setup can look like this:

Enterprise Security Policy
          |
          v
Security Baseline
          |
    +-----+------+
    |            |
    v            v
Standard       High Security
Config         Config
    |            |
    +-----+------+
          |
          v
Organizations
          |
          v
Repositories
          |
          v
Coverage Monitoring

This structure separates governance from implementation.

The enterprise defines the overall requirements.

Configurations define how those requirements are implemented.

Repositories inherit or attach to the appropriate configuration.

Monitoring identifies gaps.

Summary

Managing GitHub Advanced Security across an enterprise is primarily a governance and consistency problem. With many organizations and repositories, manually configuring security features becomes difficult to maintain and increases the risk of configuration drift.

GitHub provides enterprise policies to control how security capabilities can be used and security configurations to group security settings that can be applied across repositories. These configurations can be attached to repositories, used as defaults for new repositories, and, where appropriate, enforced.

For larger environments, the REST API can also automate configuration discovery, creation, attachment, and management.

The practical approach is to start with a clear security baseline, create a small number of reusable configurations, test them against representative repositories, and then expand coverage. Enterprise enforcement should come only after dependencies and exceptions have been understood.

Most importantly, enterprise security should not be treated as a single switch. Effective management combines policy, configuration, repository coverage, automation, monitoring, and periodic review.