Git What? Why should the CISO care?

Software development is changing rapidly and security programs must evolve if they are to be effective in this next generation of software. Most significantly, Git and its commercial code repos have facilitated the DevOps methodology that is so impactful to software development, and which also puts enormous pressure on application security programs to evolve. 

Sometimes it can feel like developers and security are each speaking a different language. Bridging that gap is an important step to empowering developers to identify and resolve security vulnerabilities that they themselves create. So here is a first step at bridging that communication gap.

Git, GitHub, GitLab! Are they all the same thing? Should you care about the difference? It’s all for developers anyway, right? Why does it matter to security? 

Git

Git is a free and open source distributed version control system, started in 2005, used to help multiple software developers work on a given code base. They make their own copy of the code, change it, then check in their contribution. The repo manages conflicts among developers’ changes. Repos were revolutionary in that developers no longer had to be invited to contribute to code, facilitating the ability to essentially farm out pieces of code amongst multiple developers. It has radically changed the way software is developed whether open source or proprietary.

GitLab and GitHub offer all of the distributed version control and source code management (SCM) functionality of Git as well as their own features with paid tiers of offerings. While both started as code repositories, and share “Git” in their names, that is where the similarity ends.

GitHub

GitHub began in 2008 and was purchased by Microsoft in the Fall of 2018. GitHub hosts the most open source projects so is well known among developers. GitHub’s primary focus is on source code management although the newly announced GitHub Actions promises to automate a broader scope of the software development lifecylce. 

GitLab

GitLab began in 2011 and remains an independent company with a very transparent growth strategy. GitLab estimates it hosts ⅔ of the proprietary enterprise self-managed code. As a single application for the entire Software Development Lifecycle (SDLC), GitLab’s scope of capabilities is more akin to Microsoft’s Azure DevOps than to GitHub. GitLab incorporates application security scanning within its Continuous Integration capabilities.   

Continuous Integration (CI) and Continuous Deployment (CD) 

The multi-threaded development approach, enabled by both Git repos and Agile methodologies that allows a much faster velocity, or cycle time, for software development. With CI/CD, these small, incremental code changes can be tested and deployed to test and to production. The process of code quality testing, a review environment, and assigning compute resources is automated. With automation comes standardization and repeatability, along with closed loop metrics helpful for process improvement, frequently found with Agile methodologies.

The key to truly “shift left” and empower developers to find and fix vulnerabilities early (DevSecOps), is embedding security testing into the developer’s native workflow – generally into the CI/CD process. While many traditional application security vendors are feverishly trying to make this happen, Microsoft and GitLab are the two leaders in doing this. Microsoft is doing so through a combination of its acquisition of GitHub and via Azure DevOps. GitLab automates app sec within its own developer tool, enabling a seamless path-of-least-resistance for secure coding practices and a compliant, audit-able process for securing the code itself. 

These tools automate software development and deployment. Security that is not automated alongside it may get left behind. As software becomes more iterative, security must also. To begin, the security professional should understand which tools developers are using and the velocity they are hoping to achieve. Security should determine the security policies needed to align with the appetite for risk and then use the DevOps tools to automate consistent application of those policies.

To learn about more of the ways next generation software will challenge security, this book covers: 

• Additional ways software development is changing: the code itself, the methodologies by which it is developed, and the infrastructure surrounding its use,
• Recommendations for security changes to meet these new demands, and
• Pragmatic advice to get started.