DEVOPSdigest

Ask any developer and most will agree that Git it is the most popular software version control (SVC) standard today. Just because it's the most popular, however, doesn't mean it's the most secure. Regardless of whether you're using GitLab, GitHub, or a locally hosted Git server each has its own security issues that can sneak up on you and start a wave of additional issues.

Keep in mind, Git is not built for security but for collaboration. It can be made secure through certain tools and best practices, but still requires caution. Self-hosting a Git server, for example, is a security issue, particularly if you lack experience in Git server configuration as there are simply too many opportunities to exploit a misconfigured or unpatched Git server by experienced hackers.

Even hosted Git services such as GitHub or GitLab offer limited security. Such services offer an easy-to-use interface with enhanced access controls. But convenience and ease-of-use can prove to be a hindrance and lead to complacency and human error. This especially true when code-commits are not properly screened by secret detection tools.

Not surprisingly, with so many companies relying on Git for code management, it has become a popular attack vector for hackers. History is littered with cautionary tales of poorly configured or insecure Git management.

What can you do to avoid repeating the Git security mistakes of others? Here are a few common Git security pitfalls and pointers to help you navigate them.

Hardcoded Sensitive Data

Developers understand the convenience of storing passwords, tokens, and authentication keys directly in the code where such credentials are used. It's difficult for them, however, to resist the temptation of saving them where they are easily accessible when issue pop up.

Hardcoded secrets are a terrible security practice that unfortunately plagues software development. Like most people, developers can be forgetful on occasion and share code that contains stored passwords. In such cases, long-forgotten secrets, still embedded in code, can leak and even get indexed on online search engines. Yes, it happens.

There is simply no good technical reason to use hardcoded authentication credentials. To avoid this, train developers to use secure coding practices. Simultaneously, ensure that security tools are integrated into the development process for the start that can monitor the development workflow.

Unsigned Commits

When committing code to a Git repository, you should be able to see the author who's committing the code. Unless the author used a GPG key to cryptographically sign the commit, it's impossible to trust what's there.
It may sound trifling for a developer with access to a repository to assign a code-commit they themselves performed to another developer on the project. But a disgruntled employee can do this to inject a backdoor into the code, thereby covering their tracks by assigning ownership of the code to another developer.

A similar exploit would be to assign a code commit to a manager of the project's development, hoping the new code would be integrated with less oversight.

When code commits are signed, a "verified" icon appears next to the commit log entry. This ensures every member of the project knows the code was committed by the true code author and was not tampered with in any way.

Unsecured Pipeline Configurations

A CD/CI pipeline that is not secure can lead to data leaks or secrets being put at risk by pull requests coming from forks of your repository, CD/CI VMs left operating unattended, or other processes.

Securing the pipeline requires holding secrets with very limited exposure. Beyond training developers to use proper security practices when storing secrets, it's a recommended best-practice to integrate tools or online services into the CD/CI pipeline to provide an extra layer of protection. This step is even more important when protecting extremely sensitive materials such as code-signing certificates.

Unpatched Software

Generally speaking, Git is used in combination with other applications to automate, secure, and provide analytics throughout the CD/CI pipeline. Hackers have evolved today are not limited to attacking a target directly. Instead, they have found it easier and worth more to execute a supply-chain attack on tools or services to upend multiple entities that use them.

To minimize exposure to supply chain attacks, it's critical to apply tool-chain software security patches as soon as they are released. And while you're at it, limit online service access to the minimum required for reliable operations and — it goes without saying but we'll say it anyway - perform regular backups.

Inaccurate Access Permissions

Poorly configured permissions can provide an access point to every Git repository on the server. In the case of one well-known automaker, the server automatically granted full access to anyone who just signed up for a developer account. More inconspicuous access permissions configuration errors may result in persons accessing data they are not authorized to in other cases.

When establishing access permissions, it's important to define access roles on a per-repository basis to ensure only developers with exact access credentials are allowed to interact with the repository.

Git security is not to be taken lightly. Losing source code or compromising intellectual data can prove disastrous and effectively level an organization. By applying some of the lessons here — along with the enforcement of security practices and policies — you can better assure that code will be more secure using Git in a production environment.