Git Security: Signed Commits, Secret Scanning, and Branch Protection
Part of the Cybersecurity Skills Guide — This article is one deep-dive in our complete guide series.
By HADESS Team | February 28, 2026 | Updated: February 28, 2026 | 5 min read
Git tracks every change to your codebase, but it does not verify who made those changes or what is in them by default. Without additional controls, anyone can commit as anyone, secrets get pushed to public repositories, and unreviewed code reaches production branches.
Signed Commits
Git commits include an author name and email, but these are self-reported. Anyone can set git config user.email "ceo@company.com" and commit as your CEO. Commit signing adds cryptographic verification.
GPG signing:
“bash
Generate a GPG key
gpg --full-generate-key
Configure Git to sign commits
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true
`
SSH signing (Git 2.34+):
`bash`
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
SSH signing is simpler — you probably already have SSH keys. No GPG keyring management required.
On GitHub and GitLab, upload your public key so signed commits show a "Verified" badge. Configure your organization to require signed commits on protected branches. Unsigned commits should not reach your main branch.
Pre-Commit Hooks
Pre-commit hooks run checks before a commit is created. They catch problems at the earliest possible point — on the developer's machine, before code enters the repository.
Use the pre-commit framework to standardize hooks across your team:
`yaml
.pre-commit-config.yaml
repos:
- repo: https://github.com/pre-commit/pre-commit-hooks
rev: v4.5.0
hooks:
- id: detect-private-key
- id: check-added-large-files
args: ['--maxkb=500']
- id: no-commit-to-branch
args: ['--branch', 'main']
- repo: https://github.com/gitleaks/gitleaks rev: v8.18.0 hooks: - id: gitleaks `
Key hooks for security:
- Secret detection (gitleaks, detect-secrets) catches API keys, passwords, and tokens before commit
- Private key detection prevents accidental commits of SSH and TLS private keys
- Large file checks prevent accidental commits of database dumps or binary blobs
- Branch protection prevents direct commits to main
Pre-commit hooks are client-side — developers can bypass them with –no-verify. That is why you also need server-side controls.
Secret Scanning
Server-side secret scanning catches what pre-commit hooks miss:
- GitHub secret scanning detects known credential patterns and alerts repository administrators. Push protection blocks pushes containing detected secrets.
- GitLab secret detection runs as a CI pipeline stage and reports findings in merge requests.
- Gitleaks can run in CI/CD pipelines across any Git hosting provider.
When a secret is detected in Git history, rotating it is not optional. The secret is compromised — it exists in the repository history even after you remove it from the current branch. Rotate first, then clean history with git filter-repo or BFG Repo-Cleaner if needed.
`bash
Scan full repository history
gitleaks detect --source . --verbose
Scan only new commits in CI
gitleaks detect --source . --log-opts="origin/main..HEAD"
`
Branch Protection
Branch protection rules on your main and release branches prevent direct pushes and enforce quality gates:
- Require pull request reviews — at least one approval, ideally two for production branches
- Require status checks — CI must pass before merge. Include security scans in required checks.
- Require signed commits — only cryptographically verified commits merge
- Restrict who can push — limit to repository maintainers or a deploy bot
- Require linear history — squash or rebase merges make history auditable
- Disable force push — prevents history rewriting on protected branches
On GitHub, use Rulesets (replacement for branch protection rules) for more granular control across repositories. On GitLab, use protected branches with push and merge access restrictions.
.gitignore as a Security Control
A well-maintained .gitignore prevents accidental commits of sensitive files:
`gitignore
Credentials and secrets
.env
.env.*
*.pem
*.key
credentials.json
service-account.json
State files
*.tfstate
*.tfstate.backup
“
Related Career Paths
Git security fundamentals apply to every DevSecOps role. These skills are baseline expectations, not differentiators. Check the skills page to ensure you have the complete foundation.
Next Steps
- Assess your source control security practices and find gaps
- Map out your DevSecOps certification path
- Open a workspace to practice Git security configurations
- Explore DevSecOps job opportunities that match your skill level
- Use the resume builder to highlight your Git security expertise
Related Guides in This Series
- Ansible Security: Vault Encryption, Access Control, and Playbook Hardening — HADESS | 2026
- ArgoCD Security: RBAC, SSO, and GitOps Access Control — HADESS | 2026
- CI/CD Security: Pipeline Hardening and Supply Chain Integrity — HADESS | 2026
Take the Next Step
Browse 80+ skills on HADESS. Go to the browse 80+ skills on hadess on HADESS.
See your certification roadmap. Check out the see your certification roadmap.
Get started free — Create your HADESS account and access all career tools.
Frequently Asked Questions
How long does it take to learn this skill?
Most practitioners build working proficiency in 4-8 weeks of dedicated study with hands-on practice. Mastery takes longer and comes primarily through on-the-job experience.
Do I need certifications for this skill?
Certifications validate your knowledge to employers but are not strictly required. Hands-on experience and portfolio projects often carry more weight in technical interviews. Check the certification roadmap for relevant options.
What career paths use this skill?
Explore the career path explorer to see which roles require this skill and how it fits into different cybersecurity specializations.
—
HADESS Team consists of cybersecurity practitioners, hiring managers, and career strategists who have collectively spent 50+ years in the field.
