DevSecOps for Git: Security Starts at Commit Time

Most security incidents don’t start in production.
They start with a small mistake like:

git commit -m "temporary fix"

This article explains how to implement real DevSecOps practices for Git, step by step — in a way that developers, DevOps, and security teams all understand.

1. .gitignore — First Line of Defense

Purpose

Prevent sensitive files from ever being tracked by Git.

Common files that must be ignored

• .env, .env.*
• *.pem, *.key, id_rsa
• terraform.tfstate, .terraform/
• node_modules/, dist/

Why this matters

If a file is never tracked, it can never leak.

Important limitation

.gitignore does NOT protect secrets already committed.
If a secret entered Git history once, it is already exposed.

2. Native Git Pre-Commit Hooks

What this is

A pre-commit hook is a script that Git executes automatically before every commit.

Location:
.git/hooks/pre-commit

Why it matters

• Runs locally on the developer machine
• Instant feedback
• Zero CI/CD cost
• Stops mistakes before push

How Git decides

• Exit code 0 → Commit allowed
• Exit code ≠ 0 → Commit blocked

This is true shift-left security.

3. Native Pre-Commit Hook (Basic Example)

A simple pre-commit hook can block obvious secrets:

• It inspects staged changes
• Searches for risky patterns
• Blocks the commit if found

This approach is useful for learning, but it is not enough for real security.

4. Blocking Secret Commits with Gitleaks (Pre-Commit)

Why Gitleaks

Simple regex checks are weak.
Gitleaks adds:

• Entropy detection
• Cloud provider key patterns
• Token intelligence
• Custom rules

What happens in practice

• Hardcoded secrets → ❌ Commit blocked
• Placeholders or env references → ✅ Commit allowed

Result:
Secrets never leave the developer laptop.

This is prevention, not detection.

5. Repository & History Scanning with Gitleaks

Why this is required

Pre-commit hooks protect future commits.
They do nothing for past mistakes.

Repository scanning finds:

• Secrets already committed
• Old credentials in history
• Legacy leaks

This step is critical for:

• Existing repositories
• Compliance
• Security cleanup

6. Gitleaks in CI/CD Pipelines

Role of CI/CD

CI/CD is enforcement, not prevention.

What CI does

• Scans code on push / pull request
• Fails the pipeline if secrets are detected
• Blocks merges automatically

This applies to:

• GitHub Actions
• GitLab CI
• Jenkins

If CI fails, the code does not move forward.

7. Branch Protection Rules

Without branch protection, CI security checks are useless.

Mandatory rules

• No direct push to main
• Pull requests required
• Required status checks
• No force push

Security without enforcement is just documentation.

8. RBAC — Least Privilege Access

Security is also who can do what.

Recommended model

• Developer → Create PR only
• Maintainer → Merge PRs
• Admin → Repository settings
• Auditor → Read-only access

Reducing access reduces blast radius.

9. Mandatory Reviews and CODEOWNERS

Why reviews matter

Secrets often leak during:

• Debugging
• Infrastructure changes
• CI/CD edits

CODEOWNERS

Automatically assigns reviewers for sensitive areas like:

• CI pipelines
• Infrastructure
• Security configs

This makes security reviews default, not optional.

10. Dependabot — Supply Chain Security

Dependencies become vulnerable over time.

Dependabot:

• Scans dependencies
• Creates update pull requests
• Reduces CVE exposure automatically

Supply chain security is part of DevSecOps.

Final Takeaway

DevSecOps for Git is not a single tool.

It is a layered system:

• Prevent → Pre-commit hooks
• Detect → Gitleaks scanning
• Enforce → CI/CD + branch protection
• Control → RBAC + mandatory reviews

If security starts after CI/CD, it’s already too late.

Security must start at git commit time.