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.
It's best when everyone gets a clone!
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
Azure DevOps Server,
we use GitLab
and can attest to its benefits,
which include boosting productivity,
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.
Security as an essential kind of peer review
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.
we're all for it.
We help our clients achieve DevSecOps,
securing their projects
as early in the software development lifecycle as possible (see Figure 1).
Everything begins when their management team logs into our application,
the Attack Resistance Management platform
(ARM). 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 ARM,
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.
clients of our Squad Plan can achieve better precision
(less false positives and false negatives)
as our highly certified
use manual techniques
to test the security of their software.
Want to learn more?
Recommended blog posts
You might be interested in the following related posts.
Definition, implementation, importance and alternatives
Keep tabs on this proposal from the Biden-Harris Admin
Vulnerability scanning and pentesting for a safer web
Definitions, classifications and pros and cons
Is your security testing covering the right risks?
How this process works and what benefits come with it
Get an overview of vulnerability assessment
Benefits of continuous over point-in-time pentesting