Have you ever stared at the same lines of code for hours only to have a coworker identify a bug after just a quick glance? That’s the power of community! Open source software development is guided by the philosophy that a diverse community will produce higher quality code by allowing anyone to review and contribute. Individuals and large enterprises, like Microsoft, have embraced open source to engage people who can help make solutions better. However, not all open source projects are equivalent in quality or support. And, when it comes to security tools, many organizations hesitate to adopt open source. So how should you approach selecting and onboarding the right open source solutions for your organization? Why don’t we ask the community!
Earlier this year at the RSA 2020 Conference, I had the pleasure of sitting on the panel, Open Source: Promise, Perils, and the Path Ahead. Joining me were Inigo Merino, CEO of Cienaga Systems; Dr. Kelley Misata, CEO, Sightline Security; and Lenny Zeltser, CISO, Axonius. In addition to her role at Sightline Security, Kelley also serves as the President and Executive Director of the Open Information Security Foundation (OISF), which builds Suricata, an open source threat detection engine. Lenny created and maintains a Linux distribution called REMnux that organizations use for malware analysis. Ed Moyle, a Partner at SecurityCurve, served as the moderator. Today I’ll share our collective advice for selecting open source components and persuading organizations to approve them.
Which open source solutions are right for your project?
Nobody wants to reinvent the wheel—or should I say, Python—during a big project. You’ve got enough to do already! Often it makes sense to turn to pre-built open source components and libraries. They can save you countless hours, freeing up time to focus on the features that differentiate your product. But how should you decide when to opt for open source? When presented with numerous choices, how do you select the best open source solutions for your company and project? Here are some of the recommendations we discussed during the panel discussion.
- Do you have the right staff? A new environment can add complexity to your project. It helps if people on the team have familiarity with the tool or have time to learn it. If your team understands the code, you don’t have to wait for a fix from the community to address bugs. As Lenny said at the conference, “The advantage of open source is that you can get in there and see what’s going on. But if you are learning as you go, it may slow you down. It helps to have the knowledge and capability to support the environment.”
- Is the component widely adopted? If lots of developers are using the software, it’s more likely the code is stable. With more eyes on the code, problems get surfaced and resolved faster.
- How active is the community? Ideally, the library and components that you use will be maintained and enhanced for years after you deploy it, but there’s no guarantee—that’s also true for commercial options, by the way. An active community makes it more likely that the project will be supported. Check to see when the base was last updated. Confirm that members answer questions from users.
- Is there a long-term vision for the technology? Look for a published roadmap for the project. A roadmap will give you confidence that people are committed to supporting and enhancing the project. It will also help you decide if the open source project aligns with your product roadmap. “For us, a big signal is the roadmap. Does the community have a vision? Do they have a path to get there?” asked Kelley.
- Is there a commercial organization associated with the project? Another way to identify a project that is here for the long term is if there is a commercial interest associated with it. If a commercial company is providing funding or support to an open source project, it’s more likely that the support will continue even as community members change. Lenny told the audience, “If there is a commercial funding arm, that gives me peace of mind that the tool is less likely to just disappear.”
Getting legal (or executives or product owners) on board
Choosing the perfect open source solution for your project won’t help if you can’t persuade product owners, legal departments, or executives to approve it. Many organizations and individuals worry about the risks associated with using open source. They may wonder if legal issues will arise if they don’t use the software properly. If the software lacks support or includes security bugs will the component put the company at risk? The following tips can help you mitigate these concerns:
- Adopt change management methodologies: Organizational change is hard because the unknown feels riskier than the known. Leverage existing risk management structures to help your organization evaluate and adopt open source. Familiar processes will help others become more comfortable with new tools. As Inigo said, “Recent research shows that in order to get change through, you need to reduce the perceived risk of adopting said change. To lower those barriers, leverage what the organization already has in terms of governance to transform this visceral fear of the unknown into something that is known and can be managed through existing processes.”
- Implement component lifecycle management: Develop a process to determine which components are acceptable for people in your organization to use. By testing components or doing static and dynamic analysis, you reduce the level of risk and can build more confidence with executives.
- Identify a champion: If someone in your organization is responsible for mitigating concerns with product owners and legal teams, it will speed up the process.
- Enlist help from the open source project: Many open source communities include people who can help you make the business case to your approvers. As Kelley said, “It’s also our job in the open source community to help have these conversations. We can’t just sit passively by and let the enterprise folks figure it out. We need to evangelize our own message. There are many open source projects with people like Lenny and me who will help you make the case.”
Microsoft believes that the only way we can solve our biggest security challenges is to work together. Open source is one way to do that. Next time you look for an open source solution consider trying today’s tips to help you select the right tools and gain acceptance in your organization.
Learn more
Next month, I’ll follow up this post with more details on how to implement component lifecycle management at your organization.
In the meantime, explore some of Microsoft’s open source solutions, such as The Microsoft Graph Toolkit, DeepSpeed, misticpy, and Attack Surface Analyzer.
Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us at @MSFTSecurity for the latest news and updates on cybersecurity. Or reach out to me on LinkedIn or Twitter.
