FOSSA Reviews

We are using it to identify licensing issues in open-source software. It is a SaaS offering.

I am an attorney. So, I don't use the front end of the product. I don't manage, model, or measure it.

It reduced the duration and the effort required to identify open-source licensing issues.

It provides contextualized and actionable intelligence that alerts us to licensing issues. I work with licensing issue alerts, and I receive an email that directs me back to the licensing issue in FOSSA.

It provides help to triage or remediate a licensing issue. It identifies the licensing issue and the software involved.

Policies and identification of open-source licensing issues are the most valuable features. It reduces the time needed to identify open-source software licensing issues.

It is holistic in terms of collaboration between the legal teams and DevOps. I'm legal, and I work with DevOps. It identifies licensing issues in DevOps projects that legal can review.

For open-source management, FOSSA's out-of-the-box policy engine is easy to use, but the list of licenses is not as complete as we would like it to be. They should add more open-source licenses to the selection.

They should also reduce the number of false-positive identifications.

I have been using this solution for one year.

It seems stable. It is there when I go to access it.

It meets the needs of our organization. I'm an attorney, and I know that developers use it, but I don't know how many developers use it.

I have used their technical support, and they've resolved any issues that I've identified. They do a good job.

We used a different solution. The decision to switch was made before I arrived.

The marketing material that they have is adequate for explaining the product. 

We are not using FOSSA for security or vulnerability management.

I would rate FOSSA an eight out of 10. It works.

We use it to scan all of our open source projects, including all of our internal projects that people use.

We are about to roll it out to the whole company. Currently, we're only using it for open source projects, making sure people are scanning before they get the project approved.

FOSSA's compatibility with the wide range of developer ecosystem tools is great. It definitely saves us a lot of time and helps us figure out what security vulnerabilities are going on. Since we can't do it ourselves, we need FOSSA.

The solution provides contextualized, actionable intelligence that alerts us to compliance issues. The intelligence provides help with triage and remediation. The solution reacts really quickly to triage every question or anything going on that needs help.

It cuts the software engineers work a lot. Because if it is already approved and scanned, then they don't have to do it again. 

The solution is holistic. Our legal teams and DevOps work hand in hand with it. For example, we have a legal team who is part of the setup for FOSSA. 

I would like more customized categories because our company is so big. This is doable for them. They are still in the stages of trying to figure this out since we are one of their biggest companies that they support. I do feel like we are being heard and they are working on trying to give us what we asked for.

I have been using it for two years.

FOSSA has been pretty stable. There haven't been websites down, etc. We are still building on top of it, which is great. We are adding more features which we didn't know that we needed. We are still getting feedback from developers at the company on what they need and what the solution can do for them.

My team of two does the maintenance for FOSSA.

The scalability has been pretty perfect.

The majority of the user roles are software engineers. We have about 3,000 to 4,000 software engineers who will be using it. Currently, I think we have about 1,000 employees who probably have used it, or maybe a little less. We are about to roll it out to the whole company, so that will be hitting the majority of all our engineers.

Right now, it's already in the system. We just haven't yet announced that it is in the system for use. 

FOSSA enables us to deploy software at scale.

The technical support is really good. They are very persistent and support what we need by answering all of our questions. They answer right away. 

We did not use another solution previously.

The initial setup was straightforward. It was very easy in order to have their platform installed into our company-wide platform for internal users. They gave us what they needed, and we gave them what they needed.

Our deployment took about a week.

For our implementation strategy, we had to figure out what was needed in order for FOSSA to be on our platform along with the needs to onboard an external platform into our system.

The deployment required three or four people: the IT team, the FOSSA team. and myself. My experience with the FOSSA team with great. The deployment went smoothly. They were there for 100 percent life support. Anything that was needed was found and triaged.

It takes probably a week to get everything scanned and approved before you can use it. Therefore, we are probably seeing about a couple of days or weeks of times saving per code or project for this solution. This is because it would take some time to scan, have it looked at, reviewed, and get approval.

It improves productivity, saving a lot of time for our software developers. 

If this is the type of product that you're looking for, they are one of the best products that you can use. The support team has just been amazing, and it helps us to have a great support team from FOSSA. They are there to triage and answer all our questions which come up by using their product.

I am not a daily user. I do more of the program management side of setting it up for everyone. I don't actually use it on a day-to-day type of basis.

I would rate the solution a 10 out of 10.

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.

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.

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.

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. 

I have been using FOSSA for just under a year. 

So far there have not been stability issues, so the stability is very good.

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%.

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.

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.

It's still too early to tell for ROI.

Pricing is competitive with some of the other bigger companies, but probably overall middle of the road.

We haven't encountered additional costs.

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.

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. 

Our major use case is to do open source license compliance. Puppet Enterprise consists of about 90 open source packages under constant development. And it also has some components which are not open source. When we release Puppet Enterprise, we have to make sure that anything that we're relying on is something that we are allowed to use, in an open source sense.

It does do security scanning, which is something that we're interested in and want to do, but we've only been using FOSSA casually for that.

I am the only person really running the FOSSA jobs. I have a FOSSA job that runs daily, that scans all of our important repositories and reports back to me and the release engineering team about what it found. When we go to do a release, we run a report from FOSSA which contains all of the open source licenses in our product and we do a rescan of that to make sure that there aren't any flagged licenses inside of our product. That's our use case.

None of the actual engineers are worried about it. Only when something gets flagged do I contact them and say, "Hey, this license isn't working for us, so we need to find something else."

FOSSA is a cloud project and it contains a CLI component that's open source.

What we don't want to do is publish our closed source stuff under GPLv3, so we need to make sure we're not using any GPLv3 inside of our product. FOSSA does a good job of showing us if we're using licenses from the open source world that conflict with our needs for our closed source components.

Prior to a Puppet Enterprise release, it would take approximately two to three weeks of dedicated engineering time by a single release engineer to go through license compliance. We just did a release in late July or early August, and with FOSSA our license compliance review took five to ten minutes. That is an enormous difference. It has helped to decrease the time that we spend on troubleshooting by huge amounts.

What I really need from FOSSA—and it does a really good job of this—is to flag me when there are particular open source licenses that cause me or our legal department concern. It points out where a particular issue is, where it comes from, and the chain that brought it in, which is the most important part to me. Because there's a chain of dependencies, it's hard to find fourth- and fifth-level dependencies inside that chain, and FOSSA does a really good job finding that stuff and reporting how it got there.

That intelligence provides help with triage and remediation, in a sense. That is, the triage and the remediation on this stuff is to just not use that stuff. With the licensing it just says, "Hey, there's a license here that you might be concerned with." And from there, the remediation is to not use that particular package.

The most valuable part is the open source license compliance.

The solution’s out-of-the-box policy engine's ease of use is very high. It works extremely well. That's easy to quantify. Its accuracy seems really good, but I have not diligently measured it. When we have checked what it is doing, it has all come out great. We're extremely happy with the results, but I can't say that it is an accurate product.

The solution’s compatibility with developer ecosystem tools is pretty good. There is some stuff within the C++ world that we haven't been able to get it to work very well with, but that's a really small amount of what we do. Most of our stuff is in Clojure and in Ruby and all the things that we want FOSSA to do there are great. It's not like we have a wide scope of developers who are using it. I'm effectively the only person actually using FOSSA. I just gather up all the information and all the repos from all the other parts of the company and run scans on them daily. I'm the major customer here.

I would like the FOSSA API to be broader. I would like not to have to interact with the GUI at all, to do the work that I want to do. I would like them to do API-first development, rather than a focus on the GUI.

There were also some reporting things that I thought could be better. I talked to FOSSA about this. A lot of times when they were reporting, their labels did not match. Classically, there hadn't been a way to get well labeled output. It was just in HTML or PDF or CSV. They put out a JSON version of things that is certainly helpful. So that part's fine.

I have been using FOSSA for about eight months.

Any stability issues I have found were from things I did. I've had some chats with FOSSA about it, and we've talked about what could be some gray areas between me and them, but I haven't had time to investigate. So I'm not going to blame FOSSA for any stability issues at the moment. I think most of them have been on me, and there haven't been that many.

What I've got at the moment are some scans that slap on a fairly regular basis and I don't know why yet. It looks like it's something to do with the way that I'm doing scans rather than anything that is on the FOSSA side.

I haven't measured the scalability. It just does its thing. I don't think I'm taxing it in the least bit. But I haven't seen any limitations at all on the Fossa side. None.

It's doing the one task that we bought it for, and it's doing it quite well. I would like to expand the use into the vulnerability scanning part, but that's not my department. But it is doing precisely the job that I want it to do and I'm quite happy with it. I don't plan on changing much with it right now.

My experience with their technical support has really been quite good. There have been times where things have languished in the support queue for a little while before they got to them, but that's been the outlying stuff, most of the time. I've had direct access both to my account rep and to the engineering folks there, and we've had some really good conversations over time. So I'm really pleased.

Prior to using FOSSA, we didn't have any other tool in place for license scanning. We came to the realization that we needed a tool like this for open source management because none of the engineers who had to do the two weeks of manual license review work wanted to be doing it. We all hated it. So if there was a tool to take care of it, we were all saying, "Yes, let's get that."

The initial setup was extremely straightforward: sign in to the GUI and download the CLI. I did have to write some shell scripts to do the daily scan, but that was on me. I just wanted to do it my way.

From licensing it until bringing it into production on a day-to-day basis, it took about a day and a half. I got reviews of it by other engineers, but I was the one who was doing it.

I haven't done any calculations. I'm just glad that I have a tool to replace a bunch of manual drudgery.

For vulnerability scanning we're using JFrog Xray. We're using both FOSSA and JFrog Xray at the moment, and most of our production folks are relying on Xray.

Xray and FOSSA, in vulnerability scanning, approach the problem in two very different ways. We have some inertia over JFrog at the moment. People who have looked at the solutions, within our company, like both for different reasons.

There is a temptation to try to insert FOSSA into continuous integration. That was certainly my temptation. To me, that is more work than it ought to be. Sequestering FOSSA into its own job worked out better than trying to insert it into continuous integration. It does not need to be run into a continuous integration. It's not something you need on every commit. That would be an overuse of the tool. Being able to do it as a side project keeps unnecessary failures from happening and it keeps a lot of other things, like unnecessary noise, from happening.

However, that's my use case for my particular setup. I can imagine other use cases where having it inside continuous integration would be useful. But for my use case, while that was my first temptation, that was an incorrect approach. Having it as a side job that stands on a schedule, rather than part of the continuous integration, was much more successful.

In terms of FOSSA's security and vulnerability management features, I am familiar with them. Our security team uses other tools for those needs at the moment. They've been stuck on them and it has mostly been inertia that has stopped us from changing to or adopting FOSSA more widely. In my opinion, there are some use cases inside of FOSSA, for the security aspect, which are better than our tools. But it is up to the security team to decide if they want to do it. There's been some poking at it over the months, but no serious migration, as of yet. Those parts of FOSSA could be used by us in future, but not at the moment.

As for the background and information the solution’s security/vulnerability management features provide on security workflows, it's basically CVE scanning, often before the CVEs get published. So whenever there is a security alert of some sort, it will publish whatever is known based upon all the ongoing, conflicting databases of security scans. It's a helpful "Hey, this bit of software that you're using is known to contain these particular vulnerabilities."

The reporting on security and vulnerabilities is pretty good. As I said, I've only used it casually, so I can't really say anything of great value. I haven't looked at it for a while. But I found the reporting, like all their reporting, to be quite clear, understandable, and straightforward. But my exposure to it isn't enough that I can't be more than vague.