Many organizations have begun to adopt a “risk rating” as part of their open source software compliance and usage discussion. Some of the information gathering requirements to assess risk will be relatively easy to meet, while others require much more effort. There are many factors to consider when assessing risk and as you decide which factors are important to your organization you will need to examine the size of the time investment needed to research and obtain the information associated with each factor.
In this article I will provide a list of some of the more common factors to consider when assessing risk and the questions you should be asking yourself and others. I will also briefly touch on the topic of building a risk profile as part of the OSS acquisition process.
Let’s start with some key product factors to consider:
Don’t just limit this to the actual maturity of the product but also consider how extensive the internal experience your team has with the product. For example, your developers may have been involved early on in the development of an OSS project, however while the product itself may be relatively immature, your team may have a great deal of production deployment success, indicating a stable, reliable product.
It is relatively easy to research the National Vulnerability Database for known security vulnerabilities and I have included some additional references for you to explore that we use in our Open Source Software Certification Process when considering security issues related to OSS:
Product Infrastructure and Community Activity
• Who developed it?
• Is it a one-off project with few developers or is backed by an established community or commercial organization?
• How active is the development community and how often do they release fixes and stable versions?
Most “mature” OSS communities release new major versions of their software 2-4 times a year with the possibility of additional minor releases and patches in the interim.
• Is there commercial training, support, warranty and indemnification available?
• Does the community offer discussion groups, forums, mailing lists for support and discussion of product issues?
• What is the level of activity in those groups?
Most OSS projects contain discussion groups, but often there is little or no response to developer queries in smaller projects.
In your risk model products like mail servers, application servers, etc. may carry more risk than small utilities like data compression programs. To assess risk in this area consider using or developing an application categorization system.
• Where do your developers acquire the software?
• Does it come directly from a community/website or does it come from a commercial vendor?
• Do you have an internal list of approved and vetted OSS products stored in an internal repository?
• Are downloads from external repository’s approved or denied?
Next let’s consider Legal and Compliance factors
You may have a good understanding of generic OSS license types like permissive attribution or copyleft licenses. But, if you haven’t already, take the time to develop a list of approved licenses, compliance factors, license compliance concerns and approved usage scenarios. You may also want to develop or adopt a definition of open source for internal use. The Open Source Initiative has an excellent definition of the term open source http://www.opensource.org/docs/osd. But you may want this risk category to extend to all free software, including closed and open source freeware.
At a minimum you should consider three factors in this area:
1. Consider the actual usage of the OSS project as it relates to license obligations. For example are you modifying the source or linking to it with proprietary applications? Each license has its own set of “triggers” that indicate when you have to meet certain obligations.
2. Consider the type of deployment. Is it “mission critical?” What are the ramifications on internal and external customers if the application fails?
3. Consider the location of deployment, i.e. where the code is installed. For internal and SaaS applications, it may only be installed on your organizations systems. However, internal is taking on a different meaning today with broader use of cloud technology.
Consider legal activity associated both with the license and product and consider related factors like industry segment or product application. Copyleft licenses, like GPL and LGPL generally have had more documented cases of legal and compliance issues than permissive licenses like BSD or MIT. Be sure to research the actual product for any known legal activity.
Here are a few sites we use to do this type of research:
And, finally consider the OSS application industry segment as it relates to issues like known patent trolling activity. Certain industry specific projects that are implemented in open source such as mobile technology and audio and television have a tendency to use more patented technology.
As you develop your own risk profile you will want to take these and associated factors into consideration to build a process and rating system.