During the RSA Conference, I hosted a Peer 2 Peer on how to manage your open source. The purpose of the session was to have a discussion about how the participants were securely managing the open source their organizations were using. It’s no secret these days that nearly every organization is using open source to solve their challenges. Everything from containers running infrastructure to developers leveraging existing code in applications to add complex features quickly. When we look at this from the security perspective though it creates some questions we have to ask. Where is this code coming from? Who is responsible for it? Can we trust what we’re running? While important questions, it’s not always clear how we can answer them. As expected, nobody had all the answers during the discussion, there were fantastic ideas, questions, and practices that came out of the discussion we did have.
I would break the discussion into three main themes: How do I know which projects are high quality? How do I manage which projects we should be using? And finally, how does open source licensing affect my risk?
The first topic, which projects are the best, hits on the idea that just like any other product and service on the market, the level of quality varies widely. There are some open source projects that are incredibly high quality. The Apache web server comes to mind here. There are also projects that see substantially less care and attention. Calling them low quality might be incorrect, but we can say they don’t have the level of maintenance other projects do. The conversation here revolved around paying attention to the open source project. It’s not enough to consume the open source. Ideally you get involved, but at a minimum you need to pay attention. Projects without recent updates, public discussions, or security flaws should be viewed with a skeptical eye. The healthiest open source projects have steady code commits, they have plenty of public discussion, and most importantly they own up to their security problems. For example, no security updates isn’t a good thing, it’s actually very very bad because it means they’re not paying attention.
The second theme around managing the projects was a natural progression from the first. Once we identify which projects we could or should use, what do we do about it? A few of the attendees discussed some of their internal processes around how to approve certain projects for developer use. The mature organizations had a process setup where the security teams would understand then track the open source projects that their internal staff was using. The basic idea is that rather than let staff pull down whatever they want there is a process to decide which applications and libraries meet some sort of internal metric. This also made the job of the security team easier as when it’s time to track security flaws in products and services, they know what’s running in the infrastructure and products.
The third theme centered around open source licenses. I must admit I didn’t expect this topic to come up, it was a very common issue some years back when open source was new to many. The topic died down once open source was more widely adopted. I suspect now that we have whole new groups investigating open source it will become more popular than ever. The basic problem is that all open source projects come with some sort of license. Some of these licenses place requirements on the organizations using the source code. For example, the GPL requires you make source code changes public, other licenses such as BSD do not. It’s of course substantially more complex than this (books have been written on this subject, we won’t cover it here, perhaps a dedicated session next year could make sense). The important message wasn’t about various licensing requirements though, the message was about open source licensing needs to be a part of your security team’s risk model. It would be foolish to try to ban using open source because of potential license risks. Open source is here to stay, you can’t stop it any more than you can stop the tide. The correct solution here is to spend some time understanding what a particular license will mean for your organization. Some licenses have strict requirements, some licenses are even incompatible and the software cannot be used together. Some licenses are just plain silly on purpose. It is up to us as security professionals to have a basic understanding about these matters and work with other internal groups to fully understand how open source licenses fit into our risk models and adoption standards.
Overall I was extremely pleased with the P2P session. I didn’t do most of the talking which I consider a success. It’s an immense pleasure when a topic you weren’t expecting comes up and creates fascinating discussion. One of the best parts of participating in a P2P discussion is everyone is an expert at something. Just because one person has a more mature management model doesn’t mean they’re an expert at licensing. Everyone contributed to the discussion, and I feel like everyone learned something.