FOSSA Review

Embedded within the software development lifecycle as close to the introduction of dependencies as possible


What is our primary use case?

FOSSA provides a command line interface tool, and we always use the latest version of that. It gets pulled down automatically by some scripts that I've written, so we will always pull down its latest version.

We're using it primarily for the free, open source license compliance portion of it. Those scripts that I've built have the ability to be able to fail builds on pull request checks, though we haven't started enforcing that yet. Therefore, we're really primarily using FOSSA as a dependency inventory tool, then our legal team can also review and give feedback to the teams about the licenses that they're using. In the future though, we are planning on leveraging FOSSA for that policy enforcement piece as well.

How has it helped my organization?

It lets legal sleep at night. We have been acquired by a parent company who has a much stricter policy around free, open source dependencies. The fact that we already had FOSSA in place, which had that inventory of the 13,000 dependencies, has drastically eased the discussions that we've needed to have with them. This is sort of tangential, but the reason why they're so much stricter than us is because they are traditionally not a SaaS-based company. Their software tends to be installed on-prem, which means that the free, open source license compliance piece becomes a much touchier subject for them.

Any license type that is not categorized in either a denial, review, or approval state. This also ends up bringing up an alert that says, "Someone's using an uncategorized license. Should we add this to the approved or denial list?" I believe that those get applied across the entire organization. This functionality helps us identify the violations, then legal can come in and review as to whether or not there's action that needs to be taken. Recently, I've seen some back and forth between our legal team and FOSSA about improving this functionality.

FOSSA helps the legal team interact and communicate with the engineering teams who are introducing the dependencies, which is all part of DevOps. In the context of DevOps, it absolutely helps in their communications with legal.

What is most valuable?

It is a combination of both features and the perspective that FOSSA tries to take, which is sort of different than a lot of their competitors. The main feature and perspective that they take is their desire to be embedded within the software development lifecycle as close to the introduction of dependencies as possible. That has allowed us to build these checks and FOSSA execution into the pull request checks that run automatically whenever an engineer opens a pull request to introduce new code changes into a code base.

The solution’s compatibility with a wide range of developer ecosystem tools is incredibly easy to use. I've written a handful of scripts to even ease that process even more. It is at the point where, in order for one of our teams to integrate FOSSA into their development process, it requires them to add essentially two commands to their pull requests check pipeline. That builds in a bit more functionality than the FOSSA command line tool provides out-of-the-box. However, just executing FOSSA can be achieved by adding a single line to a continuous integration pipeline. With all of the various platforms that you can use to build your project, FOSSA is incredibly easy to integrate.

Their CLI tool is very efficient. It does not send your source code over to their servers. It just does fingerprinting. It is also very easy to integrate into software development practices.

What needs improvement?

On the legal and policy sides, there is some room for improvement. I know that our legal team has raised complaints about having to approve the same dependency multiple times, as opposed to having them it across the entire organization. I believe that our legal team is working with FOSSA on improving those things. FOSSA is very open to our suggestions, requests, etc.

For how long have I used the solution?

We have had FOSSA for probably two to three years at this point. When we picked up FOSSA, they had only been on the market for roughly a year.

What do I think about the stability of the solution?

There are times, and this is true of any SaaS offering, where they experienced transient issues every now and then. Occasionally, I'll get a team, saying, "My pull request check failed and it's coming up with FOSSA saying that it timed out," or that they're getting a 500 response. I tell them to wait an hour and try again, then I usually don't hear back from them. I would say that it's as stable as any SaaS offering that I can imagine out there. If I was to go and check their API status page, I think I would end up seeing at least 99 percent across the board on their services.

We have had minor downtimes here and there that have been less than a day.

They are just now releasing version 2 of their command line tool. That is the first major update that they have released for the CLI tool.

For maintenance, there's just me from the technical side, and at most, two people on the legal side. I have to add an API key to a CI pipeline when someone new wants to integrate with FOSSA. I don't even know if that would equate to one percent of my responsibilities. We are constantly looking to improve. Therefore, we are actually looking at ways that I wouldn't need to do that. That literally the entire process would just be running that CLI command to generate the configuration file, add that configuration file to GitHub, and add these two commands to your pipeline, then everything should just work. That's in the future, but my responsibilities may even diminish even more.

What do I think about the scalability of the solution?

We have almost 200 projects currently using FOSSA. Those are all built into the pull request checks, and we are planning on extending their use, potentially even up into our parent company as well. I rarely get complaints from teams that their pull request checks are being held up or anything like that. They seem to scale at whatever size we need them to.

The solution enables us to deploy software at scale as a global company. We have probably a few thousand nodes hosting our software in AWS and our private data center. We would not be able to confidently be able to deploy all of this stuff without knowing that we were compliant with these licenses.

The largest set of users is engineering. The teams want to be able to get in there so they can see the results of the submissions, and whether or not they have any alerts that they need to talk to legal about. The next largest, which is a funny word to use for this because there are only two of them, would be the legal team, then there is myself from security. It's going to be interesting to see what users in our parent company want to be involved as well, because I know that they actually have a dedicated intellectual property group.

How are customer service and technical support?

The technical support is fantastic. I have waited, at most, five days for them to fix bugs that we've identified in the CLI tool. They are knowledgeable, can escalate properly, and their turnaround time is excellent.

Their CLI tool is also open source. I have actually had some of our engineers submit pull requests to them to fix bugs that they've not only identified, but figured out a fix for. They are open to merging outside pull requests as well.

Which solution did I use previously and why did I switch?

A lot of competitors that we had tried prior to FOSSA seemed to want to be more of an audit tool, which gets run at the end of a release. Unfortunately, at that point, there is no flexibility or time to correct a policy violation. You're already at code freeze. The team has already validated and tested the build. Now, all of a sudden, you're going to tell them that they have to go in and tear out a dependency. There's no way that you would be able to do that within the timeframe of a release. Whereas, FOSSA wants to come in as soon as that dependency gets introduced. This reduces the amount of work and everything that would need to be done in order to replace that dependency with something else.

Prior to me getting involved with this whole effort, we had been using Black Duck. I believe it was very expensive and we were never able to get it to function the way that we wanted it to. 

When I came onboard and started looking at stuff, we were using a provider called WhiteSource who was not able to fill that pull request check feature that I really wanted because it was slightly tangential. However, I came from an engineering background before coming over to security with about 15 years of software engineering, so I had a very opinionated view of where these checks should be happening. WhiteSource just flat out could not support the use case that I had.

We purchased and tried to use Black Duck before bringing on WhiteSource. I'm not sure how long we had Black Duck floating around for, since that actually predated me. However, I tried to work with WhiteSource for a year in order to try get their offering into the process and add the stuff that I wanted to do. We were completely unable to do it.

How was the initial setup?

The initial setup was straightforward. They made it so easy to run and submit a build to their platform. In order to set up a configuration file, it's running one command out of the CLI tool, then submitting it; you run a build and do all the fingerprinting, then submitting all that data up to the FOSSA platform is just one more command with the CLI tool. They streamlined everything behind the scenes for us.

We are still rolling it out to teams who have not adopted FOSSA, e.g., if we have a new project, then we ask them to set up FOSSA for their project. I literally tell them that it's less than an hour's worth of work. If your guy is working, and he's telling you that setting up FOSSA is taking longer than an hour, you should probably have him come talk to me, because he's doing something wrong. When people start pushing back, and they're like, "Oh, we don't have time to put FOSSA in." I'm like, "It takes less than an hour. You have time to put FOSSA in."

We are going to need to reevaluate our implementation strategy as we work more with our parent company. Now that we have exposed them to FOSSA and the way that we've been using it, they're interested in adopting FOSSA themselves, and they are a far larger organization than us. 

What about the implementation team?

I was part of the PoC, initial setup, and everything since then.

What was our ROI?

It is not a moneymaker. It's more of a compliance tool. It helps legal sleep at night, so to the extent that our legal team is better rested, we've seen return on investment.

There is no way that we would be able to manage the volume of open source licenses that our organization uses without using a tool at least similar to FOSSA. Off the top of my head, we have somewhere around 13,000 unique dependencies identified in FOSSA today. That is with some projects not quite being properly configured as well. We expect that number will likely go up to 15,000. Just trying to maintain anything with that volume using a manual process is impossible.

What's my experience with pricing, setup cost, and licensing?

FOSSA is not cheap, but their offering is top notch.  It is very much a 'you get what you pay for' scenario.  Regardless of the price I highly recommend FOSSA.

Which other solutions did I evaluate?

I poked around at other options. Granted, this was two or three years ago. So, I only remember the guys who sort of stuck out in my mind, like SonarQube. 

Because we're also a SaaS company, it's good to eat at least some of your own dog food. We ended up going with the SaaS offering. This also means that there is less maintenance on our side, since the SaaS offering gets updated automatically. We don't have to worry about making sure that those nodes are up and running within our infrastructure, and our infrastructure guys don't have to worry about maintaining them.

I know that FOSSA would love if we did use the solution’s security/vulnerability management features, but the organization is going in a different direction. We're going to end up going with the GitHub Dependabot offering. This is mainly because all of our source code is already in GitHub, who has automated a lot of those checks, even the remediation. They have kind of automated the non-vulnerable already, and just keeping all of that information in one place is also beneficial rather than spreading it around multiple tools.

If FOSSA did the automated piece that GitHub has Dependabot doing where Dependabot identifies one of your dependencies as being vulnerable, then they will automatically open a pull request upgrade that package to a non-vulnerable version. If FOSSA can introduce something along those lines, then I would be more interested in their vulnerability and security management piece. The other thing I would say is that GitHub offers the Dependabot feature at no additional cost, which is also a very significant selling point that I think FOSSA would have a very hard time competing with.

What other advice do I have?

With my engineering background, I was supporting legal from the technical side of things in order to get the processes and checks embedded into the development process. The accuracy of the policies and checks was handled by the legal team.

I recommend taking a look at, or at least considering, the approach that I took, where I wrote some scripts to automate the steps within a continuous integration pipeline. We've actually open sourced the scripts that we used. They're on GitHub. While the FOSSA CLI tool is fantastic, there tends to be a bit more functionality that you need to build around it that's a little more specific for your organization, and scripting works well for that.

Biggest lesson learnt: There's a tool out there that does free, open source license compliance that wants to come in and be part of the software development life cycle early, i.e., as soon as the developer introduces a dependency. 

Before I found FOSSA, and after my experience with WhiteSource, I thought that I was going to have to write my own solution, which would have been a nightmare because I'm not a lawyer and don't know necessarily how to parse nor understand all these licensed languages. It was a huge undertaking, and I'm one person. Now, since I'm technically not on the engineering team, it's very difficult for me to get engineering resources beyond myself.

One of the features that FOSSA has on their roadmap is that they want to provide functionality before a developer ever introduces a dependency, so they can sign into FOSSA, run a search, and find out whether or not that dependency is going to violate policy. Just being able to move those checks earlier into the development process saves a ton of development work and time.

I would put FOSSA as a solid eight out of 10. Nothing is perfect. There is always room for improvement. However, they are a fantastic tool and an incredibly responsive organization.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Other
**Disclosure: IT Central Station contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
More FOSSA reviews from users
...who work at a Computer Software Company
...who compared it with Black Duck
Add a Comment
Guest