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.
Top comments (0)