At this point, we have a ton of experience with the Git stuff we use. And Git locking is well documented. Okay, it’s documented; we can say that, at least. Interestingly, a lot of the “how to secure Git” information is actually “how to keep critical information out of Git”, and therein lies the problem. “Critical information” always includes warnings to “do not put configuration information into Git”. Never.” And that’s been the default way to lock down Git for most of its existence.
Next is GitOps. What is its purpose, in a nutshell? To put this critical information into Git. So we waltzed; only a fraction of us actually locked down our implementation because we ensure that the data in Git, while valuable, is not filled with bits of information that would be useful in compromising systems. But now it will. In fact, in GitOps almost everything is part of this information useful to attackers.
All of this means it’s time to get serious Cottage Security. Not contentsbut real Git Security. I’m not going to go crazy with links to lockup docs here – it’s a very different process to lock down a local Git repository versus a remote repository and it’s radically different when you lock down a service like GitHub or GitLab (in fact, some of the work is done for you with a SaaS provider) … so you’ll have to research it yourself, depending on your Git implementation. But the are documents there that walk you through it; you’ll just have to make sure you find the ones that say “How to lock down Git repositories” and not “How to keep privileged data out of Git repositories”.
But whatever you do, stop putting it off. Now, if a neer-do-well gets into your repository, it won’t just be the source code for various applications that gets leaked – and that’s certainly bad enough, even if your organization isn’t a software organization. – it will be the information infrastructure that can be used and abused. So make sure the information is protected in every possible way. Point security to Git and tell them, “We know you’re incredibly busy, but this is the most important thing to protect if we’re going to implement GitOps.” Because it literally is. If database configuration, network configurations, and possibly even connection information is to be stored in Git, it is imperative to lock it down (local and remote copies). You wouldn’t leave this information in plain text on a centralized data store and rely on existing protections. So don’t do the equivalent with Git.
If GitOps isn’t in your immediate future, it’s still your source code full of vulnerability advertisements, so at least have your security team review your Git installation/policies/configuration. Even as a developer, I’m less concerned with source code repositories than configuration repositories. There are several reasons for this, but the main one is all of you. Most organizations just don’t seem to care about the security of the source code repository, but that changes when operations are queried on the list of holes in the firewall moved to Git and configurable from Git (for one example).
So keep kicking! You all create, distribute, and secure a ton of software, and the complexity of our environments hasn’t diminished after the wave of remote work. Yet you are still rocking it. May you have enough staff to do the job and candidates looking to work with you rather than competitors. And keep showing the world that the software is manageable. But secure your Git.