A large number of open-source products and libraries (software whose source code is community-built) are being used by developers and organizations around the world, not just because of their cost-related benefits, but because of their capabilities. But recently, there have been incidents of organizations becoming victims of cyberattacks because of some loopholes in the security of these open-source products. A single vulnerability in an open-source application can lead to a major disaster like Equifax. In that case, the attackers had exploited a vulnerability in the open-source component of Apache Struts2 and managed to steal personally identifiable information (PII) of some 147.9 million people.
Thus, the importance of protecting these open-source components has now become a significant challenge for all organizations. Developers and programmers need to make sure their software isn’t exploited by bad actors. Many organizations and developers understand the risk and have started implementing adequate security practices. Let’s talk about five key security practices that can help you protect your open-source libraries:
1. Use security tools to find and fix security vulnerabilities
In recent years, many open-source and commercial tools have been developed to solve the issue of finding security vulnerabilities in open source components. Each tool or service has a different way of working and the ability to find out any known and unknown issues in open-source tools.
Some free or publicly available tools are Arachni, Grabber, Iron Wasp, Nogotofail, and many more. Some commercially available tools include Hakiri, Snyk and more. These tools can help find vulnerabilities in open-source components in applications, along with transitive dependencies. After finding out known or unknown issues, the tool collects mitigation possibilities as offered by the community. It provides a suggestion for mitigating issues such as links for patches, recommendations for system configuration changes. These tools then show all possible solutions and help the user fix the issue.
2. Always keep track of security updates for open-source libraries
One of the crucial aspects of protecting open source components is to have an updated inventory of an organization’s open-source libraries, both in development and production environments. By not having updated information on which open-source components are being used in their applications, an organization faces a major security threat from external attackers. Many popular proprietary applications include indirect open-source components that might not be in active development or receiving updates. For that reason, these open-source components remain unpatched and become a threat over time. This usually happens because the organizations spend most of their resources on securing in-house components, but miss-out updating the open-source third-party libraries, leaving them exposed to cyberattacks.
To solve this issue, organizations should start surveying the open-source components they use and take note of the last time these were updated with the latest security patches. Organizations can also create a central repository of open-source components where security updates can be managed. This will provide detailed information about the security of open source components being used, and whether or not recent updates have been applied.
3. Have an automated patch management strategy
Finding the known and unknown vulnerability is just the first step to protecting open-source libraries, but not patching them as soon as possible will still leave them vulnerable. One of the greatest examples of this scenario is the Equifax breach, which showed what can go wrong when patches aren’t applied immediately.
Organizations usually use various open-source software. Keeping track of every one of them is a very complicated task, let alone patching them quickly when they are vulnerable to a specific issue. So, for efficient and fast patch management, an organization can deploy automated systems to deploy patches with just a mouse click from a single workstation (added benefit of time-saving). SolarWinds and GFI are two vendors that offer such a solution. Also, you can schedule all critical patches to be deployed on a daily or weekly basis. An environment that’s up-to-date on current patches offers great resistance to any attempts of external cyberattacks.
4. Enforce security policies for open-source libraries
Implementing security standards and policies will help developers or organizations to stay protected while building apps using open-source libraries. Such policies will require developers to verify that they do not have any known vulnerabilities pending to be patched. Sometimes, developers are aware of the risks associated with different open-source components but they tend to overlook these vulnerabilities in the absence of any strict rules. Having clear security rules and standards will help them acknowledge and adhere to them.
Organizations should require that developers check open-source components for any known or unknown vulnerabilities before using them. Developers can also follow secure coding practices during the design stage of application to make sure that security policies are enforced within the architecture during the development phase itself. Having in mind all risks associated with vulnerable open-source components will surely help the organization stay protected.
In Kubernetes-centric, or container-centric stacks, open-source tools like Project Calico have emerged as a great way to define a perimeter around every service of the application. This improves the overall security posture as defense is not just peripheral, which if breached leaves the entire application unguarded. Rather, defense is set up at every level and every service. This means that even if one service is compromised, all other services are still safe and protected. This distributed approach to security is natural to modern cloud-native applications and infrastructure. This is especially important if you work with modern tools like Kubernetes.
5. Use automation tools to list all the dependencies
Developers can use tools like Scon and CMake for developing automation, which can perform an in-depth scan and provide details about how an application is built and list all the application’s dependencies. This can be very useful for identifying vulnerable open source components.
Automation tools can help consolidate and centralize the management of dependency versions without adding dependencies, which are inherited by all applications used in open-source libraries. In simple words, it gives visibility into which open-source library is being used within a corporate development environment. Also, there are several build automation tools, offering similar functionality in listing dependencies like Maven, GNU Make, Ninja Build, and Gradle. These tools can show a dependency tree of all applications that depend on open-source libraries.
Open source is here to stay, and so are open-source vulnerabilities
The trend of using open-source libraries to develop applications is becoming popular and will continue to grow. But just acknowledging it is not going to help organizations. Instead, they need to be proactively adopting security practices like tracking security updates, application dependencies, proper patch management programs, and security tools to find or fix those issues.
There is no perfect nor easy solution but following best security practices will surely help. Fortunately, there exists today a plethora of tools and solutions that secure application and infrastructure end-to-end. Many of them are specifically focused on open-source security. There may not be a single tool that acts as a silver bullet for security, but adopting a strategy of best-of-breed security will help to enforce security on multiple fronts. Let’s face it — open source is here to stay, and it is a game-changer for software development. What will separate the winners from the losers will be how well they enforce security while using these open-source applications and tools.
Featured image: Wikipedia
