The change author and approver — the human links in the audit chain

A change has two human links in the audit chain: the author who wrote it and the approver who decided it should be merged. The two are distinct identities, recorded separately, and conflating them is the most common audit failure in infrastructure repositories. The discipline that keeps them distinct is the four-eyes principle: no change is merged by the person who wrote it. The mechanism that enforces the discipline is CODEOWNERS plus required reviewers plus branch protection.

The two roles, distinct

The author is the engineer who wrote the change. The author is recorded in the commit author field, the pull request author field, and the merge commit author field. The author is the person the auditor calls to ask “why this approach?”.

The approver is the engineer who decided the change should be merged. The approver is recorded in the pull request review record, the CODEOWNERS mapping, the branch protection rule, and (for regulated environments) the change-advisory-board ticket. The approver is the person the auditor calls to ask “why did you accept this?”.

The author writes. The approver decides. The two are distinct identities; the four-eyes principle is the rule that says an engineer cannot be both for the same change.

flowchart LR
    A["Author: writes the change"] --> P["Pull request"]
    P --> C["CODEOWNERS: maps path to owner"]
    C --> R["Reviewer: required approval"]
    R --> M["Merge: approval + status checks"]
    M --> D["Deployed: audit-grade record"]

The four-eyes principle

The four-eyes principle (also known as dual control or separation of duties) requires that two distinct individuals authorise a change before it is applied. The principle has two practical implications:

• The author cannot be the only approver. The merge button is disabled until a second pair of eyes has approved.
• The approver cannot be the only author. A reviewer who rewrites the change unilaterally and merges it without an author has produced a change with no author identity, which is a different audit failure.

Branch protection enforces the principle at the repository level. The merge button is disabled until:

• A required number of approving reviews is recorded.
• The approving reviews come from CODEOWNERS-mapped owners for the changed paths.
• The required status checks have passed.

REPO=acme/infrastructure
gh api \
  -X PUT \
  -H "Accept: application/vnd.github+json" \
  "/repos/$REPO/branches/main/protection" \
  --input branch-protection.json
# branch-protection.json enforces:
# - required_approving_review_count: 2
# - require_code_owner_reviews: true
# - required_status_checks: ["ci/lint", "ci/plan", "ci/scan"]

CODEOWNERS as the machine-readable mapping

CODEOWNERS is a file in the repository that maps paths to GitHub usernames or teams. The mapping is consulted by branch protection: a pull request that changes a path under infra/payments/* requires approval from the owners of that path.

# CODEOWNERS
/infra/payments/    @payments-platform-team
/infra/iam/         @security-team
/terraform/state/   @platform-leads
/.github/workflows/ @platform-leads @security-team

The mapping is the source of truth for “who can approve what”. A reviewer who is not in the CODEOWNERS list for a changed path can leave a comment but cannot provide the required approval. The merge button is disabled until a CODEOWNERS-listed reviewer has clicked Approve.

Technical approval versus change-board approval

A pull request review records technical approval: “the code is correct, the tests pass, the rollout is safe”. A change-advisory-board (CAB) ticket records business approval: “the change is scheduled, the stakeholders are informed, the risk is accepted”. A regulated change needs both.

The two approvals live in different systems: the pull request in GitHub or GitLab; the CAB ticket in Jira, ServiceNow, or a custom change-management tool. The change record links them with a ticket reference in the pull request body and a pull request link in the CAB ticket.

flowchart TB
    PR["Pull request: technical approval"] --> CR["Change record"]
    CAB["CAB ticket: business approval"] --> CR
    CR --> AUDIT["Audit: both approvals recorded"]

A change that has only technical approval has not been authorised by the business. A change that has only business approval has not been technically reviewed. A change with both is auditable across both axes.

Production discipline

1. The author and the approver are distinct. No engineer can be both for the same change. Branch protection enforces the rule; the auditor verifies.
2. CODEOWNERS is required for the merge button. A pull request without a CODEOWNERS-listed approver does not merge.
3. Technical approval is in the pull request; business approval is in the CAB ticket. Both must be recorded; both must be linked.

Cross-course references

• This course, Part LXIV (Auditability) - the five-question audit the author and approver answer.
• This course, Part XLIV (RBAC) - branch protection as the RBAC mechanism for human approvals.
• Linux for Production Sysadmins - Parts XXXIII (ChangeMgmt) cover the change-board process from the operating-system side, the analogue of CAB approval.

Quiz