What is our primary use case?
Our use cases are for handling incoming open-source software for high speed or agile development that our teams are doing. We also use it for looking at security vulnerabilities in real-time as they're doing their daily builds. It helps to compile distribution acknowledgments or the open-source acknowledgments that need to go out with any distributions.
How has it helped my organization?
Although it's a little too early for any metrics or data, it has improved my organization through its ability to apply legal and security policies in an automated fashion to a very large volume of open-source components. All of its associate transitive dependencies are invaluable and alleviate so many legal resources to work on higher risk or higher-profile issues that need guidance.
FOSSA absolutely provides contextualized actionable intelligence that alerts us to compliance issues.
The user interface is incredibly straightforward and the communication that's provided to the developers or the project managers and legal team is clear and concise and allows either an attorney, a developer or a manager to take a look at their project and see where the security vulnerability and licensing issues come from. You can quickly identify the source of those issues, verify whether or not that is an accurate determination by the tool, and then either as a manager or attorney, provide feedback to that team on how to remediate the concern.
It helps with triage and remediation. The data provided makes it really easy and effective to determine the source of the license or security concern. And because it's easy to identify where that's coming from, it makes it very straightforward to provide remediation guidance to the development team.
What is most valuable?
The most valuable feature is definitely the ease and speed of integrating into build pipelines, like a Jenkins pipeline or something along those lines. The ease of a new development team coming on board and integrating FOSSA with a new project, or even an existing project, can be done so quickly that it's invaluable and it's easy to ask the developers to use a tool like this. Those developers greatly value the very quick feedback they get on any licensing or security vulnerability issues.
The out-of-the-box legal policies are very good but I think that they lack thoroughness of some of the unclassified licenses. The accuracy was good, I don't think I had to make any major changes. I would only have to make changes if I were a risk-averse or an incredibly risk-tolerant company. But if you're middle of the road, the out-of-the-box legal policies are pretty acceptable. It probably just needs to classify more of the unclassified licenses in one of the three categories for disposition to get a better starting point for new companies adopting the out-of-the-box policies.
We use the security vulnerability management features. I give the developers a heads up that there might be some published vulnerabilities that they might be unaware of. It's good because it gives them really quick feedback, so if they're doing a nightly build they'd get feedback the next day, or if they're building it right away they might get near-immediate feedback. But we don't have any enforced policies regarding security vulnerabilities, especially for internal or hosted applications.
The background and information these features provide on security workflows is just integration to the national vulnerability database, so it's limited to the data that's contained in the NVD, which of course is standard industry-accepted vulnerability data. There's definitely room for growth there and actually doing analysis of the proprietary code, but looking at the NVD information as a baseline is certainly useful.
In terms of the compatibility with a wide range of developer ecosystem tools, the interoperability with different developer ecosystems is excellent, and that's actually one of the reasons we chose FOSSA as our enterprise solution. Even if they didn't have out-of-the-box compatibility with a certain build environment or a build pipeline, they were able to get it working with one of them or any of the new environments very quickly. It definitely has industry-leading interoperability for different build environments, which is really valuable to us.
This affects our open-source management operations by allowing for a much greater deal of efficiency. As part of the legal team, having to look at an incredibly large volume of open-source components coming into the company, it was immensely time-consuming and it took away attorney's resources from more mission-critical or more complex responsibilities, such as embedded software or any software being distributed outside of the company. Having it as a resource to very quickly triage incredibly high volumes of open-source coming into the company through agile development programs was invaluable.
It is holistic and helps us work with both legal teams and DevOps. It's a great way to help legal and development teams work together by automating a lot of the guidance that gets provided in the more straightforward scenarios like internal development or projects that aren't externally distributed. It's a great resource for having a centralized place for all of the outstanding issues to provide automated, legal, and security guidance to those development teams.
My team is purely legal, but I would say that there's definitely a lot less person power required to address any license concerns as the majority of license questions are resolved in an automated fashion by us populating the license policies in the tool as completely as possible. So the more completely we populate those license policies, the more of that work is offloaded to the tool from my legal team, which is excellent for making more available time where it's more valuably used.
It has decreased the time our staff spends on troubleshooting by 10 to 20 hours per week where an attorney could have that time then reallocated to something more important.
What needs improvement?
We have seen some inaccuracies or incompleteness with the distribution acknowledgments for an application, so there's certainly some room for improvement there. Another big feature that's missing that should be introduced is snippet matching, meaning, not just matching an entire component, but matching a snippet of code that had been for another project and put in different files that one of our developers may have created. A snippet matching is important as well and something that should be included soon. Those are the two big improvements that should be implemented.
For how long have I used the solution?
I have been using FOSSA for just under a year.
What do I think about the stability of the solution?
So far there have not been stability issues, so the stability is very good.
What do I think about the scalability of the solution?
It's definitely scalable although there's definitely some room for improvement when it comes to supporting an enterprise with thousands or tens of thousands of projects. There's a lot of room for improvement developing a bit more detail in groups and teams and being able to filter the projects that have been scanned on the home landing page. But it definitely supports a very large number of teams and projects.
There is a wide range of users who use this solution, including developers, attorneys, security experts, project managers, and just general managers who all have access and look at some of the outputs of the tool.
We're still somewhat early in the rollout being just under a year for being a very large enterprise so the number of projects we've used it for is in the range of a few hundred. For our company, the expected number of projects will be well in excess of probably 10,000 maybe even 20,000.
We definitely intend to increase usage. The adoption rate across the company is 5%.
How are customer service and technical support?
The support has always been excellent. They communicate in many different ways, be it Slack, email, or on the phone, and they're always able to help us.
How was the initial setup?
The setup process was very straightforward. It was mostly the complexities of our own internal enterprise software policies and data privacy policies that made the implementation a little bit more challenging, but in no way was that FOSSA's responsibility or fault. That were our own internal policies that were relatively strict. But otherwise, I found the deployment in a containerized environment be very fast. It took around one to two months.
We had a three-phase approach for rolling out FOSSA inside of the company. The first one was to bring on the team that was helping us early on throughout the proof of concept stage with FOSSA and some other competitors. Because they were already familiar with it, it was easy to bring them onboard into our newly provisioned FOSSA environment. They already knew what they were familiar with and could provide us immediate feedback if something didn't seem to be working properly. They were development teams at the company that had been doing some POC work with us with FOSSA.
Then phase two was bringing on leaders around the company in different development languages. They may not have been familiar with FOSSA, but they were very competent developers in their respective languages and environments. Bringing them on was phase two. And then phase three was the larger enterprise rollout where anyone who wanted to leverage the tool was welcome.
What was our ROI?
It's still too early to tell for ROI.
What's my experience with pricing, setup cost, and licensing?
Pricing is competitive with some of the other bigger companies, but probably overall middle of the road.
We haven't encountered additional costs.
Which other solutions did I evaluate?
We also evaluated Black Duck as well as Flexera. The biggest pros for FOSSA was the interoperability with different development environments. Being able to support a very wide range of development environments, including older ones, was very important to us as a very large enterprise. We have an incredibly diverse range of build environments, build pipelines, development environments, IEs, all of those things, so having something that supports nearly everything that we had internally was incredibly important. It was also a cheaper alternative. Not cheap necessarily, but it is a more affordable alternative to some of the other solutions out there.
What other advice do I have?
With the rapid growth of the consumption of open-source in development, it was no longer feasible for attorneys to manually review every incoming component on an individual case by case basis. Having a tool to automate the review, both from a legal, but also a security perspective, and provide near-immediate feedback to the developer was critical to have.
My advice would be that if you have a very large volume of open-source that you can apply clear and consistent policies to or you currently do that in a manual process, that something like this is absolutely worth every dollar to be able to keep your teams moving quickly and efficiently. Implementing something like this is definitely worthwhile if someone is on the fence with respect to spending the money to look at the open-source components, both from a license and security perspective in a fast and efficient manner.
The biggest lesson I learned from this solution is that there's a much larger volume of open-source components that might be in your environment that you may not be aware of given the comprehensiveness of FOSSA's scanning of both top-level components and transitive dependencies. You'll learn that there's an incredibly large number of components in your applications.
I would rate it an eight out of ten.
Which deployment model are you using for this solution?