Git Moving!

Let's start with a bit of a history lesson. A few decades ago, not all software developers had access to the master version of a software solution project. In fact, only one of them had access to it and was responsible for sharing only what was necessary. For example, the specific part of code one project member needed to work on. Suffice to say, this wouldn't work too well if you were on a schedule and needed help from several pairs of extra hands. Anyways, in those days, teams who had no copies of previous versions of their projects risked losing everything in a fleeting moment.

The issue of lack of documentation versioning was tackled with the birth of version control systems (VCS). They are basically "a software utility that tracks and manages changes to a filesystem." In the 1970s, Marc Rochkind created the first VCS, the Source Code Control System (SCCS), in order to answer the question "What changed?" when something goes wrong in the development. This was a very important accomplishment because if someone messed up, they could just go back to a previous stable version of the code. That's a neat thing that couldn't be done without a VCS.

The days before VCS were pretty slow. Today's fast-paced development makes it challenging to manage the different versions of systems. As teams need to go fast, they need to be able to distribute work and make changes to the same source code at the same time. Contrary to the old ways of developing software, VCS offer the benefit of continuous cooperative and highly communicative work between team members.

When considering the kinds of VCS that exist, we need to understand that they vary according to where the repository sits and where the developer… well, sits. (Repository is a filesystem that is being tracked for modifications.) The local kind of VCS is relatively simple: The person works on the same machine where the repository is kept. What other kinds are there? Well, there is a kind that keeps the repository in a shared folder and users from within a local area network can collaborate in it. However, it's safer to have a trusted server safeguard your repository, so, in the client/server model kind of VCS, the repository sits on the server and clients can read and submit changes from their machines.

The server model has been known as a centralized VCS. Developers commit changes to a central server that contains all the versioned files. (To commit means to record the change in the central system.) Some centralized VCS are Subversion (SVN), CVS and Perforce. The disadvantages of this model refer to velocity, workflow flexibility and safety. So, first off, commits are slow because they are done through a single network to the central repository. Further, if developers are not in the network, they can't commit. Lastly and critically, suppose the only copy of the repository becomes corrupted somehow: It'd be necessary to wait until the repository is fixed.

Luckily, there's a more efficient kind of VCS. Namely, the distributed one. This one allows collaboration without needing a central repository. Its benefits are clear: velocity, code quality and collaboration.

The distributed VCS can be cloned. In this model, every developer has a clone as their local repository and every clone can be used as backup. It also offers flexibility for personal workflows because developers can commit to their local repositories while offline. Through their personal branches or transient branches created for making a change, developers can merge their work into the main repository and so they are able to go fast. When mentioning this category, Git is what comes to mind. This free and open-source VCS has been used for software development projects, large or small. Some platforms that could host your Git repository are GitLab, GitHub, Bitbucket, Azure DevOps Server, among others. At Fluid Attacks, we use GitLab and can attest to its benefits, which include boosting productivity, accelerating delivery, enhancing traceability, simplifying audits and providing security.

We know it's possible that you feel uneasy thinking about using a VCS or moving from your centralized VCS to Git. Indeed, some mentions have been made about being afraid that moving to Git means having no regular support. However, it turns out that Git's community is constantly there to help. Also, even though the change could be complicated at first, it is worth the effort as your customer base increases and your team becomes bigger.

When a developer is done with the intended change and wants to incorporate it into the main repository, then they make a merge request. Basically, they're proposing a change and are asking their peers to review it. This is the essence of peer review. It works wonders not only because merge requests are saved in the repository, helping keep track of the changes to the project, but also because it encourages interactions between developers.

Now, we would like to propose that security is also a kind of peer review. When you integrate security into your pipeline, even if only with automated tools, you are trusting the work of people probably from outside your project to review your code for vulnerabilities. This is key. If you release your software solution and it's got commonly known vulnerabilities, it won't stand a chance in the wild. The best strategy is constantly reviewing for vulnerabilities while developing and before any changes are made to the main repository.

At Fluid Attacks, we're all for it. We help our clients achieve DevSecOps, securing their projects as early in the software development lifecycle as possible (see image above). Everything begins when their management team logs into our platform. Once they provide the URL to their Git repository, it's all ready to start scanning with all the might of AI and automation. They get reports through the platform, which leads to their remediating the vulnerabilities, and so the cycle is constantly repeated. Through our solutions, we enable our clients to go fast without crashing. What's more, clients of our Advanced plan can achieve better precision (less false positives and false negatives) as our highly certified ethical hackers use manual techniques to test the security of their software. Want to learn more? Contact us!