DedSec Project

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:

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

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.