One of the sessions at the RSA Conference that drew my attention was Managing Open Source, with Red Hat Security Strategist Josh Bressers, who led an excellent round table discussion about different challenges and solutions people have implemented in their roles when managing open source at their companies.
One reason to attend events like the RSA Conference is to have discussions, and frankly, to listen to people - how they're tackling challenges, what works and doesn't at their company and in their role. It's a perspective that's important to understand, particularly when most of your perspective comes from conversations within your own company. Josh Bressers' session provided exactly what I needed to learn how different people are managing open source at their companies.
Licenses and Governance
Jeff mentioned that the Open Source Initiative recognizes 200 open source licenses; at Black Duck we track many more than 200, but our data shows that just eight licenses are used in the vast majority of projects. (This open source licensing data reflects analysis of over two million open source projects from over 9,000 global forges and repositories.) Understanding the different licenses and which one to use in a given situation make creating policies particularly important.
How do you decide what to include for your internal policies for open source software? One method a particpant used was to set up a white list of licenses so developers know what they can and cannot safely use. This organization created their own method for choosing which licenses to whitelist. They asked developers to submit the license to an Excel spreadsheet or database to be scanned, then a team decided whether to whitelist based on how the code was used, whether the code was modified, and the expected release environment.
Other participants mentioned that their boards recently started asking about a listing of the open source components in use in their code, while some mentioned that their legal teams had difficulty figuring out how handle the use of open source. The consensus was that open source is not going away, so they need to find better ways to track and choose open source licenses.
Choosing Open Source Components
The group discussion yielded some great recommendations on how to choose open source components for use in your environment:
- How stable is the development community around that component or library?
- Does that community care about security?
- How quickly do they fix vulnerabilities?
- How do they react when an issue is reported?
- How often do commits get made to the repository?
- How many people are making commits to the code?
All of these methods help developers choose good components, but there are a few other steps necessary. You can't just pull down libraries and keep them locally unless you're keeping them up to date — and if you update them, you need to check whether there's an impact to the custom code. Keeping components updated helps a lot with the governance issues but can be detrimental to usability. Why? Because many developers don't care if they break an API in open source — whereas developers in the enterprise avoid breaking APIs. This can cause conflict when keeping updated with components, because fixing one thing may easily break another.
Keeping up with Vulnerabilities
One example provided in the discussion was that in code review they found 84 different releases of Javaspring, with 82 versions in production. So simply knowing that you're using a particular open source component isn't enough, you need to know which release and version you're using and where. One participant said his company created repositories, so internal groups could download only approved code. This helped them to ensure that they knew their code, although some developers found it somewhat limiting. However, this control system can be critical when the typical project contains 100 subdependencies, all of which you need to be able to track.
Creating a staging server to test everything allowed another participant to perfect code before releasing it into a live environment. This helped to protect their live environment from downtime while also testing and securing code in an environment identical to the live one.
Containers and Continuous Integration & Development
Containers have the potential to resolve some of these issues - but of course you can't just build a container and leave it alone. Vulnerabilities can be disclosed at any time, so it's still necessary to know license and vulnerability data in any given container. Containers make it easier to deploy code, and if one breaks in live, it's easy to switch to a different container that you know works. Some members of the group felt that containers simplified code deployment in many ways, particularly in continuous integration and development environments.
Over 10k CVEs were reported last year, and that number is expected to grow for 2017 and beyond. That 10,000 CVEs a year averages 27 vulnerabilities per day, so expecting a container to remain secure after building it is not realistic. Knowing and maintaining your code applies to the code in containers, so a "set it and forget it" attitude simply won't work.
Takeaways on Managing Open Source
I found the discussion incredibly interesting, particularly because the participants ranged from the non-technical to the highly technical, and from people with litte idea how to even start managing their open source code to others who had clearly tested and developed plans to help manage and secure their code. I think this is indicative of the reality of companies today - there's a huge range, because nearly every company today is a software company in one way or another.
For example, banks have both internal and external software. Cell phones, thermostats, refrigerators, tractors - everything has software. The struggle to responsibly manage and secure your code is something that many folks are clearly thinking about, and I think that's going to continue. I'm looking forward to many more excellent sessions at RSA Conference; here's a link to our new DIY Guide to Open Source Vulnerability Management. Hope it's helpful as you explore managing your open source!