Skip to content

PATTERN Cited by 1 source

Org-wide GitHub rulesets

Problem: Per-repository branch protection and workflow permissions require correct configuration everywhere; any repo missing the required setting is an attack surface. When a workflow compromise gives an attacker write access to a repo, what they can actually do — push to main, move a tag, create a PR, merge a PR — depends on whether protection was in place.

Pattern: Enforce baseline protections at the organization level via GitHub rulesets. Individual repo owners cannot disable org-level rulesets.

Minimum-viable org rulesets (per Datadog 2026-03-09 post)

  1. Require PRs for default branches — no direct pushes to main, even for repo admins.
  2. Restrict write access to tags — attackers can't create, move, or delete tags to forge release identities.
  3. Prevent GitHub Actions from creating or approving PRs — even if a workflow has pull-requests: write, it cannot self-approve changes or open new PRs.

This is the defence-in-depth floor. Any additional workflow-level compromise (script injection, prompt injection, supply-chain attack) is contained because the attacker cannot reach the org-ruleset-protected operations.

Rollout discipline

Datadog's post + GitHub's secure-use guidance both recommend starting in evaluate mode (rules log but don't enforce) to surface which repos/workflows would be affected, then shifting to enforcement mode once violations are cleaned up.

Production containment datum

On 2026-02-27, hackerbot-claw's attack on DataDog/datadog-iac-scanner achieved code execution in the CI pipeline through script injection — the workflow had pull-requests: write and contents: write permissions. If Datadog's org didn't have the three org-rulesets above, this would have been a full-repo compromise (push to main, move release tags, merge malicious PRs). With the rulesets, the attacker could only push a harmless commit to a throwaway branch 🤖🦞.

Quoted framing from Datadog: "We confirmed that the attacker could not override code on the main branch or create, update, or delete tags because Datadog uses organization-wide GitHub rulesets and settings that require PRs for default branches, restrict write access to tags, and prevent GitHub actions from creating or approving PRs."

This is the canonical wiki instance of concepts/defense-in-depth working as designed at the SCM layer.

What else to add

Org-wide rulesets are the hardening floor, not the ceiling. Datadog also enumerates:

  • Mandatory commit signing for humans and for bots.
  • Mandatory PR approval.
  • Defaulting to lower-privilege GITHUB_TOKEN permissions — apply permissions: read-all at the repo level, opt-in to higher privileges per-workflow.
  • Identifying and removing unused GitHub Actions secrets at scale — every unused secret is an avoidable attack surface.
  • Environments + environment-scoped secrets — make workflow secrets available only to specific environments protected by branch rules, so contributors with write access can't exfiltrate them by modifying a workflow.

Seen in

Last updated · 200 distilled / 1,178 read