How to Ensure Safe Use of Open Source Libraries

The open source revolution is on. More and more enterprises are joining the open source bandwagon, to develop their internal and customer-facing apps. Free availability of source code, unbridled flexibility, gross reduction of app development time, resilience, and several other advantages prompt the move. But with great advantages come great risks as well.

The very nature of open source leaves the enterprise app development team with little control over the source and nature of their code. The odds are high that open source code may come with vulnerabilities, open for hackers to exploit.

Technological advances cut both ways. While technology may be used to beef up security, it also enables hackers to update their toolkits, and add any newly discovered vulnerability to their automated scanners. The odds of any application using flawed code being quickly found and exploited are generally high, more so when the open source library in question is a popular one. To make things worse, such hacker toolkits are freely available now.

So how do enterprise counter the hacker menace and ensure they can still reap the benefits of open source?

 

Be Very Careful of Downloads

With dozens of different open source libraries, tools, frameworks, and code snippets freely available over the Internet, there is a very good chance the variant chosen by the enterprise may have vulnerabilities. Even the hugely popular Ruby on Rails web application framework, with a very wide user community known for prompt updates, has been inflicted with several security vulnerabilities, placing 200,000-plus sites at risk of attacks that could lead to remote code execution.

Opt only for versions of open source libraries maintained by established consortium, dedicated to the cause of enhancing and maintaining the software. Such consortium would have a stake in the code. They would almost certainly be supported by grants from generous sponsors, enabling them to issue prompt patch updates, when a vulnerability is discovered.

Enterprises, for their part, need a clear policy on the usage of open source, loaded with:

  1. A white-list of trusted websites, from where the source libraries may be downloaded. The most reliable options are the websites recommended by Open Source Initiative.
  1. A list of security do-and-don’t, to prevent system admins and other users from downloading spurious open source software from dubious sources. Have a well-documented security policy, with clear guidelines on installation and maintenance of open source.

Prefer source code to binaries wherever possible. Most open source products are available either as source code or in package formats or binaries. Binaries offer a far greater level of risk, as there is no telling whether it has complied with the associated source code after all. The best practice is to download the source code directly, verify it against the provided MD5 checksums for integrity, and analyze the code for any latent vulnerabilities, before using it to develop apps.

 

Establish a System

A commercial closed sourced suite is developed through a structured and formal procedure, such as conducting a requirement analysis, defining the acceptance criteria, evaluating the product, comparing the product with competitive options, testing the functionality and security features, and more. Open source code may not necessarily undergo such kind of scrupulous evaluation or validation. There is no short cut but for the app development team to establish a method in the madness themselves.

Have a process in place to ensure adequate control, and to update all third-party code promptly.

Analyze the environment to identify possible threats. For instance, using popular open source libraries makes it that much convenient for attackers to identify vulnerabilities and launch attacks. However, at times, the biggest threat may not even be external, but malicious insiders. Understand the various ways in which the system could be attacked, and protect data accordingly.

Also, have a policy in place to govern code sources. Some teams may find they need to reduce the number of different code sources they use in order to manage them effectively. Within the framework of such policy and analysis:

  1. Create and maintain an up-to-date list of all third-party code in use, including all dependencies and sources. Designate a point person for each such code, to track mailing lists, news and updates.
  1. Avoid ad-hoc installations. Evaluate any open source considered for an enterprise use, and gather accurate information about the product.
  1. Institute an emergency response plan to execute critical releases. Internet facing apps often require a swift response to prevent attackers from exploiting a newly discovered vulnerability.
  1. Institute a dedicated team of system, network and security administrators to implement the policy and also review the policy from time to time, depending on the changes in business environment.

 

Apply Security Tools

Policies and safeguards can only safeguard to an extent, and require reinforcement through effective security tools.

Many open source projects do not issue patches, and rather just release a new version that fixes the problem.

The following are some of the tools worth considering:

Source code scanners such as FlawFinder and RATS (Rough Auditing Tool for Security) identify potential security problems in the source code. These source code scanners undertake pattern matching to highlight the areas of the code that has potential vulnerability and pose security risks such as buffer overflows, racing conditions, shell meta character dangers and poor random number acquisition.

  • Vulnerability scanners such as SARA (Security Audit Research Assistant) and Nessus scan the network for vulnerabilities.
  • Adopt a defense-in-Depth strategy, or a layered approach to securing the network, deploying the most effective security tool at all levels, from, application to the network.
  • Configure the network properly. Disable all unwanted services, adopting the policy of “deny by default unless explicitly permitted.”
  • Assume the network will be breached, and have effective measures in place to contain the menace, such as encryption of sensitive data.

The stakes of security breaches are high. The penalties, damaging lawsuits, and erosion of customer confidence can bring down the enterprise in itself. The most effective and risk-free approach towards adopting open-source is to partner with an experienced partner, like us. With us, you can leverage our considerable experience in not just developing cutting edge solutions using the most relevant open-source tools, but also take the most effective measures to ensure top-grade security.

Looking for a reliable IT solutions provider?

Fingent has helped businesses leverage the power of IT to create solutions that solve complex business challenges for more than 13 years. Get in touch with us for a free consultation to know how you can leverage our expertise in web and mobile applications to improve your business for higher productivity and profits.

Sreejith

Sreejith

I have been programming since 2000, and professionally since 2007. I currently lead the Open Source team at Fingent as we work on different technology stacks, ranging from the "boring"(read tried and trusted) to the bleeding edge. I like building, tinkering with and breaking things, not necessarily in that order.

View all posts >>