Protect Critical GitHub Repositories

Model high-impact GitHub repositories, workflows, and deployment paths as protected Privilege Zone boundaries.

In source code platforms, a critical asset may be a repository, workflow, deployment environment, secret, app installation, personal access token, or role that can influence production systems.

GitHub is a strong example. Some repositories are sensitive because they contain important code. Others are sensitive because a commit, pull request, workflow, app installation, or token can trigger follow-on actions that affect downstream infrastructure.

Privilege Zones can help teams isolate and analyze attack paths into high-impact GitHub assets.

Scenario

A software company uses GitHub Actions to build and deploy code into a cloud environment. Several repositories contain workflows that can deploy infrastructure, publish production artifacts, or assume cloud roles through OIDC federation.

The security team creates a Privilege Zone around the repositories and GitHub objects that can influence production deployment. The zone may include:

• Production application repositories
• Infrastructure-as-code repositories
• Repositories with workflows that deploy to production
• Repositories with privileged GitHub Actions workflows
• Repositories that publish production containers or packages
• Repositories with access to cloud deployment secrets
• Organization or repository secrets
• GitHub environments tied to production deployment
• GitHub teams or roles with administrative access
• GitHub environments tied to production
• Personal access tokens with broad write scope
• Workflows that can assume cloud roles or access deployment credentials
• Organization owner roles
• All-repository admin roles
• App installations scoped to all repositories with write permissions
• Personal access tokens scoped to all repositories with write permissions

The objective is to answer a simple question: who or what can influence code or workflows that can affect production?

What this can reveal

• Users or teams with write, maintain, or admin access to critical repositories
• Repository administrators with broader access than intended
• Workflows that can access secrets or deployment environments
• GitHub Apps with write access to all repositories
• Personal access tokens scoped broadly across the organization
• Paths from identity providers into GitHub roles
• GitHub permissions that can lead to cloud access
• Repositories that function as indirect control points for production

Why this works

In GitHub, privilege is often contextual. A repository may be critical because it stores sensitive code, but it may also be critical because it can trigger a workflow, deploy infrastructure, publish an artifact, or assume a role in a cloud environment.

That makes GitHub a strong candidate for Privilege Zones. The zone can define the repositories, workflows, teams, apps, and secrets that matter most, then BloodHound Enterprise can help identify attack paths that lead to them.

Suggested workflow

1. Identify repositories that can affect production or critical infrastructure.
2. Identify workflows that deploy, publish, or assume cloud roles.
3. Identify secrets, environments, teams, and roles connected to those repositories.
4. Create a zone around those GitHub objects.
5. Analyze who or what can control the zone.
6. Validate findings with application, platform, DevOps, and cloud owners.
7. Reduce unnecessary access and monitor the zone over time.

Starter Cypher queries

These example Cypher queries help you identify candidate objects for zones and labels during discovery, trials, and early implementation.

Review and tune these queries before using them as production Privilege Zone rules.

For queries covering owner roles, all-repository admin access, app installations, personal access tokens, and external identity mappings, see the GitHub extension’s Privilege Zone Rules page.

Production repository discovery

MATCH (n:GH_Repository)
WHERE toUpper(COALESCE(n.name, '')) CONTAINS 'PROD'
   OR toUpper(COALESCE(n.name, '')) CONTAINS 'PRODUCTION'
   OR toUpper(COALESCE(n.name, '')) CONTAINS 'PRD'
RETURN n
LIMIT 1000

Infrastructure-as-code repository discovery

MATCH (n:GH_Repository)
WHERE toUpper(coalesce(n.name, '')) CONTAINS 'TERRAFORM'
   OR toUpper(coalesce(n.name, '')) CONTAINS 'TF'
   OR toUpper(coalesce(n.name, '')) CONTAINS 'IAC'
   OR toUpper(coalesce(n.name, '')) CONTAINS 'INFRA'
   OR toUpper(coalesce(n.name, '')) CONTAINS 'CLOUD'
RETURN n
LIMIT 1000

Guidance

GitHub zones should be defined around impact. A repository named production may be important. A repository with a workflow that can deploy to production may be even more important. Work with platform engineering, DevOps, application owners, and cloud teams to understand which repositories create downstream control.

Key takeaway

In OpenGraph-connected environments, critical assets may be repositories, workflows, secrets, app installations, tokens, or deployment relationships. Privilege Zones help teams define those assets and understand the attack paths that can influence them.