CSOs are entrusted with the security of the organization. As such, they aren’t keen on anything that might threaten the security perimeter, physically or digitally. Open source software (OSS) components help developers speed up the development time. However, introducing open source components is often akin to introducing danger into the company network. One OSS vulnerability may lead to data theft and the loss of trade secrets.
In this article, I’ll provide you with the information you need to decide whether OSS is for you, and how to make your CSO happy even if you do decide to introduce OSS into the codebase.
What is a CSO and why should you strive to make them happy?
A Chief Security Officer (CSO) is responsible for the security of the company. The CSO is entrusted with securing the physical and digital perimeter, including personnel, physical assets, and information. If your open source components introduced a vulnerability or malware into the company’s network, that would make your CSO unhappy.
What is open source?
Open source code is a piece of software made available for public use under an open source license. There are currently over 200 open source licenses, each grants different uses of different software.
Developers use OSS code to speed up the software delivery time. Instead of writing the entire codebase from scratch, you can use OSS as is or as a template that you modify according to the specs of your project.
The danger of open source
According to Linus’ Law, the more eyes you have on the project, the more eyes you have to debug the code. This assumption might work in an ideal world. However, in practice, the openness of OSS makes it vulnerable. Anyone can alter the OSS code, and introduce a vulnerability or malware into a previously safe codebase.
OSS has become so popular, it makes up more than half of the analyzed enterprise codebase, many of which combine a great number of OSS components. In the first quarter of 2019, more than 5,000 vulnerabilities were reported. Many people download open source libraries, assuming they’re safe, only to discover it’s infested with malware.
The importance of OSS security
As the popularity of OSS continues to rise, keeping track and securing OSS becomes vital for the health of the company’s network.
OSS vulnerabilities can be exploited by actors to gain unauthorized to the network. Malware in your open source can mess up with your applications, at best, at worst you’ll find yourself dealing with ransomware and the consequences of data loss.
Keeping track of open source components can be a time-consuming job, but it’s a necessary one. Yet here we are, five years after the Heartbleed Vulnerability catastrophe, and we can still see traces of the vulnerability, according to Black Duck’s audit report.
Below, we’ll review a number of issues that make open source security difficult to maintain, and provide solutions for maintaining a healthy codebase despite these OSS difficulties.
Best practices for managing open source components
1. Create an open source software policy
Organizations use a policy and procedures (P&P) document to provide personnel and relevant parties a guideline for proper conduct in certain situations.
An open source P&P should provide guidance as to the proper management of OSS components, including which type of OSS licensing is permitted, which type of components, when to patch, and how to prioritize vulnerabilities. The goal is to avoid chaotic situations in which no one knows what to do during an OSS security event.
2. Never ever copy-paste OSS
Developers use OSS as is to speed up the development time. They throw in the OSS code into their application, hoping to add a few more features in as little time as possible.
Using OSS components as is can seem like the fastest choice, but it’s a short term decision you’ll leave to regret. You won’t be able to track the code. When an update is released, you won’t be able to track the OSS. If a vulnerability is discovered and disclosed, you’ll have a hell of a time looking for the component and applying the patch.
3. Don’t copy – Fork
In software development, a fork is created when one piece of source code is used to create a distinct work.
Developers use ‘forking’ to modify the OS component, per the allowances specified in the license. Rather than use the OSS as is, the developers clone the project, modifies it to his purposes, and therefore turns it into a different piece of code. The OSS serves as a template that speeds up the development, but the modification makes the code trackable and thus easier to manage.
4. Monitor your OSS
To maintain a healthy codebase, organizations should keep an eye on the OSS components they have introduced into their software.
Visibility gives security experts the opportunity to respond to security events in a timely manner. In some cases, that could mean real-time response to a malware that made its way into the network through OSS. Another time you might need to respond ASAP to a disclosed vulnerability.
Since you can’t fix what you’re not aware of, remediation always starts with visibility. Create an inventory of your OSS components, along with licensing agreement, and keep track of them at all times.
5. Patch as if your life depends on it
Vulnerability libraries like the National Vulnerability Database (NVD) can provide information on OSS vulnerabilities to the public.
Organizations should make use of vulnerability libraries to keep track of the known vulnerabilities, and ensure that their codebase is healthy. As soon as you discover a vulnerability in your code, stop and assess the situation. Use sources like the Open Web Application Security Project (OWASP) top 10 vulnerabilities list, which can help you prioritize vulnerabilities and respond appropriately.
6. Update as if your life depends on it
OSS projects release updates that improve the performance and security of the code. In many cases, a new version of the OSS will include security patches that have been applied.
It may take a long time, but sooner or later vulnerabilities and malware are discovered. If the OSS project is being maintained on a regular basis, the contributors will release a new version after discovering a vulnerability in their code. Then, it’s up to you to update your codebase. If you used forking instead of copying, you’ll have the ability to locate and update the OSS.
7. Automate whenever possible
Due to the staggering amount of vulnerabilities located in OSS, organizations should use automation to eliminate as many manual tasks as possible.
In OSS management and security, there are many repetitive tasks that could and should be delegated to automation tools. Trying to keep track of thousands of vulnerabilities manually has become an impossible task for humans alone. Automation tools can help you create a vulnerability inventory, keep track of the vulnerabilities, and prioritize remediation.
Conclusion
The secret to a CSO’s heart is through a healthy codebase. If you’re interested in introducing OSS into your company’s network, be prepared for a major security challenge. You’ll need to keep track of your OSS, keep an eye out for vulnerabilities, and keep the company codebase as secure as possible.
To implement a safe open source strategy, you should follow the best practices in this article and keep yourself informed of the latest OSS security news. They’ll keep your software secure, and your CSO happy.
