How UiPath Reduced Open Source Risk Through Team Collaboration

Open source is part of nearly every modern enterprise’s codebase. It’s collaborative, cost-effective, can help accelerate development, and much more.

But unless managed properly, open source also comes with some measure of risk, both in potential license compliance violations and security vulnerabilities. And it can be difficult for organizations that use a lot of open source to manage that risk when they address compliance and security issues on an ad hoc basis.

That’s why collaboration between all teams involved in software development — especially engineering, compliance, and security — is so important. FOSSA recently hosted a webinar on this topic with two leaders in open source management: Valentina Ditoiu, the Product Compliance Legal Lead at UiPath, and Valentin Lupu, UiPath’s Security Program Manager.

During the webinar, Valentina and Valentin shared how UiPath has aligned multiple teams around reducing open source risk and provided guidance to help your organization do the same. In this blog, we’ll highlight key insights from UiPath’s experts, with an emphasis on how compliance and security teams can work effectively with engineering teams. You can also watch our on-demand webinar to get more information on these topics by clicking the link below.

On-Demand Webinar: How to Efficiently Manage OSS Security and Compliance Across Teams

1. Develop Easy-to-Understand Compliance Policies

When drafting or refreshing an open source licensing policy, it’s helpful for compliance teams to try to use common language and make the policy as practical as possible. A wide range of non-legal teams may be impacted by your open source compliance policy, and it’s helpful if they’re able to easily comprehend its content.

“Often the legal team will take for granted legal concepts such as copyright or license or terms of use and think that other people have the same clear grasp,” says Valentina, UiPath’s Product Compliance Lead. “But understanding what people understand is the first step in creating a practical open source policy. You have to take the time to explain to your engineers what a license is, where to find it, and talk about tools and technologies that they use. Make the information apply to their day to day. Provide a step-by-step description of what they should do in case they want to open source a project, but again, make it tailored to your company and your practices.

“If your policy looks like legal analysis of licensing issues, then you probably should get together with your engineering team, listen to their feedback, and draft a more easily digestible version. A bad policy would not lead your engineering team to success, and that’s your role in compliance: to get them to deliver a safe product and one that makes you, the Legal Counsel, sleep well at night.”

2. Get Management Buy-In

Of course, implementing open source licensing and security policies isn’t possible unless all teams involved in open source are on board. While the need for a collaborative approach to managing open source risk may be clear to compliance and security teams, it usually can’t function properly without management buy-in. In developer-focused companies, this often isn’t a problem; management generally knows how valuable engineering time is, how important product ops teams are, and tends to be more mindful of the concept of open source risk.

If this is not the case, and management is not aware of having an open source compliance strategy, you have to let them know.

“Knowledge of risks that stem from not having a strategy is usually enough for management to give room to the security team and product ops teams to apply some effort to making this strategy work,” says Valentina, UiPath’s Product Compliance Lead. “Also, they will influence the engineering team toward collaborating with the compliance teams to a much greater extent. This is definitely something you want and need.”

3. Process Makes Perfect

Buy-in from all corners enables organizations to implement defined procedures that bring compliance and security policies to life. It might be possible for companies that use only a small amount of open source to address compliance and vulnerability issues without set processes. But the many organizations that depend heavily on open source will only be able to successfully reduce risk with a set of procedures that brings together compliance, security, and development.

It’s helpful to identify tools and people within your company that can play a role in executing these processes.

“We found that it was very valuable to have a unique point of contact in each development team,” says Valentin, UiPath’s Security Program Manager. “This helps us get things moving both from a legal and security perspective. It can be a huge help. It can also ensure that we are prioritizing properly and issues are fixed based on a specific assessment.

“Additionally, we often find ourselves in a situation of trying to understand the exploitability and risk potential of specific vulnerable libraries. In that regard, cooperation with the development team is valuable. They know the code best, so working with them is the best suitable scenario for understanding what we should do next.”

Then there is the tooling piece of the puzzle. UiPath uses a software composition analysis tool to quickly and easily identify compliance and security risks — and give all relevant teams strong visibility into those issues.

“Having an open source scanning tool that covers the majority of, if not all, the technologies your company works with makes communication easier between teams,” Valentina says.

4. Shift Left

The right tooling is only one part of understanding and reducing open source compliance and security risk. There’s also the matter of where in the software development cycle (SDLC) teams should use those tools.

Shifting left refers to the idea that it’s best to identify and fix issues as early as possible in the SDLC. In the context of open source license compliance and vulnerability management, this means teams should seek to conduct license compliance and vulnerability analysis integrated directly into existing engineering workflows and as a key component of the CI/CD pipeline. This is easily accomplished when using the proper scanning tool.

“We’ve seen that it’s a better experience at the CI/CD pipeline level than doing it as a git integration (the code level),” says Valentin, UiPath’s Security Program Manager. “This is true for various reasons, but mostly because there are multiple types of projects, different programming languages, different building processes, and so on. Understanding each specific build aspect for a project can take a lot of time.

“This can be overcome by integrating everything at the zero level. So, in that sense, leveraging FOSSA’s CLI was a huge help for us. It’s very versatile and reliable. It rarely fails. So it’s a huge help for us in achieving what’s needed.”

5. Enable Engineering to Make Fixes in Their Native Environments

Let’s say you’ve implemented clear policies governing open source license compliance and security, everyone in the company is on board with them, and you have the right tooling and people in place. There’s still one significant hurdle on your path to a fully collaborative open source program: determining how and where engineering will fix any security or compliance issues.

A best practice for this is to send anything that needs to be fixed to your developers’ preferred tools (such as Jira or Confluence).

“Making sure you’re in their world is super important,” Valentina says. “Engineers are not usually the ones to have discussions on email or have lengthy discussions over the phone. They just want the tasks to be tracked, so you have to make that effort to go in, raise the ticket, and do whatever is needed to help them prioritize the task and solve it. If you’re not helping them, they’re not going to help you.

“When actually raising the issues to the engineering team for fixing, you have to raise tickets in the tools you are using, and not where you as a legal person usually work. The security team generally uses the same ticketing platform as the rest of the product team by default, so this is not out of the ordinary for them, but the legal team has to adapt.”

Get More Open Source Management Insights

Register for our January 14 webinar, How to Efficiently Manage OSS Security and Compliance Across Teams, for more information on reducing risk in open source, including:

• How security teams can keep up with the rapidly evolving open source vulnerability landscape
• Specific workflows to successfully and efficiently remediate compliance and vulnerability issues
• How product ops teams fit into open source risk reduction

On-Demand Webinar: How to Efficiently Manage OSS Security and Compliance Across Teams