As General Counsel at Black Duck, I have the unique opportunity to speak with a large number of lawyers about open source software management and reuse. Over the years, these conversations have almost exclusively focused on the license compliance aspect of open source reuse management. Concerns around the so called “copyleft” implications of the General Public License (GPL) and interpretation questions, in general. Discussions concerning the approximately 2,300 or so other open source license have made license interpretation a regular topic of conversation. Without diminishing the importance of license compliance, it is absolutely critical to also consider all security threats associated with open source reuse.
Many lawyers, it seems, believe that their role in open source management is to act as “gatekeepers.”
Essentially many lawyers think their role is classifying the (copyright infringement) risk associated with the reuse of certain open source components based on the terms of the associated license and the intended use case. Typically, a piece of code licensed under a permissive license like the BDS or MIT will be given the “green light” for all uses, while components under more restrictive licenses like the GPL or AGPL will be flagged as requiring additional scrutiny. Following this exercise, it seems most lawyers don’t concern themselves further with respect to how and where the chosen open source components are being used thereafter.
Managing Open Source Security Risks
However, it is important that lawyers stay involved for the purposes of managing the security risks associated with open source reuse. Evaluating security risks must not only be an essential part of the “gatekeeping” function, but it must also be part of an organization’s ongoing management of the open source in use. Vulnerabilities are routinely discovered — and are often found to persist in components for years without ever being detected.
Accordingly, it is absolutely essential that the organization have a means of continually tracking what components are being used and have a means of comparing that up-to-date list against all known and newly discovered vulnerabilities in as close to real time as possible. Components that may appear clean one day may, in fact, be found to have previously undetected vulnerabilities.
Having a meaningful open source management policy in place that accounts for the continuous management and review of components, with specific procedures for implementing, executing and auditing that policy is critical. Lawyers should stay involved all the way through code shipment and beyond to make sure that procedures are being followed and that the ever-evolving risks are being adequately and continuously monitored and assessed. At the end of the day it is the lawyers who:
- Must make representations concerning the potential threats to the enterprise — to their managers, board of directors, customers, lenders, insurers, and the list goes on
- Will be on the front lines of defending claims made against the enterprise should a breach occur
Thinking beyond license compliance and deploying reasonable security vulnerability detection and remediation tools will go a long way in both preventing security breaches and allowing the company and management to convey a strong and complete story about their open source software risk management.
Read my white paper about what a general counsel needs to know about open source software to learn more show general counsels can help protect their companies from legal and financial ramifications of open source software security threats.
The post Why Talk About Open Source Software Management? appeared first on Open Source Delivers.