Docs

Appearance

GitHub Organization Management Guide ​

Overview ​

Cirius Group's GitHub organization is Cirius-Group-Inc. This guide covers day-to-day org management: adding/removing members, managing repositories, branch protections, and understanding the kobe-bot account.

Organization owners can access org settings at https://github.com/orgs/Cirius-Group-Inc/settings. Rory is the primary org owner. Greg or Kevin should be added as backup owners.

Organization Members ​

Current Members ​

AccountRolePurpose
roryg20OwnerPrimary human admin
cirius-kobe-botMemberAI agent account — automated PRs and read-only infra access

Adding a New Member ​

When a new engineer joins and needs GitHub access:

  1. The new member must have a personal GitHub account
  2. Org owner invites them: Org Settings → Member privileges → People → Invite member
  3. Enter their GitHub username or email
  4. Select role: Member (not Owner) — only Rory should be Owner
  5. They receive an email invitation and must accept within 7 days

After accepting:

  • Give them read access to repos they need: Repo → Settings → Collaborators and teams → Add people
  • For infra repos (azure-infra, aws-infra, etc.): read-only access by default. Write access requires explicit approval from Rory.

Removing a Member (Offboarding) ​

  1. Org Settings → People → find the member → Remove from organization
  2. This immediately revokes their access to all private repos
  3. Any PRs they opened remain open but they can no longer push
  4. Their forks of private repos are deleted automatically

Do this the same day as account offboarding — GitHub access should be revoked simultaneously with Entra account disable.

Org Roles ​

RoleWhat They Can Do
OwnerFull org admin — billing, settings, add/remove members, delete repos
MemberPush to repos they have write access to; create repos (if allowed by policy)
Outside CollaboratorAccess only to specific repos explicitly granted. For contractors.

Contractors should be added as Outside Collaborators on specific repos only — not as full org members. This limits their blast radius if their account is compromised.

Repository Management ​

Current Repositories ​

RepoPurposeAuto-Merge
azure-infraAzure production TerraformOFF — manual review required
aws-infraAWS all-account TerraformOFF — manual review required
azure-dde-infraDDE environment TerraformOFF — manual review required
ops-automationSecurity agents, compliance pipelinesOFF — manual review required
palo-alto-configsFirewall configurationOFF — manual review required
bedrock-docsArchitecture documentationON — squash merge
bedrock-socSecOps platform (FastAPI + PostgreSQL)ON
bedrock-grcGRC platformON
bedrock-findingsVulnerability managementON
bedrock-projectsProject management toolingON
bedrock-attackRed team toolingON
bedrock-scannerCode analysis toolingON

Auto-merge is OFF for all Terraform infra repos. These touch production infrastructure and require Rory's explicit review before merge. All other repos have auto-merge enabled.

Creating a New Repository ​

  1. GitHub → New repository or Org → Repositories → New
  2. Name: lowercase, hyphens (e.g., new-service-name)
  3. Visibility: Private — no Cirius repos are public
  4. Initialize with a README
  5. After creation, configure branch protections (see below)
  6. For Terraform repos: set up the standard CI workflow from another infra repo as a reference

Repository Settings Checklist (New Repos) ​

After creating a repo, configure:

  • [ ] Branch protection on main (see Branch Protections section below)
  • [ ] Auto-merge enabled or disabled per the policy above
  • [ ] Delete branch on merge: enabled
  • [ ] Allow squash merge: enabled; disable merge commits and rebase merge (keep it clean)
  • [ ] Add to the appropriate GitHub Actions secrets (if it needs OIDC or other secrets)
  • [ ] Add cirius-kobe-bot as a collaborator with Write access (needed to open PRs)

Branch Protections ​

Branch protections on main prevent direct pushes and ensure all changes go through reviewed PRs. All repos should have these configured.

Standard Protection Rules for main ​

Repo → Settings → Branches → Branch protection rules → Add rule (pattern: main):

  • [x] Require a pull request before merging
    • Required approvals: 1 (Rory is the approver for infra repos)
    • Dismiss stale reviews when new commits are pushed: enabled
  • [x] Require status checks to pass before merging
    • Add the repo's CI checks (e.g., terraform-plan, checkov, build)
  • [x] Require branches to be up to date before merging
  • [x] Restrict who can push to matching branches — only owners/admins can push directly
  • [x] Do not allow bypassing the above settings — applies to admins too

Verifying Branch Protections Are Set ​

bash
# Check protection rules on main for a repo
gh api repos/Cirius-Group-Inc/azure-infra/branches/main/protection \
  --jq '{required_approvals: .required_pull_request_reviews.required_approving_review_count, status_checks: .required_status_checks.contexts}'

The kobe-bot Account ​

cirius-kobe-bot is the AI agent's GitHub account. It has Member role in the org and write access to repos where it needs to open PRs.

What kobe-bot Can Do ​

  • Open pull requests (its branches are prefixed kobe/)
  • Push to its own branches
  • Comment on PRs
  • Merge PRs on repos where auto-merge is enabled (after CI passes)

What kobe-bot Cannot Do ​

  • Approve its own PRs (requires a human reviewer)
  • Push directly to main (blocked by branch protection)
  • Merge PRs on infra repos (auto-merge is off — requires human approval)
  • Modify org settings or add members

kobe-bot Token Management ​

The kobe-bot GitHub token is stored in Keeper → Infrastructure — Shared → GitHub Token — kobe-bot. The token has repo scope on the Cirius-Group-Inc org.

If the token expires or is revoked:

  1. Log into GitHub as kobe-bot (credentials in Keeper)
  2. Settings → Developer settings → Personal access tokens → Generate new token (classic)
  3. Scopes: repo, read:org
  4. Update the token in Keeper and in any secrets (Azure Key Vault or GitHub Actions secrets) that store it

Auditing kobe-bot Activity ​

To see what kobe-bot has done recently:

bash
# All PRs opened by kobe-bot across the org
gh pr list --repo Cirius-Group-Inc/bedrock-docs --author cirius-kobe-bot --state all --limit 20
gh pr list --repo Cirius-Group-Inc/azure-infra --author cirius-kobe-bot --state all --limit 20

Or on GitHub: Org → Audit log → filter by actor: cirius-kobe-bot.

GitHub Actions and OIDC ​

All CI/CD workflows use OIDC federated authentication — no stored long-lived tokens in GitHub secrets.

OIDC Identity Configuration ​

The OIDC trust is set up in each cloud provider with the exact org name:

  • Azure: federated credentials bound to repo:Cirius-Group-Inc/<repo>:ref:refs/heads/main
  • AWS: OIDC provider token.actions.githubusercontent.com with audience sts.amazonaws.com

Critical: The org name in OIDC configs must be exactly Cirius-Group-Inc (with the hyphen and capital letters). A mismatch breaks authentication silently with AccessDenied.

GitHub Actions Secrets ​

Org-level secrets (available to all repos):

  • None currently — all auth is OIDC, no stored credentials

Repo-level secrets (per repo where needed):

  • Check each repo's Settings → Secrets and variables → Actions for what's configured
  • Add new secrets there, not at the org level, to limit blast radius

For full OIDC setup details see OIDC Authentication.

Security Settings ​

Org Security Overview ​

GitHub Org → Settings → Code security and analysis:

  • Dependabot alerts: enabled on all repos — flags vulnerable dependencies
  • Secret scanning: enabled — alerts if credentials are accidentally committed
  • Code scanning: enabled on repos that have CodeQL or other scanners configured

Reviewing Security Alerts ​

bash
# List Dependabot alerts across a repo
gh api repos/Cirius-Group-Inc/bedrock-soc/dependabot/alerts --jq '.[] | {id: .number, severity: .security_vulnerability.severity, package: .dependency.package.name}'

# List secret scanning alerts
gh api repos/Cirius-Group-Inc/bedrock-soc/secret-scanning/alerts --jq '.[] | {id: .number, type: .secret_type, state: .state}'

Secret scanning alerts are highest priority — a committed credential is an active risk regardless of whether the commit is still in history (it's accessible via git log even if the file was later changed).

If a Secret Is Committed ​

  1. Rotate the secret immediately — assume it's compromised the moment it's pushed
  2. Revoke the old credential at the source (Key Vault, AWS, GitHub token settings)
  3. Remove from the repo: git filter-repo --invert-paths --path <file> or use BFG
  4. Force-push the cleaned history (requires branch protection bypass — coordinate with Rory)
  5. Document the incident in SecOps

Audit Log ​

GitHub maintains an audit log of all org events. Access at: Org → Settings → Audit log

Or via API for automation:

bash
gh api orgs/Cirius-Group-Inc/audit-log \
  --paginate \
  --jq '.[] | select(.action | startswith("repo")) | {action, actor, repo: .repo, created_at: .created_at}' \
  | head -20

The audit log captures: member changes, repo creation/deletion, branch protection changes, OAuth app authorizations, and all admin actions. Export this for SOC2 evidence if an auditor asks about GitHub access controls.

Document History ​

DateChangeAuthor
May 2026Initial draft — org members, repo inventory, branch protections, kobe-bot capabilities and token management, OIDC, security alerts, audit log.Rory

Internal use only — Cirius Group