Open source code management: How to safely use open source libraries and frameworks?

When developing internal and external applications, organizations are increasingly using open source code-which is reasonable. Using free pre-built components rather than writing your own code can significantly shorten application development time and improve the probability of software development success. When developing applications, the development team can easily use hundreds of more open source libraries, frameworks and tools, and countless code from the Internet.

However, open source code is risky-even the most widely recognized code base. No one can guarantee that the open source code will not have bugs or that it has adopted an open source code management process that meets the requirements of the enterprise application in the development process. Even if an Open-source project has an active user community, it may have new and old vulnerabilities. This year, for example, the open source Ruby on Rails Web application framework has encountered several vulnerabilities, with an estimated 200,000 sites that could be attacked by remote code execution. Worse, these bugs occurred in 2007, which means that all versions of the framework have such problems for more than 6 years. In this article, we'll show you the scope of the risk of using open source code for enterprise applications, and ways to reduce risk with open source code management technology.

Open source code and vulnerable components

Some people think that open source code to enterprise application risk is very limited, because many times the open source code only applies to the limited application component. However, the application component almost always has the full permissions of the entire application, so a problematic component can always have serious consequences.

Vulnerabilities in any code can be small or serious, and can be difficult to attack, but vulnerabilities on common frameworks, libraries, or components can be significantly riskier. Now the free hacker tool set is updated quickly, they add these newly discovered vulnerabilities to the automated scanners, so that applications that use these problem codes are quickly searched and then attacked, not only by advanced hackers, but also by primary hackers who use automated attack tools.

The presence of these vulnerable components in new applications is a serious problem, so it appears in the latest owasp ten application vulnerabilities list. On the previous version of the owasp list, it belonged to a more general "Security Configuration Error" entry, but it is now a stand-alone entry--9th: "Use a component with a known vulnerability."

For example, Owasp noted that 2 of the components with vulnerabilities were downloaded up to 22 million in 2011. The first is to bypass the Apache CXF authentication: The Apache CXF Framework cannot provide an identity token, so an attacker can have full privileges to perform any Web service. The second is the abusive expression language in the Open source Java Framework Spring, which allows an attacker to execute arbitrary code to control the entire server. What are the consequences? As long as enterprise applications use these problematic frameworks, they may become the plaything of attackers.

Implementing software security through open source code management

The benefits of using open source code are certainly better than the time and resources needed to develop applications from scratch, but on the other hand, the enterprise still has to use a process to ensure that all third party code is updated. Most development teams don't even know the origins of some of these codes, let alone newer versions.

However, not all open source projects use an understandable version numbering mechanism, so vulnerability reports are not always able to accurately identify the vulnerable component versions. Fortunately, websites such as CVE and NVD provide services to facilitate the search and query of this information.

To improve the management of open source code, the development team must first create and maintain an up-to-date list of Third-party code uses, including all dependent codes and sources. Assign a person responsible for each source to keep track of mailing lists, news and updates. This should not be just a passive activity; Because not all new vulnerabilities are reported to a centralized information center, you also need to monitor the public security mailing list. Some teams may find that they have to reduce the number of code sources they use to improve management efficiency, and there is certainly a strategy for managing code use, such as business cases, risk assessments, and acceptable authorizations.

If an application uses problematic code, first check to see if it uses the part of the code that contains the vulnerability, and then evaluate whether it has a risk that needs to be addressed. It is important to note that many open source projects do not release patches; instead, they usually fix the problem by releasing a new version. There is an emergency response plan to deal with important releases, since many of the applications connected to the Internet should be rigorously reviewed, and they may require a quick response to prevent an attacker from successfully breaking the vulnerability.

Enterprise developers who use open source libraries should know the risks of open source code. Even if the code can significantly reduce software development time, using them may unnecessarily increase the vulnerability of an enterprise application, increasing the risk level of the organization and ultimately requiring more time to deal with the risk. To pay attention to these issues in advance, organizations can safely use open source libraries and frameworks without placing applications and the entire organization at unnecessary risk.