9.5.2. Code Repository and SCM Security
💡 First Principle: The code repository is the single source of truth for what runs in production. If an attacker can modify the repository — through a compromised developer account, a malicious pull request, or direct push access — they control what gets built, tested, and deployed. Repository security is therefore foundational to the entire software supply chain: every other pipeline security control is downstream of the repository and assumes the source code is trustworthy.
Repository access control:
| Control | Purpose | Implementation |
|---|---|---|
| Branch protection | Prevent direct pushes to main/production branches | Require pull requests with approvals; no force-push; no deletion |
| Required reviewers | Ensure human review before merge | Minimum 1–2 approvals; CODEOWNERS for sensitive paths |
| Signed commits | Verify author identity | GPG or SSH key signing; reject unsigned commits on protected branches |
| Role-based access | Limit who can modify what | Read/write/admin roles; minimize admin count; review periodically |
| SSO and MFA | Protect developer accounts | Enforce organizational SSO; require MFA for all repository access |
Code review as a security control:
Code review serves dual purposes: quality assurance and security verification. Security-focused code review looks for:
- Authorization checks — Is access control enforced at every endpoint? Are object-level checks present?
- Input validation — Is all external input validated server-side? Are parameterized queries used consistently?
- Secret management — Are any credentials, API keys, or tokens hardcoded? Are secrets fetched from a vault?
- Error handling — Do error responses leak internal information (stack traces, database schemas, file paths)?
- Logging — Are security-relevant events logged? Are logs protected from tampering? Is sensitive data excluded from logs?
Repository security monitoring:
- Audit logs — Track who accessed the repository, what branches were modified, which PRs were merged and by whom. Integrate with SIEM for anomaly detection.
- Secret scanning — Automated tools (GitHub secret scanning, GitLeaks, TruffleHog) scan commits for patterns matching API keys, passwords, certificates, and private keys. Must scan all branches and full history, not just the current HEAD.
- Dependency update automation — Tools like Dependabot and Renovate automatically create PRs when dependency updates are available, reducing the window of vulnerability exposure.
Source code management (SCM) infrastructure:
| Decision | Considerations |
|---|---|
| Cloud-hosted vs. self-hosted | Cloud (GitHub, GitLab.com): vendor manages infrastructure and patching. Self-hosted (GitLab CE, Gitea): you control data residency and customization but own the operational security burden |
| Monorepo vs. polyrepo | Monorepo: unified access control, easier dependency management. Polyrepo: finer-grained access control per service, but more complex dependency tracking |
| Forking model | Contributors fork and submit PRs from their fork. Limits write access to the main repository; standard for open-source and large organizations |
⚠️ Exam Trap: A code review process that only checks functionality but not security provides no security assurance. The exam tests whether you understand that code review is a security control that requires reviewers trained in secure coding practices — not just feature verification.
Reflection Question: A developer's GitHub account is compromised via a phishing attack. The attacker uses the account to push a malicious commit directly to the main branch of a production application repository, bypassing the normal PR review process. The commit modifies the authentication module to create a backdoor. Describe the repository security controls that should have prevented this attack at each stage (account compromise, direct push, unreviewed code reaching production), and what monitoring would have detected the compromise after the fact.
