As we approach the second full weekend in October, Cybersecurity Awareness Month continues in full swing.  To be honest, I have not seen too many postings or news related headlines on this.  I guess people have a lot more on their mind, especially with the Presidential Elections coming just around the corner.  But as promised, I bring you more topics that are feel are especially relevant for this month.  Today, we look at the concept of Open Source Software.

Loosely put, Open Source (as it is also called) is software that you can download and use for free, without any licensing issues involved.  This is of course a huge advantage over using Closed Source Software, in which you actually have to purchase the software package and have to maintain the licensing for it for as long as you have and make use of it.

Probably some of the best examples of Open Source is that of Linux, My SQL, PHP, Apache, etc.  While the growth of this is has been getting larger every day, it does come with its issue as well.  Probably the biggest one this regard is that of Security. 

With Open Source, you and your software development team are primarily responsible for making sure that the code you use is secure to the environment in which it will be deployed and used.

Unlike the Closed Source software, there are no automatic downloads that you can rely upon in order to get the latest patches and upgrades.  Also, you have to be on your toes to make sure that you are using the most recent release of the Open Source package. 

This can be a time-consuming task, as there is no direct technical support line that you can call to get the answers that you need.  Rather, you have to comb through the many forums that are online to get them. 

The downside here is that the answers may vary and may not even come from authentic source.  So, you have to be careful.  In this regard, it is always best to work in a team-based environment so that you can get answers and ideas more efficiently. 

Another area in which Open Source is showing its security vulnerabilities is that of the APIs.  Simply put, these are the software modules that bridge the gap between different components, such as the front end of the web application to the database.

These APIs can be custom configured, which saves a lot of time in the software development process.  If your coders had to write and compile all of these APIs from scratch, it would take forever, thus prolonging the delivery date to your client.  Here are some key statistics of just how prevalent security in Open Source is today, based upon a survey that was conducted by Synopsis:

*At least 73% of the Open Source libraries that are available on the Internet today have at least one major security issue that is associated with them;

*At least 82% of them contain outdated source code, in which the end user is not notified of.

More details on this study can be found here at this link:

So, what are some of the best ways you can ensure that the Open Source you are using for your project is as safe and secure as possible?  Here are some key tips:

*Create clear cut policies:

Most companies have Security Policies (at least hopefully) in place, which spells out the specific strategies that they will use in order to beef up their lines of defenses from Cyberattacks.  But what is often missing from here is how Open Source will be handled.  Therefore, you need to establish very clear and succinct guidelines as to how the Open Source libraries should be tested and implemented into the application that you are developing for your client.  Obviously, this will vary somewhat on a case by case basis but having these guidelines in place will make sure that everybody, especially your software development team, are all on the same page.

*Make sure that the code is updated:

As just mentioned, many of the Open Source Libraries have some sort of outdated source code component to them.  While it would of course be very nice if the organization that creates these libraries kept everything up to date, the harsh truth of reality dictates the opposite. Rather, it is up to you to make sure that you are using the most recent ones for the app you are about to develop.  After all, who wants something with outdated source code, right?  If you are having troubles deciding which is the most recent one, you always conduct a query in Google, or even post your question to a well known and established Open Source forum.

*Check for the interdependencies that exist:

Just as much as the world is fast becoming interdependent with the IoT, so too is the world of software development.  The web applications of today are heavily dependent upon other components from within them in order to make them work seamlessly for the client.  So in this regard, it is very important that after each source code module has been developed and compiled, that your security test them (as well as the connections in it) before you move onto developing the next module for your web app.  A great way to do this is via Penetration Testing.  This is really the only way to know for sure where the unknown and hidden gaps reside at in the source code.  If you wait to do all of this at the very end and find that there are whole host of issues to be dealt with, you may as well just go back to the drawing board and try to get a new client.  By testing your source code on a modular level from the standpoint of security, not only will ensure that your compiled code is safe, but also all of the interdependencies that exist between these modules are also functioning properly as well.

*Get an extra set of eyes:

The web applications that are developed today can vary greatly widely in terms of both size and scope.  For example, a mom and pop outfit may just require a very simple tool to be created, whereas as a Fortune 100 company may have a project with literally thousands of software modules in them.  If the latter is your case, it is always wise to get a second look at the validity of your security testing processes.  For example, after you have tested the first module, try to get an outside development team to review the results of your testing.  In way, compiling Open Source code is like writing.  It’s hard to proofread your own writing.  Thus, you should try to hire an outside proofreader to do this for you.  By getting a third party involved (of course that is very reputable and can be trusted) you can have better chances of catching mistakes that were accidentally overlooked in the security testing process.

*Confirm the legitimacy:

In today’s world, there are many places online in which you can download Open Source libraries.  But just don’t go for the one that appears first in the Google rankings.  Rather, take the needed time which is necessary to confirm and verify both the legitimacy and authenticity of the repository from which you are downloading the libraries.  It’s like downloading a mobile app.  Hopefully, you will take some to research to research the authenticity of the mobile app before you download it, as there are many rogue mobile apps out there today in the marketplace.  Probably the best way to get started in this regard is with GitHub, as this is deemed to be the most widely used and popular venue in which to obtain Open Source libraries.  The link for it is at:

My Thoughts On This

Whether we like it or not, COVID19 has made the world now pretty much a virtual place in which to work, even when it comes to software development.  Therefore, the need to firmly security test your Open Source libraries and the source code that you create from them is now greater than ever before. 

In order to drive this point home, lets look at it from the standpoint of dollars and cents.  If you don’t test the source code for a web application that you have just created for a client, you will be the first one they will go after for monetary damages in case it has been hacked into!!!

This is of course can be all greatly mitigated by having clear and established Open Source policies in place and making sure that it is being kept up to date on a regular basis.