Whether or not you know it, your organisation will be using open source software somewhere. Mark Tolliver explains the risks and how to control them

The use of open source alongside proprietary code is the reality of today's dynamic application development landscape. The inclusion of open source makes sense for business – it is readily available, fuels innovation, fosters collaboration, and is free of charge. The widespread acceptance of open source continues to grow as an important alternative to commercial software.

It is safe to say that open source is everywhere and you will have it in your organisation whether or not you know about it. Open source makes up at least 30% of the total code base in all software applications – both internally developed and commercial software applications. Often, it makes up 50% or more.

The benefits of using open source are readily apparent. However, organisations must find ways to effectively manage what has become a very informal 'software supply chain' through which open source regularly enters the development environment and, ultimately, the enterprise network.

Each time a developer imports open source components into an application, they are essentially 'procuring' software. By folding open source into proprietary software development programs, they introduce business risks that live outside existing procurement, review, and support mechanisms designed to manage the process.

Organisations with established open source software management procedures often track open source procurement and use through a variety of means – from Excel spreadsheets and intranet sites, to general email communications. While useful, these methods are seldom sufficient. Insufficient open source record-keeping paves the way for problems in application security and integrity.

The current application development process results in a hybrid code base in which much of the code is not owned or internally developed by the organisation, and has not been adequately documented. The inclusion of open source and other third-party components represents a new set of risks that are especially significant to the financial services industry.

The risks

Operational risks:

¦?Undocumented open source and other third-party code within operational code bases places them outside any policy or governance framework

¦?An absence of open source and other third-party component vulnerability assessment – even if the presence of these components has been acknowledged

¦?Unintentional infringement of intellectual property (IP) rights and licence obligations – unknowingly downloading competitor's code for example.

Business risks:

¦?Vulnerabilities in software assets that may result in compromised application or data integrity (customer data loss, backdoors, targeted attacks, phishing, application downtime, etc)

¦?Legal exposure

¦?Non-compliance with compliance mandates.

Know your ingredients

“Open source patch management is a crucial aspect of overall software risk management.

Open source projects benefit from the public and collaborative nature of the community of users and developers associated with the project.

Experience shows that a great majority of these communities respond quickly to reported vulnerability and security concerns. Their normal course of action is to validate, repair and post a patch or upgraded release to the project web site.

Commercial software suppliers, on the other hand, have put in place mechanisms by which to notify customers of updates and push them out automatically to licensed users.

While some open source projects have commercial services and support offerings, many do not. This puts the burden of responsibility on the user to monitor whether there are security patches or newer versions of the open source project available. As such, for security and development teams, open source patch management is a crucial aspect of overall software risk management. Ultimately, the development team is the primary source of information regarding which open source components are used in the applications they build and which are subsequently installed on the network. Yet this information is also crucial to other departments including security, compliance and legal. If no accurate report of open source content exists, the organisation will be unable to address security or legal issues that are introduced through its use.

The growing complexity of multisource development environments necessitates transparency in the application development lifecycle. Successful open source management calls for a robust and enforceable software risk management process, based on the following best practices:

¦?Policy: Setting guidelines for the procurement and use of open source and third party components

¦?Education: Ensuring that the development teams understand the importance of, and adhere to, the open source use policy

¦?Authorisation system of record Allowing the development teams to request and record open source use for the purposes of creating an audit trail

¦?Audit and analysis Keeping an ongoing inventory of open source and third party components, reporting on their use, detecting known vulnerabilities and alerting the organisation to legal liabilities.

Among the steps for implementing a software risk management policy, code audits are fundamental. They enable security and engineering teams to ensure that open source and other third-party components meet the same security and quality assurance thresholds required of internally developed, proprietary code.

Organisations should also ensure their application development, security, and even compliance teams can confidently answer the following questions:

¦?What open source and third party software components are we using?

¦?Where are we using them?

¦?Are they secure? Do they have known vulnerabilities?

¦What rights do we have to use them, and are we in compliance with any obligations regarding their use?

Knowing what open source is being brought into the organisation allows companies to get a handle on the scope of the open source inventory, the associated licence restrictions and its known vulnerabilities. Enacting best practices for open source use empowers organisations to use it to their best advantage.