[RFD]: Establish baseline org-wide governance (CODEOWNERS, SECURITY, Dependabot alerts, org settings)

[alexlovelltroy]

Decision Goal

Should OpenCHAMI adopt the following four baseline org-wide governance settings together, as a single coordinated rollout — (1) CODEOWNERS files on every active repo pointing at @openchami/tsc, (2) standardized SECURITY.md content plus Private Vulnerability Reporting (PVR) enabled per repo, (3) Dependabot alerts (security side only) enabled as the org default for new repos and enabled per-repo for the active set, (4) tightened org settings baseline (web commit signoff required, repo creation restricted, eventually 2FA mandated)?

Category

Process

Stakeholders / Affected Areas

The TSC; all org maintainers and contributors; security researchers (via the disclosure path); downstream packagers and consumers of OpenCHAMI components; org members enrolled (or not) in 2FA. The mechanical changes touch openchami/.github (for inherited SECURITY.md content), every active repo's settings page (per-repo PVR + Dependabot toggles, CODEOWNERS file), and the org-level Settings → Security/Permissions page.

Decision Needed By

No hard deadline, but earlier is better — each item independently reduces real governance debt. Aim for in-discussion at this TSC meeting; concrete rollout sequencing decided in the same meeting if scope is accepted.

Problem Statement

A May 2026 audit across 10 representative repos (5 management-layer, 5 core services) surfaced a cluster of governance gaps that share a common shape: each is a "set once, applies to many repos" baseline that's currently absent or only present in the openchami/.github repo (which doesn't inherit for several of them).

Findings, by artifact:

• CODEOWNERS: 1 of 10 repos has it (openchami/.github only). This is a real gap — unlike most community-health files, CODEOWNERS does not inherit from the org's .github repo. Each repo needs its own. Today, code review on most repos relies on whoever happens to be watching.
• SECURITY.md: inherits from openchami/.github (one source of truth, applies org-wide). Mechanically present. Two gaps: (a) the content quality of the inherited file has not been reviewed recently for this RFD; (b) GitHub Private Vulnerability Reporting must be enabled per-repo for the "Report a vulnerability" UI to appear — likely off on most repos.
• Dependabot alerts: org-level setting dependabot_alerts_enabled_for_new_repositories is null. Existing repos: per-repo toggles unverified but likely mostly off. Vulnerable transitive deps are surfaced only by manual review.
• Org settings: web_commit_signoff_required: false, members_can_create_repositories: true, two_factor_requirement_enabled: null. New repos start permissive; commit authorship audit trail not enforced; any member can create a repo (a contributor to the org's accumulation of stale repos visible elsewhere).

Each gap is small individually. The cost of not fixing them compounds across the 60-repo org surface, and the rollout for each is structurally similar — toggle org settings, optionally add a small file to each repo, possibly notify members. Bundling them avoids four separate TSC review rounds.

Existing related work, for context: the .github repo already hosts CONTRIBUTING.md, SECURITY.md, CODE_OF_CONDUCT.md, pull_request_template.md, .pre-commit-config.yaml, and .yamllint — i.e., it's already the canonical home for org-wide config. This RFD's CODEOWNERS template and (eventually) dependabot.yml template would land in the same repo.

Proposed Solution

Adopt all four together with the following sequencing (low-risk → higher-risk):

1. Dependabot alerts (org level). Enable dependabot_alerts_enabled_for_new_repositories: true and dependabot_security_updates_enabled_for_new_repositories: true org-wide. Sweep existing active repos to enable per-repo. Note: this is alerts only, paired with a separate Renovate RFD for active-update PRs.
2. SECURITY.md + PVR. Review and refresh openchami/.github/SECURITY.md for content quality (supported-version statement, disclosure timeline target, PVR contact). Enable GitHub PVR per-repo across the active set.
3. CODEOWNERS rollout. Add a baseline CODEOWNERS template at openchami/.github/CODEOWNERS (already present, but as a template for new repos to copy — does not inherit). For each active repo, add .github/CODEOWNERS with * @openchami/tsc as the starting pattern. This is intentionally blunt; evolve to subteam-based ownership later if PR volume justifies it.
4. Org settings tighten (sequenced last because most disruptive):
   • web_commit_signoff_required: true (low friction — one extra flag for contributors).
   • members_can_create_repositories: false or scoped to a defined subset.
   • two_factor_requirement_enabled: true — announce with notice; existing members without 2FA need a grace period or get removed.

Each step takes minutes to hours of GitHub-side work. The CODEOWNERS rollout is the largest mechanical task (one file per repo for ~28 active repos); a sweep can be scripted via gh repo edit and PRs.

Alternatives Considered

• Address each independently across four TSC meetings. Defensible, but creates inertia — easier to defer one and lose momentum on the rest. The audit found these as a cluster; the rollout naturally pairs them. Bundling preserves the cluster framing.
• Adopt with stricter CODEOWNERS pattern from day one (per-repo-class subteams instead of @openchami/tsc blanket). Higher fidelity but requires creating teams that don't exist yet. Start blunt; refine later when the contributor mix justifies the team-creation overhead.
• Bundle in REUSE compliance / LICENSE coverage as well. REUSE is a non-trivial body of work (per-file SPDX headers, .reuse/dep5, LICENSES/ directory adoption across all repos) — separate RFD warranted. Some repos already use the REUSE pattern (e.g., ochami, openchami.org); rollout is in flight.
• Status quo / do nothing. Real cost: CODEOWNERS gap means PRs go to whoever's watching; Dependabot gap means CVEs in transitive deps go unsurfaced; org-settings gap means new repos start permissive.

Other Considerations

• 2FA enforcement is the disruptive item. Members not currently enrolled may get removed when the toggle flips. Recommended: announce 4 weeks in advance via the community repo and MAINTAINERS.md channels.
• CODEOWNERS auto-pings the whole TSC. If the TSC is, say, 8 people, every PR creates 8 review requests. GitHub's auto-assignment feature (assign a subset of code owners per PR) partly mitigates. Worth considering as part of the rollout.
• Dependabot PR noise (alerts only). Alerts-only is much quieter than active dep-update PRs — it surfaces vulnerabilities only when one exists. Mitigated by design.
• Inherited vs per-repo files. Critical distinction: SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, issue templates, and PR template all inherit from .github. CODEOWNERS and dependabot.yml do not inherit — each repo needs its own. The proposal accounts for this.
• members_can_create_repositories: false restricts org members' ability to spin up a new repo without TSC approval. Reduces the abandoned-repo accumulation problem but adds a friction step for legitimate experiments. Consider scoping to a specific team (e.g., @openchami/maintainers) rather than full restriction.

Related Docs / PRs

• GitHub docs: Managing Dependabot alerts, About CODEOWNERS, Privately reporting a security vulnerability.
• openchami/.github — existing org-wide config home; landing zone for the CODEOWNERS template + dependabot.yml template that doesn't inherit.
• Related RFD (companion): Renovate adoption for active dep-update PRs. The two RFDs partner — Dependabot for alerts, Renovate for active updates.

---

Outcome (to be filled in after discussion)

• Accepted
• Accepted with modifications
• Rejected
• Needs follow-up RFC
• Deferred
• Split into sub-decisions
• Other: ________

Decision date:
Recorded by:

[milliams]

I'd like to suggest adding in Zizmor as a required workflow on every repository. I recently added it to Clifton and it helps avoid many of the GitHub Actions supply chain attacks by tightening up the configuration. I also added actionlint but that one's a bit more opinionated on style.

[alexlovelltroy]

Do you think actionlint and zizmor should both be included, or is one more generally applicable than the other?

[milliams]

Do you think actionlint and zizmor should both be included, or is one more generally applicable than the other?

I would say that they are complementary and would suggest including both. Zizmor specifically focuses on the security aspects (e.g. code injection, RCE, supply chain), whereas actionlint is a more traditional linter, as you might find in other languages (e.g. missing variable definitions, unused variables, idiomatic alternatives).

[alexlovelltroy]

Agreed at the meeting. I'll take the action.

[synackd]

One thing I might add is branch cleanup. I've noticed PR branches lingering and have been manually cleaning them, but it would nice to have that done automatically.