Open source code use within financial services organisations visibility only 50% at best, says software quality expert

Julian Brook, associate director at SQS Software, which conducts quality control testing on business software, said that almost every organisation that is developing software will be using open source code to some extent, but that a lack of governance and controls mean they will not be able to accurately quantify the amount.

Businesses lacking in controls are open to potential security concerns and are also at danger of exposing commercially sensitive intellectual property to public consumption, he added.

"I would say that, arguably, open source is used in every organisation that is developing software, especially in the financial services world," Brook told Out-Law.com. "Very few of the organisations will have sufficient controls in place to know all of the open source they are using with any confidence. There is 50% visibility at most."

Brook said the lack of visibility varies between organisations but that SQS had identified open source code within companies' developed software where those businesses had a no-open source code policy and had been adamant that none existed within their software. Many other businesses had underestimated the extent of open source software contained within their software packages, he added.

'Open source' is a term that refers to software constructed using underlying code that is made available by developers for others' use without the need to pay licensing fees but that may be subject to other requirements. Responsibility for upgrading open source software rests with its community of users.

Brook said that the use of open source code within mobile technology and mobile payment systems is on the rise.

"The number of open source projects that are targeting the mobile space are increasing rapidly," Brook said. Open source code has been used in 'near-field communication' technology that facilitates contactless payments, through mobile wallets for example, he said.

Typically those making use of open source software face licensing obligations and restrictions with regards to that use.

Licensing restrictions may prevent open source code being put to commercial use, or require users to publish all of the code behind software where open source code was only a component part.

"This would mean exposing your intellectual property," Brooks said.

Businesses may also encounter security risks from using open source code, although those risks are also present in using proprietary software, Brooks said. Ensuring that open source code is of a good quality and stems from a large community of active developers where "bugs have been flushed out" in peer review should mitigate the security risks, though, he said.

To address licensing and security concerns, organisations developing software should have appropriate governance and control procedures in place and ensure that the internal culture and strong leadership demands that procedures are followed, Brooks said.

"There are two kinds of checks that organisations developing software should have in place," Brooks said. "The first is process-based where any individual within the organisation wishing to use open source software should have to request its use. You don't want to slow up developers but you also need to have the ability to log requests."

This upfront check may involve a number of people, such as the lead architect on projects, the security, compliance and legal team and possibly even the procurement and quality teams too, Brook said. Those individuals should be able to identify potential issues with the intended use of open source code and, if appropriate, alter the way it is to be used or prevent its use entirely, he said.

Having this check in place at the outset will help businesses avoid having to "rebuild software" upon discovering the existence of unaccounted for open source code later in the development process, Brook added.

"The alternative is to scan an application [after it has been built] to discover what open source code is contained within the software," Brook said. This second assessment is a "good 'belt and braces' check at the end of the process".

The upfront check need not be overly bureaucratic, Brook said. Organisations can create a 'whitelist' or 'blacklist' of approved or problematic open source licenses and issue guidelines to staff on the kind of software components in which open source code can be used, he said. This way organisations can put in place a "lightweight" checking system where a "management-by-exception" approach applies, he said.

If businesses are contracting with external suppliers to develop software on their behalf, they should ensure that those suppliers inform them of the open source code they use and a register of what code is used should be maintained so that the use of open source code can be checked and accounted for, Brook said.

"Businesses will want to encourage the software developers they are contracting with to make use of open source code because it will save time and money – why pay them to develop something themselves if it already exists, is free and has already been proven to work by the open source world?" Brook said.

Where suppliers use open source code, suppliers should only be rewarded to the extent that they use their expertise to test and integrate open source software into the wider application, he said.