top of page
Search

Part 2 : Git Commit Hooks, Pre-Commit Checks & Branch Protections (Security in Action)

  • 1 day ago
  • 3 min read
ree


When we talk about security in DevSecOps, a lot of risks start right in the repo before code ever hits CI/CD pipelines. This is where Git commit hooks, pre-commit frameworks, and branch protections come into play.


------------------------------------------------------------------------------------------------------

Git Hooks – Security’s First Gate

Think of Git hooks like little security guards that live inside your Git repository. They’re scripts that run when certain Git events happen (like committing, pushing, or merging code).


  • Local hooks (on developer’s machine):

    • pre-commit: Runs before the commit is made. Perfect spot to check for secrets or run linters.

    • commit-msg: Ensures the commit message follows your org’s rules (e.g., must have a Jira ID).

    • post-commit: Runs right after a commit. Useful for notifications/logging.


  • Server-side hooks (on remote repo):

    • pre-receive: Runs before changes are accepted on the remote repo. Stops bad commits at the gate.

    • update / post-receive: Good for enforcing team policies or kicking off workflows.


Why it matters: Hooks let you catch issues early (like hardcoded AWS keys, unsafe configs, bad commit messages) before they ever hit CI/CD.

------------------------------------------------------------------------------------------------------

Pre-Commit Frameworks

Yes, you could write your own Git hook scripts, but that’s messy. Instead, teams often use frameworks that manage hooks across multiple languages and repos.


Two popular ones:

  • Yelp’s Pre-Commit:

    • You create a .pre-commit-config.yaml in your repo.

    • Add rules (e.g., check for YAML syntax errors, remove trailing spaces, scan for secrets).

    • Every developer who clones the repo gets the same hooks.


  • Overcommit:

    • Another Git hook manager with built-in checks.

    • Widely used in security-focused teams.


Example (.pre-commit-config.yaml):
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v2.0.1
    hooks:
      - id: check-yaml
      - id: end-of-file-fixer
      - id: trailing-whitespace

  - repo: https://github.com/psf/black
    rev: 24.3.0
    hooks:
      - id: black

With this:

  • Every commit will check if your YAML is valid.

  • Remove trailing spaces automatically.

  • Format Python code using Black.


Run pre-commit install once, and boom — your repo now has built-in security and quality checks before anyone can commit bad code.

------------------------------------------------------------------------------------------------------

Peer Code Reviews

Automated checks are great, but nothing beats human eyes. That’s where code reviews come in.

Big companies never let code go straight into production without review. Why?


  1. Transparency – At least one other person knows what’s being changed.

  2. Accountability – Developers are more careful if they know someone else will review their work.

  3. Security – Reviewers can spot “code smells” like:

    • Hardcoded passwords/API keys

    • Custom (and unsafe) cryptography

    • Suspicious or obfuscated logic

    • Incorrect handling of sensitive data


Pro tip:

  • Create a security checklist for reviewers (data validation, error handling, proper logging, etc.).

  • Make high-risk code (auth, payments, encryption, APIs) require senior or security-team review.

  • Randomly assign reviewers to reduce risks of collusion.


------------------------------------------------------------------------------------------------------

Branch Protections (Your Repo’s Guardrails)

Even with hooks and reviews, you don’t want people pushing code directly into main or develop. This is where branch protections come in.

All major platforms (GitHub, GitLab, Azure DevOps, Bitbucket) support this.


What branch protections do:

  • ❌ Prevent deleting critical branches (like main).

  • ❌ Prevent direct pushes to release branches.

  • ✅ Require pull/merge requests for changes.

  • ✅ Force code reviews/approvals before merging.

  • ✅ Allow you to define who can approve changes (e.g., security must approve auth changes).


Example: On GitHub, you can require that:

  • At least 2 reviewers approve before merge.

  • All checks (tests, scans, pre-commit) must pass.

  • No one can merge unless those conditions are met.

This ensures security isn’t optional — it’s baked into the workflow.


------------------------------------------------------------------------------------------------------

Putting It All Together

Even if one layer misses something, the others catch it.


✅ Hooks = automatic checks

✅ Pre-commit frameworks = easy setup

✅ Peer reviews = human judgment

✅ Branch protections = safety nets


Together, they make your repo a security-first environment.


 
 
 
bottom of page