It’s been a while since I started to talk to people in the financial services ecosystem about our approach towards open source. At first, most of them thinking we were either bold, ahead of our time, or mad would listen to our story but would not really comment: “Let’s see where it goes” or “good luck with your brave intentions.” Only after we started to show progress with the delivery of the FinTP Project, did people start to look seriously at what we were doing. That’s when FinTP started to stir up interest and we got many inquiries about the project.

I’ve already shared the most common questions, like: Why do we do it? Why should we join?

It is also the time when skeptics started sharing their doubts on the success of the open source model, stating that the security vulnerabilities that come from community contributions are a barrier for the project’s reliability. Some were and still are even more pessimistic and claim that financial institutions cannot assume the potential risks that come with adopting an open source solution for critical parts of their business.

I am not going to fuel the ongoing debate on whether open source software is more secure than proprietary software, as it has already been discussed in detail with subjective arguments on both sides.

I have taken part both on delivering open source and closed source solutions. Both are subjected to the same security threats from a technical point of view. Each of the security vulnerabilities have to be contained through coherent management and control over the software development and deployment lifecycle processes. These processes need to be adapted to the type of distribution model—for open source and closed source. FinTP is in fact developed as the next version of a commercial closed source distributed product, for which application users and independent auditors haven’t been able identify any major security vulnerabilities. One of its strongest assets is the community of professionals who seek to contribute their experience and skills to improve the quality and design of FinTP.

This community is still being formed, thus our company still needs to ensure the mandatory alignment to regulations, technological improvements, and most of the bug fixing. We are the first, and for the time being, single source code creator for FinTP. While we expect the community to get traction and the space for collaboration to become more active, the natural trend is to transparently institutionalize the commitment process and committers role. Our company’s internal development and deployment processes went by the CMMI Level 3 process model and later on was adapted to a more Agile approach. By ensuring these processes are adapted to make sense and work in an open environment, I believe FinTP will succeed in maintaining at least the same quality standard. Having said that, I would like to add that in my opinion vulnerabilities that come from community contributions have a risk score as low as contributions in closed source applications.

I want to highlight a couple of areas regarding software security that we focused on while developing the FinTP Project, which should also be common for closed source projects.

According to White Source, most software applications embed open source libraries that are outdated. This means that an old release of a component, with known security issues or bugs, is included in an up-to-date version of the software, which you are using and counting on it to work flawless. Does anyone know if their software vendor embeds the latest versions of open source libraries in the enterprise applications delivered (or even which open source libraries are being used)? Open source applications are more transparent in displaying what technology is used, what the update policy is, and all related licensing implications. Moreover, having the project available in open source means that a neat open source policy is in place that can be checked anytime and in a regulated manner whether the latest versions of embedded open source libraries are included or not (or at least for the more sensitive ones).

The Open Web Application Security Project (OWASP) is an organization focused on improving the security of software, creating awareness, and laying a foundation for developing the security layer of software applications. Our teams of developers and testers established a methodology of assessing risk for security vulnerabilities, following the OWASP Enterprise Security API. That means the design of FinTP addresses the most common vulnerabilities and security best practices, covering a range of risk scores from low (passwords policy, bypassing authentication, and authorization schemas), to medium (credentials transport over an encrypted channel and confidential data encryption), to critical (StoredCross Site Scripting, SQL Injection, and Privilege escalation).

I want to stress that many security vulnerabilities occur and are exploited when technology is not properly understood and exploited. For closed source solutions, customers rely on the guarantees received from the manufacturer of the software or hardware and the provider of services. Usually, there are licensing agreements, maintenance contracts, and Service Level Agreements (SLA) which set a clear limitation of responsibilities between all parties involved. Two typical cases arise here. One is customers with limited resources rely on the skills and know-how of their suppliers. The other is when customers prefer to have control over selecting, deploying, and managing their platforms. When implementing open source solutions, the scenario repeats up to a point: some prefer to subcontract professional services (analysis, development, configuration, testing, deployment, and maintenance) when deploying a solution tailored for their specific needs, while others prefer to do everything in-house.

The difference when implementing an open source application comes from the activities that must be performed to ensure a successful deployment. There are many unstable versions released in open source projects, so choosing a stable baseline is very important. Also, testing for a specific configuration has to be done thoroughly and cannot be limited only to User Acceptance Tests. Another important task is to define an upgrade policy for your deployed open source solution, which is not a very easy thing to do. On one hand, custom developments and configurations have to be aligned to the community version of the application, and security vulnerabilities must be detected and fixed by the community. On the other hand, you want to have a predictable technological upgrade plan with as little maintenance effort and risk possible.

Enthusiasm and creativity are usually important drivers for any technological project, but successful completion always depends on proper management and control processes over the lifecycle of the project.

Our article was also published on opensource.com.