Repository Security Best Practices

A single leaked API key can cost a company millions. A vulnerable dependency can expose user data. An unprotected branch can let malicious code reach production. Repository security is not optional — it is a fundamental responsibility that every developer must understand.

Security in Git repositories operates at multiple layers: access control (who can do what), code integrity (ensuring code has not been tampered with), dependency safety (third-party code you rely on), and secret management (keeping credentials out of version control). Let us walk through each layer with practical configurations.

The Security Checklist

Before we dive deep, here is the complete checklist every repository should follow:

Dependency Security with Dependabot

Third-party dependencies are one of the largest attack surfaces. A single compromised package in your supply chain can affect your entire application:

Dependabot does three things: alerts you to known vulnerabilities, suggests version updates, and can automatically create PRs with the fix.

Security Policy (SECURITY.md)

Every repository needs a clear vulnerability disclosure policy:

Securing GitHub Actions

GitHub Actions workflows are a common attack vector. Compromised Actions can steal secrets, modify code, or escalate privileges:

Why pin to SHAs? A tag like v4 can be moved to point to different code. If an Action maintainer's account is compromised, attackers could push malicious code to an existing tag. SHA references are immutable.

Never use pull_request_target with untrusted code execution:

Preventing Credential Leaks

Pre-commit Hook for Secret Detection

Access Control Best Practices

CODEOWNERS for Security-Sensitive Paths

Common Mistakes

Mistake 1: Relying solely on .gitignore for secret protection. If a file was ever committed before being added to .gitignore, the secret remains in history.

Mistake 2: Using classic PATs with broad permissions. Always prefer fine-grained tokens scoped to specific repositories and minimal permissions.

Mistake 3: Not pinning Action versions. Using actions/checkout@v4 instead of the full SHA means a supply chain attack could inject code through tag manipulation.

Mistake 4: Granting admin access liberally. Every person with admin access can disable branch protection, delete the repository, or modify security settings.

Interview Questions

Q1: What are the most important security settings for a GitHub repository?

Branch protection (prevent unauthorized direct pushes), secret scanning with push protection (catch leaked credentials), Dependabot (monitor dependency vulnerabilities), CODEOWNERS (require expert review for sensitive paths), minimal token permissions, and enforced 2FA for all organization members.

Q2: How does Dependabot improve repository security?

Dependabot monitors your dependency tree against vulnerability databases, sends alerts when known CVEs affect your packages, and can automatically create pull requests to update vulnerable dependencies to patched versions. It also keeps non-security dependencies up to date.

Q3: Why should you pin GitHub Actions to commit SHAs instead of tags?

Tags are mutable — they can be moved to point to different code. If an Action author's account is compromised, an attacker could republish a malicious version under an existing tag. SHA references are immutable and always point to the exact same code.

Q4: What should you do when you accidentally commit a secret?

Immediately revoke the credential (assume it is compromised), remove it from the entire Git history using git filter-repo or BFG Repo-Cleaner, generate a replacement credential, investigate whether the exposed secret was used maliciously, and implement prevention measures.

Q5: How do you prevent secrets from being committed?

Layer multiple defenses: .gitignore for secret files, pre-commit hooks scanning for patterns, GitHub push protection blocking pushes with detected secrets, environment variables instead of hardcoded values, and team education about secure coding practices.