As software projects grow, managing source code becomes increasingly difficult.
Organizations need a way to:
- Track changes
- Collaborate with other developers
- Review modifications
- Restore previous versions
- Manage releases
Version control systems were created to solve these problems.
What Is Version Control?
Version control is the process of tracking changes to files over time.
Instead of manually creating files such as:
project-final.zip
project-final-v2.zip
project-final-v2-fixed.zip
project-final-v2-fixed-final.zip
a version control system maintains a history of changes automatically.
This allows users to review who changed what, when it was changed, and why.
Git
Git is the most widely used version control system today.
It is used by:
- Software companies
- Security teams
- Infrastructure teams
- Cloud engineers
- DevOps teams
Most modern software development workflows involve Git.
Repositories
A Git project is stored inside a repository.
A repository contains:
- Source code
- Configuration files
- Documentation
- Change history
Repositories may be:
- Local
- Shared internally
- Hosted on external platforms
Commits
A commit represents a snapshot of changes.
Example:
Added login functionality
Fixed authentication bug
Updated database configuration
Each commit becomes part of the repository history.
Branches
Branches allow developers to work on changes without affecting the main codebase.
Example:
main
├── feature-login
├── feature-api
└── bugfix-auth
Once changes are complete, they are typically merged back into the main branch.
Why Organizations Use Git
Git provides several important benefits:
- Change tracking
- Collaboration
- Backup of source code
- Code review workflows
- Release management
Without version control, managing large software projects becomes extremely difficult.
Metadata
Git stores information about repository history.
This information may include:
- Authors
- Commit messages
- File history
- Previous versions
In some situations, historical commits may reveal information that no longer exists in the current version of the application.
Supply Chain Attacks
Source code repositories are part of the software supply chain.
If an attacker compromises a repository, build pipeline, dependency, or developer account, they may be able to pass malicious artifacts downstream, which eventually reach users or production systems.
Supply chain attacks may involve:
- Modifying source code
- Stealing signing keys or deployment secrets
- Poisoning dependencies
- Tampering with build pipelines
- Compromising developer accounts
- Injecting malicious code into legitimate software
This is especially dangerous because the malicious code may be delivered through trusted update or deployment mechanisms.
As of the mid-2020s, supply chain attacks have become one of the most significant concerns in cybersecurity. Unlike traditional attacks which target a single organization, a successful supply chain compromise can potentially impact hundreds or even thousands of downstream customers simultaneously.
These attacks also create a difficult operational dilemma. Organizations must regularly update software to receive security fixes and vulnerability patches. However, if a trusted vendor, dependency, or update mechanism becomes compromised, the update process itself can become an attack vector.
In practice, organizations often find themselves "between a hammer and a hard place":
- Failing to update software and remaining vulnerable to known security issues
- Updating software and trusting that the update chain has not been compromised
For this reason, modern organizations increasingly focus on software provenance, code signing, dependency management, build integrity, and supply chain security controls.
Git Hooks
Git supports a feature known as hooks.
Hooks are scripts that can automatically execute when certain repository-related events occur, such as:
- Creating a commit
- Receiving changes
- Merging branches
- Checking out code
Organizations often use hooks to:
- Enforce coding standards
- Run automated tests
- Validate commits
- Trigger build processes
Because hooks are capable of executing code, they should be treated with caution.
In some environments, a compromised repository may not only expose sensitive information but may also introduce opportunities for code execution through automated workflows, build systems, or improperly managed hook configurations.
More broadly, modern software development frequently involves a large amount of automation. Source code changes may automatically trigger:
- Tests
- Builds
- Deployments
- Package publication
- Infrastructure changes
As a result, a compromise of a repository can sometimes have consequences that extend far beyond the source code itself.