> Using open source code can significantly reduce open time and resources, but no one can guarantee that open source code will not have bugs, nor can it ensure that it adopts an open source code management process that meets enterprise application requirements during the development process.

When developing internal and external applications, businesses increasingly use open source code—which is reasonable. Using free pre-built components without writing your own code can significantly shorten application development time and increase the probability of software development success. When developing applications, the development team can easily use more than a hundred open source libraries, frameworks and tools, as well as countless code from the Internet.

However, open source code has risks – even the most widely recognized code base. No one can guarantee that open source code will not have bugs, nor that it will adopt an open source code management process that meets enterprise application requirements during the development process. Even if an open source project has an active user community, it may have new and old vulnerabilities. For example, the open source Ruby on Rails Web Application Framework has encountered several security vulnerabilities this year, with an estimated 200,000 websites likely to be attacked by remote code execution. Even worse, these bugs appeared in 2007, which means that all versions of this framework have had such problems for more than 6 years. In this article, we will introduce the range of risks posed by open source code to enterprise applications and ways to reduce risks using open source code management techniques.

#### Open source code and vulnerable components

Some people believe that the risks posed by open source code to enterprise applications are limited, because many times open source code is only applied to limited application components. However, the components of the application almost always have all permissions to the entire application, so a problematic component can always have serious consequences.

The vulnerabilities of any code may be very small or serious, and the difficulty of attacks can be large or small, but vulnerabilities that occur on general frameworks, libraries or components are obviously at a higher risk. The free hacker tool set is now updated very quickly, and they will add these newly discovered vulnerabilities to the automatic scanner, so that applications using these problem codes will be quickly searched and then attacked. Not only advanced hackers can launch attacks, but some junior hackers using automated attack tools can also attack.

It is a serious problem to have these vulnerable components in new applications, so it appears on the latest OWASP Top 10 Application Vulnerabilities List. On the previous version of the OWASP list, it belongs to the more general "Security Error" entry, but it is now a standalone entry - Article 9: "Using Components with Known Vulnerabilities".

For example, OWASP pointed out that two components with vulnerabilities reached 22 million downloads in 2011. The first is to bypass Apache CXF's authentication: The Apache CXF framework cannot provide an identity token, so an attacker can have full permissions to execute any web service. The second is the abused expression language in Spring, an open source Java framework, which allows attackers to execute arbitrary code to control the entire server. What are the consequences of this? As long as enterprise applications use these problematic frameworks, they can become playthings in the hands of attackers.

#### Implement software security through open source code management

The benefits of using open source code will certainly outweigh the time and resources required to develop applications from scratch, but on the other hand, enterprises still have to use a process to ensure that all third-party code is updated. Most development teams don't even know where some of this code comes from, let alone updates.

However, not all open source projects use an understandable version numbering mechanism, so vulnerability reports do not always indicate exactly the vulnerable component versions. Fortunately, websites such as CVE and NVD provide services that facilitate searching and querying this information.

To improve the management of open source code, the development team must first create and maintain a latest third-party code usage list, including all dependency code and sources. Assign a person in charge for each source to track mailing lists, news and updates. This shouldn't be just a passive activity; because not all new vulnerabilities are reported to a centralized information center, so public safety mailing lists need to be monitored. Some teams may find that they have to reduce the number of code sources they use to improve management efficiency; and, definitely, develop a strategy to manage the use of code, such as business cases, risk assessments, and acceptable authorizations.

If an application uses the code in question, first check whether it uses the part of the code that contains the vulnerability and then evaluate whether it has the risk of handling it. It is important to note that many open source projects do not release patches; instead, they usually fix the issue by releasing new versions. There is an emergency response plan to handle some important releases, as many Internet-connected applications should be scrutinized and they may require a quick response measure to prevent attackers from successfully breaking the vulnerability.

Enterprise developers using open source libraries should be aware of the risks of open source code. Even if these codes can significantly reduce software development time, using them can unnecessarily increase vulnerabilities in enterprise applications, thereby increasing the risk level of the organization, ultimately requiring more time to deal with risks. To be aware of these issues, businesses can safely use open source libraries and frameworks without putting applications and the entire organization at unnecessary risk.