Git Security, Signed Commits, Branch Protection and Repository Trust — DedSec Project
Git Security, Signed Commits, Branch Protection and Repository Trust Source control is part of the software trust chain. Study identity, review policy, signed objects, protected branches…
Source control is part of the software trust chain. Study identity, review policy, signed objects, protected branches, secrets exposure, dependency changes and repository recovery.
Learning objectives
By the end of this module you should be able to:
- Explain Git object integrity and hashes and identify its most important trust boundary, state transition, and evidence source.
- Explain commit/tag signatures and identify its most important trust boundary, state transition, and evidence source.
- Explain branch protection and required reviews and identify its most important trust boundary, state transition, and evidence source.
- Explain CODEOWNERS-style approval concepts and identify its most important trust boundary, state transition, and evidence source.
- Explain force pushes and history rewriting and identify its most important trust boundary, state transition, and evidence source.
- Explain secret exposure and rotation and identify its most important trust boundary, state transition, and evidence source.
Deep concepts
1. Git object integrity and hashes
Git addresses objects by cryptographic hashes and links commits into a content history, which helps detect accidental or unauthorized modification. Repository integrity still depends on trusted refs, hosting controls, signatures where required, and protecting the identities allowed to update branches/tags.
2. commit and tag signatures
Signed commits or tags can attest that a key approved specific history, but verification needs trusted key ownership and policy. Decide which events must be signed, how keys are enrolled/revoked, and what CI does when a signature is missing or invalid.
3. branch protection and reviews
Protected branches should require review, status checks, restricted force pushes, and controlled merge paths according to risk. Review policy must cover automation/bots and administrative bypasses; an emergency override should be visible and followed by retrospective review.
4. CODEOWNERS and approval paths
CODEOWNERS can route changes in sensitive directories to appropriate reviewers. Treat it as workflow assistance, not a complete authorization boundary: protect the ownership file itself and enforce required approvals through repository policy.
5. force pushes and history rewrite
History rewriting can remove or replace commits referenced by collaborators or releases. Restrict force pushes on protected refs, retain server/audit history, and distinguish cleanup of accidental secrets from an attempt to hide unauthorized changes.
6. secret exposure and rotation
Deleting a secret from the latest commit does not revoke copies already cloned, cached, logged, or indexed. Revoke/rotate the credential first, assess usage, then clean history only if policy requires it and coordinate the rewrite carefully.
7. submodules and dependency refs
Submodules and other pinned repository references extend trust to another repository/object. Pin immutable reviewed revisions, validate ownership/provenance, and prevent an untrusted dependency location from changing what privileged build automation fetches.
8. backup, mirroring and recovery
Repository resilience includes remote mirrors, protected release artifacts, issue/metadata backups where needed, and tested restoration. Recovery should preserve evidence of unauthorized ref changes while allowing teams to re-establish known-good branches and tags.
Authorized lab sequence
Lab 1 — Create a throwaway local repository, sign a test tag if you have a test key, and document verification outcomes.
Lab 2 — Design branch-protection rules for a critical library versus a personal experiment.
Lab 3 — Simulate accidental placement of a fake secret string and practice safe history cleanup plus “rotate the real secret” reasoning.
Knowledge checks
Answer these without looking at the notes:
Next modules
Recommended related modules: 022, 029, 040, 084, 097, 098, 109. From the main menu, choose Search lessons to find related sections across the full guide.