# Repository Governance — CODEOWNERS, SECURITY.md, and Default Files > **Intro:** Source code management is not just a storage layer. It is one of the most practical security control surfaces in a modern engineering program. The public DevSecOps Playbook is especially useful here because it treats repository governance as a **baseline domain**: identity, access, reviews, ownership, disclosure contacts, and organization-wide defaults. > > **What this page includes** > > * the most useful SCM-oriented ideas imported from the DevSecOps Playbook; > * current interpretation for GitHub and GitLab style platforms; > * minimal examples for `CODEOWNERS`, `SECURITY.md`, and org-level defaults; > * what to treat as legacy wording vs current-safe implementation. ## Why repository governance matters so much A repository platform sits close to: * developer identity; * code review; * branch protection; * build triggers; * source provenance; * vulnerability disclosure intake; * reusable workflow and template distribution. That makes it one of the highest-leverage places to add security with relatively low friction. ## A practical baseline, adapted from the DevSecOps Playbook The imported ideas that are worth keeping are: * use a **centralized SCM platform**; * define **user and team roles** clearly; * require **MFA** for repository access; * require **pull or merge requests** for protected branches; * enforce **peer review** and ownership routing; * publish `CODEOWNERS` and `SECURITY.md`; * use an org-level shared defaults repository such as `.github` when appropriate. ## Current-safe interpretation ### Centralized SCM Still foundational. Teams need one system of record for: * code history; * branch and release policy; * review evidence; * automation triggers. ### User roles and least privilege Do not grant broad admin or workflow-edit rights just because someone is a senior engineer. Separate: * repo administration; * workflow / ruleset administration; * environment or deploy approval; * security administration. ### MFA This remains a **priority-1** style control. Prefer phishing-resistant MFA where possible. ### SSH vs HTTPS Older playbook wording suggests preferring SSH instead of HTTPS for repository access. Treat that as **historical guidance**, not a universal current rule. Modern secure patterns can include: * SSH with managed keys and rotation; * HTTPS with SSO, short-lived tokens, and strong MFA; * enterprise-managed identity controls. The real control goal is **trusted developer identity and manageable credentials**, not loyalty to one transport. ### GPG or commit signing Keep the spirit of the control: verify authorship and reduce spoofed commits. Interpret it today as: * verified commit signing where supported; * strong identity binding in the platform; * provenance-aware build paths for sensitive repos. ### Server-side git hooks Still useful in some self-managed setups, but many modern platforms get better day-to-day results from: * required status checks; * reusable workflows; * org rulesets; * protected branches; * merge request approval rules. ## Minimal repo governance baseline | Control | Why it matters | Practical platform expression | | -------------------- | ----------------------------------- | ------------------------------------------- | | centralized SCM | auditability and consistent process | GitHub / GitLab / Bitbucket org standard | | unique roles | least privilege | team-based repo roles and group inheritance | | MFA | prevent account takeover | org-enforced MFA / SSO / conditional access | | PR or MR required | stop direct unreviewed changes | branch protection or protected branches | | peer review | quality and security signal | required reviewers and review count | | CODEOWNERS | ownership routing | path-based review requirement | | SECURITY.md | disclosure intake | repo-root security contact and process | | shared defaults repo | reduce drift | `.github` or equivalent org templates | ## CODEOWNERS example ``` # Global fallback * @platform-security @core-maintainers # API surface /api/ @api-team @product-security # Infrastructure as code /terraform/ @platform-engineering @cloud-security # CI workflows /.github/workflows/ @platform-engineering @product-security ``` ### Why CODEOWNERS helps security * high-risk files route to the right people automatically; * infra, workflow, and auth-sensitive changes stop bypassing the people who understand them; * ownership survives team growth better than tribal memory. ## SECURITY.md example ```md # Security Policy ## Reporting a Vulnerability Please report security issues to security@example.com or through the private intake form at https://example.com/security. Do not open public issues for undisclosed vulnerabilities. ## What to include - affected component - steps to reproduce - impact assessment - logs, screenshots, or proof of concept when safe to share ## Response targets - acknowledgement within 3 business days - triage target within 10 business days ``` ### Why SECURITY.md matters It turns vulnerability disclosure from tribal knowledge into a visible repository control. It also reduces the chance that researchers disclose publicly because they could not find a safe contact path. ## Org-level `.github` defaults A shared `.github` repository is useful for: * default `SECURITY.md`; * `CONTRIBUTING.md`; * issue templates; * PR templates; * baseline CODEOWNERS fragments or policy links; * shared reusable workflows. That reduces drift across many repositories and gives smaller teams a safer starting point. ## Good review policy vs theater ### Good policy * all protected branches require PR or MR flow; * review requirements are path-aware for high-risk files; * workflow or deployment changes have tighter approver requirements; * repository admins are limited and reviewable; * emergency changes still produce an audit trail. ### Theater * two approvals from people who do not understand the files they approved; * a CODEOWNERS file that nobody maintains; * SECURITY.md that points to a dead mailbox; * signed commits with no meaningful identity governance. ## Repository governance checklist * Is MFA enforced for all contributors with write access? * Are direct pushes to protected branches blocked? * Do high-risk paths have real owners in `CODEOWNERS`? * Does `SECURITY.md` point to a live intake path? * Are repo and workflow admins limited? * Are org-level defaults reducing drift between repos? ## Cross-links * [GitHub Actions for Product Security](/devsecops-cicd-and-supply-chain/index-1/github-actions-for-product-security.md) * [Security Quality Gates and Release Blocking](/devsecops-cicd-and-supply-chain/index-1/security-quality-gates-and-release-blocking.md) * [Repository Secret Scanning](/application-security-and-secure-sdlc/index-1/repository-secret-scanning.md) * [DevSecOps Playbook Domains, Priority, Difficulty, and Adoption Roadmap](/devsecops-cicd-and-supply-chain/index/devsecops-playbook-domains-priority-difficulty-and-adoption-roadmap.md) \---*Incorporates selected governance ideas from the public DevSecOps Playbook by 6mile, updated for current repository-platform practice.* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.product-security.expert/devsecops-cicd-and-supply-chain/index-1/repository-governance-codeowners-security-md-and-default-files.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.