By Dr. Thomas P. Scanlon, CISSP
Software Engineering Institute, Carnegie Mellon University

Today’s software developers are as much integrators as they are pure coders. There is an abundance of libraries, plug-ins and other third-party software components readily available to speed development. There is no sense in reinventing something when you can just download it, merge it in and move along. Using free and open source software (FOSS) components can save both time and money, so they make for attractive choices. However, including open source software into development projects often makes the cybersecurity professionals in an organization a little uneasy. But, should it?

There is often a misconception that FOSS components are ‘less secure’ than commercial products. The reality is that on the whole, they are no more or less secure. The relative security of a component is based on many aspects and some FOSS components can measure up extremely well, while some commercial products can measure poorly, and vice versa. The same care should be taken to make sound third-party component selections regardless of the product’s origin.

When evaluating an open source component for use in a project, several factors should be examined to determine the amount of security risk the component contains. Ask questions like these to help determine where security risk may lie:

• Who are the original developers of this product?
• Is the project currently managed by a known foundation or group?
• Is there active development on the project?
• What are the criteria to become a contributor to the project?
• How are code contributions to the project vetted and tested?
• What is the process for reporting, handling and disclosure of vulnerabilities?
• How often is code updated or patched?
• Is there an active community of users for this product?

These questions are similar to those that would be asked when performing due diligence before a commercial product purchase, and that is the point. Security – and risk – can be assessed for open source components just as it can be for commercial products. Open source components even have an added benefit of many more eyes being able to review the source code which provides an added layer of transparency that commercial products often do not.

After open source components are evaluated and selected for a project, there are some ongoing measures that will help manage security risk. Software Composition Analysis (SCA) tools can be implemented to automatically monitor development projects and provide alerts when components in use have new vulnerabilities and when new versions are available. Further, consider adopting policies on open source use, such as components of a certain age must be replaced or updated, restrictions on components that exceed a threshold on vulnerabilities, and blacklists of components from certain sources. SCA tools can help incorporate and enforce such policies, but they can also be applied without tooling.

Collectively, if measures are taken to select and monitor open source components sensibly, there is no reason that open source should be considered any less secure of an option than commercial. That doesn’t mean open source components are completely secure, but they can be used with same level of security risk as any other products. Choose wisely, monitor responsibly, and welcome open source into software development projects.