FOSSA Reviews

I have worked with FOSSA primarily to manage the dependencies in our projects. For example, if I take a Spring Boot application, FOSSA helps in identifying mismatches or unsupported dependencies that arise due to version updates of Java or Spring Boot. 

It provides suggestions for upgrading specific modules to maintain compatibility. The tool focuses on ensuring the versions of dependencies are in sync with the current versions of the application.

Overall, FOSSA serves as an add-on for our application. It ensures that our applications are updated with the latest features and enhancements. However, it does not function as a main security tool.

FOSSA suggests solutions for dependency mismatches. Similar to SonarQube, most of the suggested solutions work effectively. It helps to quickly identify and resolve dependency issues, saving us time in searching for solutions.

FOSSA does not show the exact line of code with vulnerabilities, which adds time to the process as we have to locate these manually. 

Some other tools like Check Point or SonarQube provide exact line numbers for bugs. Also, the process in FOSSA can be quite contradicting and not very straightforward for new users.

I have been working with FOSSA for about one and a half years since joining my current project.

FOSSA is stable as long as we have a valid token to access it. Tokens have expiration periods, and any server-side issues will cause tasks to fail in the pipeline, which stalls deployment.

While I have not personally faced scalability issues, our projects usually consist of five thousand to six thousand lines of code. Larger projects might require more consideration for scanning times.

I would rate FOSSA's technical support as eight out of ten. Occasionally, I experience issues with discrepancies in vulnerability display across different branches.

Positive

In my previous company, I worked with SonarQube before using FOSSA. FOSSA is more of an add-on tool rather than a direct substitute for Check Point or SonarQube.

For a newcomer, working with FOSSA was difficult due to the contradictory process. Some instructions were unclear, resulting in challenges understanding the given suggestions.

We have a dedicated team within our organization responsible for handling the deployment and implementation of FOSSA.

We primarily use SonarQube and Check Point for security vulnerabilities. These tools provide direct line numbers for issues, which FOSSA does not.

For those seeking to ensure their application is updated with the latest features, FOSSA can be a beneficial add-on. However, it should not replace your existing primary security solutions such as SonarQube or Check Point.

I'd rate the solution six out of ten.

FOSSA is a software composition analysis tool that can scan applications to determine their open-source components. The solution can be used for record-keeping, license compliance, vulnerability detection, and obsolescence management. In some cases, it is used for compliance because the federal government, PCI, and certain regulatory agencies require software bills of material.

FOSSA is easy to use and set up, provides relatively accurate results, and doesn't require armies of people to get value from its use.

If you have thousands of applications, organizing them all into teams or tags is challenging. There is a point where you start using FOSSA at a very large scale, and the user interface needs to adjust.

That's probably a challenge because the organizations using it are huge. It's not a problem if you use the tool for smaller use cases with hundreds of applications. When you get into the thousands of applications, managing through the user interface becomes a little hard.

I have been using FOSSA for four years.

The solution's technical support is excellent. I've had support questions, and they've answered them quickly.

Positive

The solution's initial setup is very straightforward. You can download and use the CLI. The number of people for the deployment depends on how complicated the deployment is. You can go to GitHub, download the open-source CLI, run it on your workstation against the build, and get results.

Making it work inside an enterprise workflow will be more complicated because you might have to coordinate with your pipeline team, depending on how complicated your work environment is. That's a factor of your complexity, not how complicated it is.

The solution is obviously beneficial, which is why we're using it. You definitely get benefits, which is why we're using it. However, we often use it because the cost of not using it is greater.

The solution's pricing is good and reasonable because you can literally use a lot of it for free. You have to pay for the features you need, which I think is fair. If you want to get value for free, you can do that. If you want things that aren't free, you pay for them. No one likes paying for these things, but that's what you must do if you want to use software instead.

Overall, I rate the solution ten out of ten.

In our current project, we are using FOSSA as part of our CI/CD pipeline. It is used to scan our projects to ensure that our dependencies are up to date and do not introduce vulnerabilities to our code.

Before using FOSSA, we could only identify issues after deployment in the Cloud Run. Now, with FOSSA, we identify dependency issues or vulnerabilities during the CI phase itself. 

This proactive approach has eliminated the need to search the internet for solutions, as FOSSA provides updated recommendations automatically. This has made the process more efficient and mitigated risks before deployment.

FOSSA allows us to keep track of all dependencies to ensure they are up to date and not causing any vulnerabilities. It also checks the licenses to see if they are current or expired. It helps us mitigate issues before they become problematic during deployment.

While running a FOSSA scan, it takes time for the results to reflect in the FOSSA UI portal. After running the command in IntelliJ or the CI pipeline, we need to refresh or reopen the project in the portal to see the latest report.

We have been using the FOSSA solution for over a year.

FOSSA is always up and running, with no reported downtown or stability issues. When I access the portal, it is responsive and reliable.

FOSSA scales well, maintaining performance and availability across multiple users and teams in our large organization.

We have a separate SRE team that handles any issues related to FOSSA. In case of problems, we contact them, and they resolve the issues during their office hours. The support process is smooth and efficient.

Positive

We have been using other solutions like Check Point and SonarQube for vulnerability management and software composition analysis.

There were no challenges reported by the SRE team during the onboarding phase. FOSSA was already implemented when I joined.

Deployment and setup are managed by our SRE team. They handle all technical requirements and ensure smooth operation.

If you need to automate the tracking of your application dependencies, vulnerabilities, and license expiry, then FOSSA is a good solution. It proactively identifies issues and breaks the CI flow if necessary, ensuring security without manual intervention.

I'd rate the solution eight out of ten.

I lead the legal team at my organization, and we use FOSSA largely in partnership with our engineering teams. We use FOSSA for open-source software licensing scans and diligence.

We are using its latest enterprise version.

It has reduced the time that we used to take to go through the internal review and the diligence of a build and then push that build to be live on production. It has not only reduced the time; it has also reduced some of the pain points to make us more operationally efficient. It has allowed us to scale up our engineering efforts in a way that enabled us to push multiple builds for different product features and create more agency for those teams. From a timeline perspective, we've had it for two years, and our baseline prior to that was very narrow, but it has significantly reduced the time taken for a more complex build with diligence reviews from maybe two or three weeks to almost instantaneously. Of course, the second component to the timeline reduction is that we also don't need to staff someone to conduct those reviews. They are automated through FOSSA.

Its actionable intelligence helps with triage. It doesn't do recommendations, but it highlights those issues so that I and my team can move them on very quickly and ultimately unblock those issues for our engineering teams. It doesn't make recommendations per se, as far as I know.

It contextualizes the specific license that maybe has an issue or that is approved or rejected in a package. It contextualizes that within the package and the other licenses that are in play. So, it allows us to isolate that portion of the package and make a decision if the license was rejected or flagged. It allows us to make the decision on the package to say, "This piece of it, do we need it or do we not?" We can then move forward.

I do find the license solution of FOSSA very holistic in terms of collaboration between the legal teams and DevOps. We don't use the security solution of FOSSA, so I can't speak to that, but I would agree wholeheartedly that it's a very holistic tool for both teams. It has enabled us to build out a process that removes some of the typical pain points between an R&D team and the legal team when it comes to third-party license scanning. One of the pain points is often timing and how long it takes to typically do these reviews manually. FOSSA does them near instantaneously. The second pain point is around isolating issues. I can't even imagine how long a manual review of a package would take, and fortunately, we haven't had to do that manually because FOSSA does that for us. From a relationship standpoint, it has removed some of such pain points between the legal and engineering teams to allow us to work faster and smarter and ultimately push new features and projects to production in a more efficient way.

It 1000% enables us to deploy software at scale. Our engineering teams are constantly working on new builds. They're scaling those builds out and upwards, but the legal team is fixed. So, we leverage technology like FOSSA to be able to scale up our legal operations, meet the engineering teams' needs, and keep track with them without having to bring in an additional FTE to manually do some of the work, which would be required if we didn't have FOSSA. It helps us reduce our costs, and it also reduces the timeline to better support the engineering teams.

It has absolutely decreased the time that our staff spends on troubleshooting. It is difficult to know how much time it has decreased because it has been so long since we've had FOSSA, and it is hard to remember those baselines. If I were to estimate based on the number of projects that we have in play from the engineering teams, it has reduced our demands on the team by probably 80 hours on a quarter by quarter basis, if not more.

Because of being on the legal side, I'm less familiar with its compatibility with the wide range of developer ecosystem tools, but our engineering teams use FOSSA for their builds and for pushing them out to production. So, from my understanding after many conversations with them, FOSSA makes it much easier and more efficient for them to make their builds and then ultimately get to the production phase.

FOSSA has a feature that allows you to automate the scanning of licenses. You can do that by setting up different policies that are custom-tailored for your organization, which in my case are legal policies or intellectual property policies. These policies are used to scan the open-source licenses and flag them, approve them, or reject them based on your company's preferences. One of the things that I really love about FOSSA is the way we can take what would manually require probably hundreds of hours of individual review and automate that through this platform.

In terms of ease of use and accuracy of its out-of-the-box policy engine, it is certainly very easy to use. It is also very accurate. There were some things that we custom-tailored based on our risk appetite and our internal policies related to intellectual property. The out-of-the-box policies were great, but we just slightly tailored them for what we needed for our use case. The majority did not need tailoring, and across the board, all of the policies that were out of the box were consistent with the decisions that I would have made in the absence of internal policies that I had to be mindful of.

One of the things that I really like about FOSSA is that it allows you to go very granular. For example, if there's a package that's been flagged because it's subject to a license that may be conflicts with or raises a concern with one of the policies that I've set, then FOSSA enables you to go really granular into that package to see which aspects of the package are subject to which licenses. We can ultimately determine with our engineering teams if we really need this part of the package or not. If it's raising this flag, we can make really actionable decisions at a very micro level to enable the build to keep pushing forward.

One thing that can sometimes be difficult with FOSSA is understanding all that it can do. One of the ways that I've been able to unlock some of those more advanced features is through conversations with the absolutely awesome customer success team at FOSSA, but it has been a little bit difficult to find some of that information separately on my own through FAQs and other information channels that FOSSA has. 

The improvement is less about the product itself and more about empowering FOSSA customers to know and understand how to unlock its full potential. More training would be helpful. When we first purchased FOSSA, there was no real onboarding that I was a part of. That could just be because FOSSA did an onboarding with someone else on the team, and I inherited that after the fact, but onboarding would be very helpful. Another thing that would be really helpful is building out more documentation for more advanced use cases of FOSSA. One, in particular, would be for the use case where FOSSA can help you really drill down on a specific package and what licenses are flagged or rejected in that package, and how to resolve those within the system. This was something about which I couldn't find documentation on the FOSSA website, and I had to have the CS team walk me through that.

I have been using this solution for about two years.

It is very stable. We have not experienced any downtime.

It scales very well. One of the things that I love is that the engineering teams have been able to load more and more projects into FOSSA and build out their pipelines. FOSSA also has integrations with Slack, and these integrations enable FOSSA to notify and push notifications on Slack after a scan has been completed and the issues have been identified. That's very helpful from my perspective and from a team's perspective because it creates visibility. It also enables me to not spend all day every day in the FOSSA platform. Instead, I only need to go in when I receive a notification.

In terms of its usage, it is adopted a hundred percent in our company. In terms of users, there are two people from the legal team who use FOSSA. Largely, the entire engineering org uses FOSSA in one way or another, and its users range from the Chief Technology Officer, who oversees the engineering team, to director-level people in the engineering team. One in particular who uses FOSSA a lot and with whom I partner is the director of platform and security at my organization. There are others as well, such as individual engineers, engineering managers, and our security manager.

When I couldn't find the answer to a question that I had, I was able to turn to our customer success manager who then was able to connect me. We jumped on a Zoom call with probably one of their platform engineers. Three of us were then able to recreate the issue and work through it together. On top of that, they were able to help me anticipate future issues on that point and how to navigate them. It was a near-term troubleshooting solution and a long-term way to work more efficiently. They're responsive and knowledgeable.

We didn't use any solution previously.

I don't know if its initial setup was complex or straightforward. I was a part of the initial setup, but I wasn't the primary owner of the initial setup. I was a stakeholder who was consulted and ultimately would become the primary owner, but I wasn't a part of the actual setup piece. Eventually, the setup was transitioned over to me where I took full ownership. 

I don't have a whole lot of visibility on the number of hours per se, but I remember from the time of purchase to the time we stood it up, it was relatively quick and brief.

FOSSA is well worth the investment. It is an opportunity to scale your operations, especially for a legal team to maintain pace with your technical teams, especially your engineering teams, in a cost-efficient way. Instead of using a platform like FOSSA, the alternative might be to hire one or two FTEs where their full-time role is to manually scan the open-source licenses. If you were to do that, you have an additional cost, additional overhead, and additional risk. With something like FOSSA, you have something that's easily auditable, easy to roll out of the box, and easy to scale. It's a no-brainer.

The auditability is critical. There have been a handful of conversations that I've had with Enterprise customers at my company where they've requested reports related to open-source compliance and dependencies. If you were to pull this data manually, it would probably take months to track down the data, verify it, and generate the report for a single build, whereas FOSSA does that almost instantaneously through the platform. It produces an auditable record that you can then share with customers and investors as you're going through a diligence exercise.

Its price is reasonable as compared to the market. It is competitively priced in comparison to other similar solutions on the market. 

It is also quite affordable in terms of the value that it delivers as compared to its alternative of hiring a team.

We did explore and had demos of other solutions. One of the solutions was WhiteSource. I wasn't involved in the ultimate decision-making process. I was, sort of, consulted, but I was not ultimately involved. I think it came down to the platform itself in terms of usability and the support for our use cases. That was the tipping point.

I would rate FOSSA a nine out of 10 in terms of efficiency, scaling, and speed. I would rate it a 10 if the documentation to really get into advanced features was more widely available. 

The solution is used for cyber security.

The scalability is excellent.

The technical support has room for improvement.

I have been using the solution for one year.

I give the scalability a ten out of ten.

We used technical support for the deployment.

The solution's cost is a five out of ten.

I give the solution a five out of ten.

There are ten companies in South Korea using FOSSA.

We use the solution for the security compliance and licensing of open-source components.

I am impressed with the tool’s seamless integration and quick results.

I want the product to include binary scanning which is missing at the moment. Binary scanning includes code and component matching through dependency management. It also includes the actual scanning and reverse engineering of the boundaries and finding out what is inside.

We have been using the solution for four years. We are using the solution since its introduction.

The tool is very stable. I have never had a problem with it.

The solution has around 300 users in our company.

I haven’t contacted tech support yet since I know the sales director and the whole sales team personally.

The solution’s setup is very easy.

FOSSA is a fairly priced product. It is not either cheaper or expensive. The pricing lies somewhere in the middle. The solution is worth the money that we are spending to use it.

I would rate the solution an eight out of ten. I highly recommend the tool to users because its user interface lets us know what we are doing.

I am on the security side, and I help developers in implementing this solution. We use this solution to know the licenses of the libraries for the legal part.

In terms of deployment, I go to the website, so it is a SaaS version.

When we sell products to the customer, we need to give them a file with different licenses. FOSSA enables us to do that. It is useful for licensing compliance.

FOSSA provides contextualized and actionable intelligence that alerts you to compliance issues. I do receive alerts, but I am not the one who is managing this part.

Being able to know the licenses of the libraries is most valuable because we sell products, and we need to provide to the customers the licenses that we are using.

It is easy to use with a wide range of developer ecosystem tools, and I would rate it a 10 out of 10 from this perspective.

It is holistic in terms of collaboration between the legal teams and DevOps. As a security specialist, I'm just helping developers to set up their repositories. It is the legal team that takes a case up with the Dev team.

On the dashboard, there should be an option to increase the column width so that we can see the complete name of the GitHub repository. Currently, on the dashboard, we see the list of projects, but to see the complete name, you have to hover your mouse over an item, which is annoying.

We can rename a GitHub report, but the problem is that if legal changes the name and says, "Okay, this repository is part of the solution with a specific name," I lose the specific URL of the GitHub repository. I no longer know which one it is. They should make this information available.

I have been using FOSSA for one year.

It looks great to me in terms of stability.

Currently, only four people are directly using FOSSA in the browser. Its users include the legal team and me. I'm helping developers with the setup, but they are not directly using FOSSA in the browser.

Its usage is 100% for the applications with which we are using it. 

Their support is great. I would rate them a 10 out of 10. Generally, I talk to my customer success contact. He is really responsive, and he always finds a solution. He is also always available for our call. 

We were using another solution. We switched because FOSSA was easier to set up. It was also the right one for the licenses for the libraries.

I was involved in the initial setup of FOSSA, and it was straightforward. It was really easy to set up, and our customer success contact was really helpful. For all the projects, it took two months.

In terms of the deployment strategy, we start with some projects, and when we know that we want to sign up with FOSSA, we evaluate it for other projects.

I did it myself. In terms of maintenance, it doesn't require any maintenance from our side.

We didn't evaluate other solutions. This was the only one because my legal team colleagues wanted to try it.

It was easy to set up. You can easily set it up by looking at the documentation.

I would rate FOSSA a 10 out of 10. 

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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. 

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

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.

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.

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.

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.

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.