5

When the boss asks why Git is good, can I justify using security as one of the reasons?

Under Git, it's easy to track changes. Maliciously altered files can be revealed with a simple 'git diff' on the command line.

Even if attackers were able to do their own commits and rewrite the commit history, they likely would not be able to push to origin. But even if they could, other remote instances of the git repo would still retain the original history and get errors when they try to push.

5
  • 2
    As opposed to what? Are you coming from no version control system at all or do you already use a different one than Git?
    – Arminius
    Apr 6, 2017 at 2:07
  • Well, of course you can justify. Are you asking what would be your boss's response? I'm not sure anyone can answer that.
    – techraf
    Apr 6, 2017 at 2:12
  • 1
    The question is less about my boss and more about Git. I only hear Git talked about in terms of its (very useful) development workflow enhancement, never about security. We had no version control system until last year. One of my reasons was security, to help protect against any possible code injections. Am I justified in telling my non-tech-savvy boss that Git helps with security (as well as development)? Apr 6, 2017 at 2:33
  • 1
    @Arminius Git vs no version control whatsoever. As a security expert, would version control be something that comes to your mind to advise a client? Our site has probably 100k+ files under git, but even for a small site I could see the security value. But I'm not a security expert, so that's why I ask. We had no version control until I put us under Git last year. Apr 6, 2017 at 2:38
  • 3
    @ButtleButkus Well, you already outlined the biggest argument in your question. Tracking changes makes it harder for an attacker to inject malicious code without being noticed.
    – Arminius
    Apr 6, 2017 at 3:06

3 Answers 3

3

The security features of using Git might not be straightforward as they depend on what you're using it for, but here are some ideas.

Version Control - duh. But if you're using Git to track configuration files, Software Defined Networking, infrastructure provisioning code, or a deployed application, and suddenly things don't work. You can (theoretically) revert to a known good configuration, see what changes were made, and see who made the changes. This provides auditing and (a form of) disaster recovery. Furthermore, if it's used to manage puppet configs or Infrastructure as Code, it can serve as self-documentation. All of these can protect against downtime.

Hashing - Though SHA1 is considered much less secure now that an intentional collision has been demonstrated, it's still unreasonable to expect almost any malicious actors in a reasonable amount of time to be able to modify anything in your git repository that would stand against scrutiny.

Those are really the only benefits that come to mind, but using something for a version control of configuration files is a huge deal for enterprises. When you have many people capable of "fixing" configurations on your networks and servers, version control provides a very strong mitigation. Generally it would need to be paired with configuration management like Puppet or Salt.

1
  • 1
    +1 for the mention of tracking infrastructure changes. Apr 6, 2017 at 6:03
2

Even if attackers were able to do their own commits and rewrite the commit history, they likely would not be able to push to origin. But even if they could, other remote instances of the git repo would still retain the original history and get errors when they try to push.

Whether malicious modifications to the Git history actually get detected depends a lot on the contributors' workflow. A developer who does a lot of careless rebasing might easily establish an unauthorized edit. Luckily, Git has a feature for GPG-signing commits which can mitigate the risk (if used consistently). This article is also a good read on repository integrity and rogue commits.

A different argument that might appeal to your boss is that they can trace back security-related bugs not only to an exact date but the individual contributor. This way they could easily identify developers that need additional security training. But honestly, even without security arguments there should be no debate about the advantages of proper source code management.

1

Tracking altered files with Git has been there for some time already: tools like etckeeper are used to track changes in server configuration. But don't expect miracles: Git is a version control tool, not a security tool, it will not warn you if an important file changes unexpectedly.

Frankly, if you can't convince your boss to use Git because of its version control features (as in, we have to use it to be sure we don't lose our files), I don't think that throwing security aspects in the mix will convince them.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.