Well, here we are now, at the start of the first weekend in August.  I just can’t believe where the time is flying by.  Anyways, back to business.  Some of the biggest news headlines is yet again that of COVID19, especially with its reemergence. 

It is not happening just here in the United States, but worldwide as well.  In fact, other nations around the world are implementing much stricter and harsher penalties for the citizens that do not abide by the stay at home orders.  But with this second, this also means that the Cyber Threat Landscape is not falling asleep either.

Instead, it is getting crazier day by day.  But the common denominator with all of them is that there truly are no brand-new threat variants that are coming out; rather, they are simply derivatives from the old-fashioned ones.  Probably the best example of this is that of Phishing. 

As I have written about before, this is still the oldest threat vector that is out there.  But yet, Cyberattackers are still able to leverage upon this, and craft newer forms of threats that look almost impossible to tell if they are fake or not.

But the Cyberattacker of today knows since the world is now full of gaping security related gaps, so why even bother to create a newer threat variant in the first place?  Why not just go after something that already exists, find the backdoors in that, and from there, deploy the malicious payload? 

This is kind of attack is now starting to prevail, especially when it comes to what is known as “E-Skimming”.  This is where the Cyberattacker finds such holes and deploys malware into the online store of the E-Commerce merchant. 

From this point, the Cyberattacker can take literally full control of this particular site and do anything that they want with it.  But they like to remain covert as much as possible, so that they can leave and come back again any time that they want to.  So in this instance, all that they are really after is the financial information (especially the credit card data) that the customer is inputting into the online store in order to make their purchase.

But this doesn’t stop here.  The Cyberattacker can pretty much these days go after any kind of website, find the backdoors and holes, and penetrate into them that way as well.  At this point, you may be asking, “How do all of these backdoors and weaknesses exist in the first place?” 

Actually, that is a great question to be asked, and the answer is simple: It all comes down to the source code that is being used to develop and create the website in question.

It is not the question how robust the source code is; but rather how strong it is from the standpoint of security.  In this regard, this is where the web application (such as a website) fails the test.  The bottom line here is that the software development team often does not check for the security of the source code that they have compiled for the primary reason that they are under heavy constraints to deliver the project on time and under budget to the client. 

Because of this, rather than custom creating source code from scratch, software developers now very often take source code libraries that are “Open Sourced” (meaning, that they are free to download and use, and there is no issue with licensing), and tweak those to meet the exact needs of the project and the client.

While using open source code can be quite advantageous in terms of efficiency and speed to create the source code that is needed, they too have pitfalls as well, also when it comes to security. This finding has been further substantiated by a recent study conducted by an entity known as Synopsis, and it is entitled:    “The 2020 Open Source Security and Risk Analysis (OSSRA) Report”. 

It can be downloaded from this link:

https://www.synopsys.com/software-integrity/resources/analyst-reports/2020-open-source-security-risk-analysis.html?cmp=pr-sig

One of the key findings of this study is that at least 75% of open source code libraries possess at leas one major security vulnerability that is associated with it.  Also, it was discovered in this study that that at least 91% of the open source code libraries contain libraries within them that have not been updated in at least four years, or worst yet, they have not even been downloaded, thus making them very ripe targets for the Cyberattacker to go after.

So, how can a software development team avoid from being one of these above-mentioned statistics?  Here are three quick tips:

*Embrace the concept of software development in its entirety:

In this instance, the software development team and their related project managers should not just have the narrow view of vision that once they have created the source code for their particular project, that their job is done.  It is far from that.  Apart from making sure that the web application actually works before final delivery to the client, they also need to test from the standpoint of security as well, inside and out.  This is where the methodology known as the “Secure Software Development Lifecycle” also known as the “SSDLC” needs to be firmly adopted and used.  With this, there are certain milestones and time period breaks that can be established dedicated for just security testing the source as each module is completed.  This should also involve both penetration testing and threat hunting exercises to find and locate any weaknesses and backdoors.  The primary advantage of using this methodology is that it does not allow the software development team to wait until the very end of the project to secure test their source code, it must be done after each module is completed.  Probably one of the best resources to use in this regard is that of the OWASP framework, as it relates to open source software code.  It can be downloaded at this link:

https://www.darkreading.com/application-security/3-tips-for-securing-open-source-software/a/d-id/1338495

It is also very important to keep in mind that as many eyes as possible should be used in this security testing phase.

*Their needs to be dedicated Risk Management:

It is very important to mention at this point that if a web application project is delivered to a client, and if it gets hacked into, the primary responsibility and blame for this will fall squarely onto the shoulders of the software development team, and the company that they work for.  For example, not only lawsuits are quite possible, but there could even be further financial repercussions as well, especially from the standpoint of both the GDPR and the CPPA.  So to mitigate as much as possible this scenario from happening, the software development team has to adopt a very proactive Risk Management standpoint from the very beginning of the project. In this regard, probably of the first orders of duty is to thoroughly test the newly downloaded open source code libraries in sandboxed environment. With this, any security vulnerabilities can be found and addressed right on the spot.  This not only further protects the web application that is being developed, but it also protects the IT and Network Infrastructure of the company where the development process is taking place from any malware or viruses as the compiled source code is being uploaded and used on the development servers.  Also, having a proactive Risk Management mindset means also that the software development team is making sure that the open source code libraries that they are using have the most recent patches and upgrades installed onto them, and that they are not using packages that have come or have gone beyond their “End of Life” dates.

*Automate the workflows:

Yes, software development can be a very complex process, and it can even strain the eyes of even the most dedicated of software developers.  This should be automated as much as possible, even from the standpoint of secure testing the source code that is being compiled.  In fact, there are some open source communities that are offering free, automated services to check for any vulnerabilities of your source code, and of these is GitHub.  More information about this can be seen at this link:

https://docs.github.com/en/github/visualizing-repository-data-with-graphs/exploring-the-dependencies-of-a-repository

Also, there are probably other Artificial Intelligence (AI) tools out there that can also be used in this regard.  But keep in mind that you should not just rely upon automation to test the security levels of your source code.  It takes a combination of both the human and technological side of things in an effort to make sure that things are as airtight as possible.

My Thoughts On This

To prove just how important it is to test the security of your source code, do you remember that infamous Equifax breach?  Well, it was discovered that the primary culprit for this attack to precipitate in the first place was a security vulnerability in what is known as the “Apache Struts”.  This is an open source web server platform that is heavily used today by both businesses and cloud providers alike.

Of course, an alternative to using open source code libraries are to use closed source ones.  At least, here, there is some assurance of security testing  and an automated process for downloading the software patches and upgrades (as provided by the vendor) before you can use them in your development project.

But the primary disadvantage here is that this is quite costly, and you also have to deal with software licensing issues.

So in the end, it is a trade off, and a key decision that you will have to make.  But remember, either way you go, testing the security of the source code is purely your responsibility and that of your software development team!!!