Manual / Infrastructure / GitHub / Repository Rulesets and Security Hardening
Cloudberrie Business & Operations Manual

Repository Rulesets and Security Hardening

Protect production branches, enforce review, and enable available code-security controls.

Document: INF-108Type: Guide / SOPStatus: ApprovedOwner: Engineering OperationsVersion: 4.2.0Updated: 2026-07-17
Cloudberrie GitHub configuration
Actual GitHub Free private-repository security options used for cb-website.

Protect the Main Branch

GitHub supports branch protection rules and repository rulesets. Prefer rulesets where available because they provide clearer targeting and enforcement status.

  1. Open repository → Settings.
  2. Open RulesRulesets.
  3. Create a new branch ruleset named Protect main.
  4. Set the target branch to the default branch or pattern main.
  5. Set enforcement to Active after testing.
  6. Enable pull request requirements.
  7. Require at least one approving review when more than one engineer is available.
  8. Require conversation resolution.
  9. Require status checks when CI exists.
  10. Block force pushes and branch deletion.
  11. Restrict bypass permissions to the smallest owner group.

Small-Team Transitional Policy

When Cloudberrie has only one active engineer, enable protections that do not make work impossible: block force pushes and deletion, require PRs where practical, and document owner bypasses. Tighten review requirements as soon as another reviewer is available.

Security Features

  • Dependency graph
  • Dependabot alerts
  • Dependabot security updates
  • Private vulnerability reporting when appropriate
  • Secret scanning and push protection when available for the repository and plan
  • Code scanning where supported and useful

Feature availability can vary by repository visibility and GitHub plan. Enable every appropriate capability available in repository Settings → Code security / Advanced Security.

Secrets Management

  • Use repository or environment secrets for GitHub Actions.
  • Prefer short-lived credentials and provider-native integrations.
  • Do not put secrets in workflow YAML, source code, issues, PR descriptions, or logs.
  • Separate production and preview credentials.
  • Rotate credentials after staff changes or suspected exposure.