Years ago, when we talked about open source code, we were talking about something that was really only relevant to classic computer geeks – the ones running their computers on Unix and swapping bits of code on message boards. Times have changed, though, and now open source code is an integral part of how most businesses and just about anyone in the software world does their work. As Bart Copeland, CEO of the open source language tool company ActiveState explains, today’s companies have to use open source code to stay competitive. But while choosing open source code is important from a competitive perspective, that doesn’t mean it’s a simple or risk-free choice.
One of the serious concerns with using open source code in business application development is that the majority of codebases contain at least some major vulnerabilities, and as soon as a company starts working with one of those codes, those vulnerabilities become their responsibility. That’s who customers will blame if there’s a data leak and, while hackers often seek to exploit specific vulnerabilities, they aren’t interested in the code qua code. They want a given business’s data. So, how should businesses handle this problem?
Faced with open source vulnerabilities, businesses need to take ownership over code vulnerabilities, but there are plenty of tools at their disposal. From predictive analytics to vulnerability databases, businesses already have access to everything they need.
Predicting Problems
When it comes to cybersecurity, one of the most powerful tools that businesses have at their disposal is predictive analytics, essentially machine learning capabilities that can detect likely threat actors, identify vulnerable targets, and quickly test new security fixes and defense strategies. These systems can be merged with more concrete security mechanisms beyond the code like Web Application Firewalls (WAFs) that monitor network traffic and protect the applications and data therein.
Databases For Developers
On its own, open source code isn’t safer or more vulnerable that proprietary code. Rather, a major part of what makes open source code such a problem from a developer perspective is that so many people are using it and that means that when code launches with a major vulnerability, it could end up as part of a wide variety of applications. Luckily, because there are so many developers actively using and tweaking open source code, there are also databases specifically for cataloguing common vulnerabilities and exposures (CVEs).
Any time a developer works on an application, it’s critical that they check a vulnerability database to find out if there are any known vulnerabilities in a particular code component and, for those known vulnerabilities, whether there are available solutions. CVE databases use a standardized description method to identify each vulnerability and can connect developers with appropriate patches. Developers also need to regularly check these vulnerability databases, even after they’re done working on a program, to ensure new vulnerabilities haven’t been discovered.
Automation Offers Advantages
If developers are constantly checking their old code for vulnerabilities, how are they supposed to get anything done? That’s a legitimate question, but one with a ready solution – automation. Most vulnerability analysis really consists of automated scans, cross-checks, and updates designed to protect the overall system. Discovery tools manage the various assets at hand, simplify the process, and can actually halve the total time businesses use on vulnerability management procedures.
Control Your Code
Many of the most serious data breaches in recent years ultimately stemmed from vulnerabilities in open source code – take as an example the Equifax breach. Not only did the Equifax breach stem from a basic code vulnerability, but the bigger problem was that the company had left their code untended. The necessary patch had been available for about two months before the system was hacked. That was a few years ago, but little has changed. Many websites and companies are still operating with unpatched code or vulnerabilities that could easily be eliminated by skilled coders. If these companies don’t act fast, they could face similar blowback to what Equifax endured back in 2017.
Some companies are hoping that they can sidestep some of the vulnerability issues by using new security and cutting off hackers at the pass, but such approaches should be viewed as secondary to vulnerability management. The shift towards containers is one example of this. Yes, application containers abstract programs from their environment in a way that can protect them from certain security risks, but it doesn’t make sense to prioritize container use over patching. But containers plus Runtime Application Self-Protection (RASP) plus patching: now that’s substantive security.
Setting aside these many tools, whether a business is using proprietary or open source code, they need to take ownership over that information. Even code from a library is your code and any problems with it will come back to haunt your business, not anyone else – just ask Equifax. Their name is synonymous with data compromise, and it all could have been prevented with a patch.
