Open Source Software

What is open source software?

Open source software (OSS), refers to source code that is available for use, modification, and distribution with the original rights, as defined by the Open Source Initiative (OSI). Such software is generally distributed under a GNU General Public License (GPL) or a Berkeley Software Distribution License. 

Open source code is typically shared in a public repository. The general public is encouraged to contribute to design, development, and additional software enhancements. Common examples of OSS include: 

  • GNU/Linux
  • Mozilla Firefox
  • VLC media player
  • SugarCRM
  • GIMP
  • VNC
  • Apache web server
  • LibreOffice

What’s hiding in your applications’ open source code?

What are the key differences between open source software and closed source software?

Choosing between open source and closed source software (i.e., proprietary software) depends on many factors. Two of the most critical include the risk appetite of the organization and in-house expertise availability on the specific piece of software. When deciding between open source and closed source software, consider the following:


Open source

Closed source


Available for nominal or zero licensing and usage charges.

Cost varies based upon the scale of the software.

Freedom to customize

Completely customizable, but is dependent on the open source license. Requires in-house expertise.

Change requests must be made to the company selling the software. This includes bug fixes, features, and enhancements.


Typically less user-friendly. This is dependent on the goals of the project and those maintaining it.

Typically more user-friendly. As a for-profit product, adoptability and user experience are often key considerations.

After-sales support

Some very popular pieces of open source software (e.g., OSS distributed by Red Hat or SUSE) have plenty of support. Otherwise, you can find help through user forums and mailing lists.

Dedicated support teams are in place. The level of service available depends on the service-level agreement (SLA).


Source code is open for review by anyone and everyone. There is a widespread theory that more eyes on the code makes it harder for bugs to survive. However, security bugs and flaws may still exist and pose significant risk.

The company distributing the software (i.e., software owner) guarantees a certain level of support, depending on the terms of the SLA. Because the source code is closed for review, there can be security issues. If issues are found, the software distributor is responsible for fixing them.

Vendor lock-in

No vendor lock-in due to the associated cost. Integration into systems may create technical dependency.

In most cases, large investments are made in proprietary software. Switching to a different vendor or to an open source solution can be costly.


Depends on the current user base, parties maintaining the software, and number of years in the market.

Long market-based solutions are more stable. New products have similar challenges as open source products.


Some open source solutions are very popular and are even market leaders (e.g., Linux, Apache).

In some industries, proprietary software is more popular, especially if they have been in the market for many years.

Total cost of ownership (TCO)

TCO is lower and upfront due to minimal or no usage cost. This depends on the level of maintenance required.

TCO is much higher and depends on the size of the user base.

Community participation

The essence of open source lies in the community participating in development, review, critique, and enhancement.

Closed community

Interoperability with other open source software

Depends on the level of maintenance and goals of the group. Typically better than closed source software.

Depends on the development standards.

Tax calculation

Difficult due to undefined monetary value.


Enhancements or new features

Can be developed by the user if needed.

Request must be made to the software owner.

Suitability for production environment

OSS might not be technically well designed or tested in a large-scale production environment.

Most proprietary software goes through multiple rounds of testing. However, things can still go wrong when deployed in a production environment.

­Financial institution considerations

The financial industry tends to avoid open source solutions. If used, vetting processes must take place.

Financial institutions prefer proprietary software.


No warranty available.

Best for companies with security policies requiring a warranty and liability indemnity.

What problems can open source introduce?

Security is an important consideration in both open source and closed source software. The debate rages on with regards to which one is more secure. However, with proprietary software, the company who developed the product is often more concerned about reputation than open source software creators. They are blamed and critiqued when a security flaw comes to light. In the world of OSS, there is no defined software owner, no reputation to uphold, and no blame to assign. 

While open source software source code is available for anyone to review and use, it is also exposed to malicious users. Proprietary software code, on the other hand, isn’t readily available. Thus, it is more difficult for attackers to see and exploit the software. 

Many experts claim that the open availability of source code makes OSS more secure. As many developers work on the code, the possibility of flaws being caught and resolved as per Linus’s Law is strong. Additionally, firms and individuals voluntarily scan open source products for vulnerabilities and release the findings. 

In recent years, we’ve observed OSS vulnerabilities (e.g., Heartbleed, ShellShock) that put organizations’ assets at serious risk. To manage these risks, firms must have an OSS security initiative in place. This provides a degree of assurance that OSS is free of inherent security risks

To securely implement an open source software security initiative, ensure that the following best practices are in place:

  • Employ an analysis of OSS matching your firm’s security policy requirements.
    • If your firm’s security policy doesn’t include OSS, one must be put in place.
  • Create and maintain a repository of OSS in-use within your firm—including clear ownership.
  • Ensure that vulnerability information such as the Common Vulnerability Enumeration (CVE) or NIST Vulnerability Database (NVD) is mapped to a repository and kept up to date.
  • Ensure that OSS in-use within your firm is up to date.
  • If OSS is abandoned or slow to update, establish a process to mitigate or accept risks.
  • Perform security evaluations for all OSS currently in use (e.g., with Software Composition Analysis or Fuzz Testing)
    • If you don’t have in-house security experts, consult a vendor to conduct this evaluation.
  • Establish a security assessment plan for ongoing and future OSS that is incorporated in projects.

Maintain these best practices to avoid the introduction of security flaws within your organization. Invest in OSS security today to avoid a much more costly and damaging security breach in the future.