We changed our name from IT Central Station: Here's why
Get our free report covering SonarSource, Synopsys, Snyk, and other competitors of WhiteSource. Updated: January 2022.
564,997 professionals have used our research since 2012.

Read reviews of WhiteSource alternatives and competitors

Nicholas Secrier
Information Security Officer at a tech services company with 51-200 employees
Real User
Top 5Leaderboard
Helps Avoid The Pain And The Cost Of Trying To Retrofit Security in your Code.
Pros and Cons
  • "The dependency checks of the libraries are very valuable, but the licensing part is also very important because, with open source components, licensing can be all over the place. Our project is not an open source project, but we do use quite a lot of open source components and we want to make sure that we don't have surprises in there."
  • "Generating reports and visibility through reports are definitely things they can do better."

What is our primary use case?

We are using it to identify security weaknesses and vulnerabilities by performing dependency checks of the source code and Docker images used in our code. We also use it for open-source licensing compliance review. We need to keep an eye on what licenses are attached to the libraries or components that we have in use to ensure we don't have surprises in there.

We are using the standard plan, but we have the container scanning module as well in a hybrid deployment. The cloud solution is used for integration with the source code repository which, in our case, is GitHub. You can add whatever repository you want to be inspected by Snyk and it will identify and recommend solutions for your the identified issues. We are also using it as part of our CI/CD pipelines, in our case it is integrated with Jenkins. 

How has it helped my organization?

As the developers work they can run the checks and they can validate if their work meets our expectation or not. Then they can address the potential issues during development, rather than going through the whole process and then being pushed back and told, "Hey, you've got issues in here. This is an old component that is no longer supported," or "It's something that has a vulnerability." From that point of view, it's very valuable.

I'm not a developer, I'm an information security officer, but the false positive rate seems to be pretty good. Generally, when it picks up something, it's there. Snyk is not an antivirus. When it highlights something then there is a problem. Sometimes you can fix it, sometimes you cannot fix it. The good thing is that at least you are aware that there is a potential issue. If it's something serious, you can try to validate, but you can usually validate the issue against other databases by looking at a CVV. You've got enough information to identify if this is a real problem or not. In the vast majority of the cases, if you look at dependency, it's pretty straightforward. It matches the database that is being picked up, and you can have a look at more details.

Generally, security tools don't necessarily end up in increased productivity. What Snyk prevents is the wasting of time or productivity. If you're trying to go back and fix issues that are caused by potential vulnerabilities discovered by a pen test, trying to retrofit security can be quite painful. From that point of view, you may go a little bit slower because it's an extra step, but at the same time, you save time on the overall process and you're saving exposing the company to risks.

As a tool, Snyk allows us to identify areas where we need to improve, and this could be at the vulnerability level if there is a library that has a vulnerability. It also helps us with the licensing compliance, identifying if the new components that have been added to the code meet our company's open source compliance. In those ways it helps us as a company. The overall impact of Snyk depends on the way you use it. To me, it's the users, not Snyk, doing something.

We are a new company. We started roughly three years ago. But we knew security is a very important factor. We work with some very large companies out there. Privacy and security of their data is very important. Security was something that we knew we had to put in place from the beginning, as a way of demonstrating that we take things seriously. And we also satisfy the needs of our investors and clients when it comes to trusting us as a provider.

What is most valuable?

The dependency checks of the libraries are very valuable, but the licensing part is also very important because, with open source components, licensing can be all over the place. Our project is not an open source project, but we do use quite a lot of open source components and we want to make sure that we don't have surprises in there. That's something that we pay attention to.

The ease of use for developers is quite straightforward. They've got good documentation. It depends on the language that you use for development, but for what we have — Java, JavaScript, Python — it seems to be pretty straightforward.

It also has good integration with CI/CD pipelines. In the past we had it integrated with Concourse and now it's running on Jenkins, so it seems to be quite versatile.

What needs improvement?

They've recently launched their open source compliance. That's an area that is definitely of interest. The better the capability in that, the better it will be for everyone. There may be room to improve the level of information provided to the developers so they understand exactly why using, say, a GPL license is a potential issue for a company that is not intending to publish its code.

There is potential for improvement in expanding the languages they cover and in integrating with other solutions. SonarQube is something that I'm quite interested in, something that I want to bring into play. I know that Snyk integrates with it, but I don't know how well it integrates. I will have to see.

Generating reports and visibility through reports are definitely things they can do better.

For how long have I used the solution?

We've been using Snyk for nearly two years.

What do I think about the stability of the solution?

Generally, the stability of Snyk is fine. From time to time the reporting bits, when you look at them on the cloud, can be a little bit sluggish when you start having quite a bit of information in there. But there have been no major outages when we couldn't use it. I don't know if the sluggishness is internet-related or it's something within Snyk. They are based in the United States and I don't know if the traffic across the pond is causing any of these issues.

It's not something that you constantly use all the time. When you want to commit something, it runs on a schedule. When you put something through the pipeline, it runs. But again, there have been no outages or issues with the stability.

What do I think about the scalability of the solution?

We have had no issues with scalability. We haven't needed to do anything special to address that. So far, we have had no problems.

Usage, in our case, will depend on the number of developers that we have. So unless Snyk develops additional features, something more we can use, and we expand because of those capabilities, I don't see a massive increase in our user base. It's a development-orientated solution with a small number of people, from management, who generally keep an eye on the reports, from a compliance point of view. It all depends on our company. The only impact that will come from Snyk is if it comes out with new features that we would like to implement.

How are customer service and technical support?

We had some chats with technical support at the beginning. They seemed to be pretty responsive. Generally, you communicate with them on a support chat-group. If you need more, you can have Zoom sessions. But we only speak with them now if one of the devs finds something that doesn't look right. We haven't spoken to them in a long time.

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

Snyk replaced some potential candidates. We had some people looking at maybe using CoreOS Clair and there were some discussions about what we could use to scan our repository. But we didn't have anything officially in place. In fact, Snyk was one of the first solutions that I put in place as a paid solution for the security of our code.

Security is something that is quite important for us. We take security seriously and it's something that we baked in from the early stages. We try to shift it as far left as possible. Snyk is a result of our organization's approach towards security, rather than vice-versa. It's playing its role alongside our security needs.

How was the initial setup?

In our organization, I ask that things be done and people are doing them, so I wasn't directly involved in the setup. But the installation seemed to be quite straightforward. I don't get pushback from the dev community. My background is more infrastructure, I'm not a developer, so I can't comment how easy it is to bring everything together. But when I worked with my devs, when we migrated from Concourse to Jenkins, it wasn't such a huge undertaking and it didn't cause us too many headaches.

In terms of developer adoption, they have to use it because we asked them to use it. And once it's part of the pipeline; everything that they push through the pipeline goes through Snyk. It was a company decision to go that way.

The initial rollout took about one week. Most of the stuff was already in place. We just migrated from one pipeline provider to another. It was quite straightforward.

We have a bit of a hybrid approach. Some of it was in the cloud, and we haven't touched that. The integration of the container bit, the CLI integration is done on our cloud and it's something we maintain. We tried to use Snyk's recommendations. It has an API that you can call use to run some scans, but their full-feature recommended solution is to use the CLI, using your own instance of Snyk. So we have a container that's running Snyk, and whenever we run the scans we just call on that.

The deployment involved one or two people internally. When it was just GitHub, it was me and one developer. And when it came to infrastructure, it was me with an infra guy. It depends on the level of expertise that you have in-house and how comfortable people are with similar solutions. At the end of the day, to roll up a container image and pull that into your pipeline is quite straightforward. It's not difficult.

We don't do that much maintenance on Snyk. It's integrated. It's running in the background. We only touch it when we need to touch it. It's not like we need dedicated resources for that.

Between 50 and 70 people are using Snyk at a given time in our organization. Most of them are developers. We might have some QAs who look at something.

What was our ROI?

It hits ROI for us very well in a couple of areas that we want to address: to ensure that we don't have surprises when it comes to vulnerabilities on our dependencies — libraries and images. And from a compliance point of view, we don't want to be in a situation where we're forced to publish code because someone has decided to use libraries that would force us to either publish everything under GPL or put us in a situation where licenses are not compatible and we would have to redo part of the code.

The ROI is one of those things that is difficult to quantify. It's not something where you can say how much money you have saved. But looking at overall cost versus the benefit, it's worth the money.

Time-to-value is a difficult topic because the way that I see it, Snyk is a preventative measure. It's similar to insurance. How much money are you prepared to spend to address a potential risk? By having a solution like Snyk in place, you prevent your company from being an easy target and being exposed. It's not something you can easily quantify, but Snyk falls under the cost of doing business. You want to have something in there because the overall cost and the overall problems will be a lot greater.

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

Pricing and licensing of Snyk is okay. Their model is based on the number of committers of your source code, which can be a little bit false at times. It can be false because we have some QAs and some BAs, for example, who sometimes go in and add comments. They're not writing code, but they're flagged as committers of the code. That can cause some misunderstanding but we discussed this Snyk and explained the situation. They were quite okay with that. So although the number of people they see in Snyk is slightly higher, they're not holding us with our backs to the wall, saying, "Hey, you're over your license."

The only cost is whatever you run on your cloud. If you deploy the CLI integration and you run Snyk you need to take into account the cost, but it's not huge.

Which other solutions did I evaluate?

There are a number of other solutions out there that you can use. We looked at Black Duck from Synopsys and CoreOS Clair for containers. I had a bit of a look at WhiteSource. Because we're using open source software, a lot of our devs like the open source ethos. They had different suggestions so we looked at a number of potential use case scenarios. These days, for example, GitHub also allows you to scan your reports for dependencies and vulnerabilities. AWS also has the ability to scan your base images. You can validate different things at different stages. But the main one for moving the security to the left is Snyk.

In terms of the comprehensiveness and accuracy of Snyk's vulnerability database, I looked at that in the past. When I picked Snyk as a solution and was looking at Black Duck and other companies, I knew Snyk had its own database and was doing quite a lot of research in that area. To me it seems to be quite good compared to other solutions, like GitHub or Amazon. I get more out of Snyk. Snyk picks up more, highlights more, than other solutions I've seen.

Both Black Duck and WhiteSource are more established companies but they're probably more expensive. I haven't looked at the overall costs, but as you throw more into them they tend to be more expensive. Snyk meets our requirements.

What other advice do I have?

If your company develops software, and if you are an open source consumer, you need to have something in place. Do your research and find the best solution. For us, Snyk worked. I am involved in a security working group with my counterparts at our investors. We discussed what we're doing and what we are using and I discussed Snyk there. I discussed it with a couple of companies in particular and shared ideas and I recommended that they have a look at Snyk. Snyk is open source. You can take it for a ride and see if you like it. Once you're happy with it, you can move forward.

The biggest lesson I've learned from using Snyk is that it brings in a little bit of discipline in terms of what people can and cannot use. It also highlights the importance of security. It also adds a little bit of structure by surfacing potential issues. That's one of the most important factors. And having something like Snyk means you can validate and you can demonstrate, when meeting your clients and your investors, that you are meeting security needs and concerns.

In terms of the time it takes for developers to find fixed vulnerabilities, it depends on the type of issue. In some cases, for example, if there is an upgrade and there is a new version of the library, Snyk does make recommendations. If Snyk can do something for you it will do it. It can automatically generate a pull request so you can do a library upgrade. If there is something quite straightforward regarding licensing, they'll highlight that for you. But other issues are a little bit more complex. If it's a container image, for example, and there's no immediate image upgrade, maybe you want to do something like upgrade a library within the image. Some things are quite straightforward, and if Snyk can, it recommends it, and it's pretty easy, pretty straightforward. For other situations it will say you can manually upgrade this, but you'll have to do that process on your own.

Snyk's actionable advice when it comes to container vulnerabilities is aligned with the rest of the solution. We were one of the early users of containers. We have had Snyk in place for nearly two years, so when we started, containers were something very new for them. It's definitely better than other solutions which are free. Can it be better? Yes. As always, things can always be improved, but it's more or less on par with what we have on the regular dependency checks that we have on normal libraries as part of the source code.

If you look purely at the source code, we can do it with a SaaS application. You link your GitHub or your code repository with Snyk and, as you commit code, Snyk scans and reports. For containers, we tend to use the integration part of the CI/CD pipeline as well. All the images are passed through and we're using CLI commands to run this. This requires a little bit of extra setup, but once you put it in place it tends to be quite straightforward and doesn't require any additional work. As for allowing developers to own security for the applications and the containers they run in in the cloud, to be honest with you, in a lot of cases, their main focus is on developing the app. The scanning is more on the infra side. When it comes to containers and streamlining the application installation, that usually falls on the infra. They stay on top of that task. We have it integrated and we keep an eye out in case something has been plugged up. I just ask them to make sure it's addressed as soon as possible.

We're using Qualys to do external scans and external assessments. We also do penetration testing. But at the end of the day, you have to look at what you want from a tool. Maybe there are other solutions out there that claim to do a lot more. I'm sure that there are other vendors that can potentially give you a more integrated and better view, but they come with additional costs and additional complications. It all depends on what you want to do and how you want to achieve that. For us, the purpose of Snyk was to look at the vulnerabilities in the code or Docker container images, and to address the licensing aspect. 

Some companies go with individual solutions for every single part. For example, they use Clair to scan just the containers and something else to scan just the code. They have linting tools and other things. We're not just using Snyk. For example, we also have linting tools for code quality. This is not something that Snyk is doing. We're trying to use what is suitable for us.

Disclosure: PeerSpot 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.
ITCS user
Software Architect at Alfresco Software
Real User
Top 20
Prevents vulnerable code from going into production, but the user interface is dated and needs considerable work
Pros and Cons
  • "The solution's ability to prevent vulnerable code from going into production is perfectly fine. It delivers, at least for the reports that we have been checking on Java and JavaScript. It has reported things that were helpful."
  • "Veracode has plenty of data. The problem is the information on the dashboards of Veracode, as the user interface is not great. It's not immediately usable. Most of the time, the best way to use it is to just create issues and put them in JIRA... But if I were a startup, and only had products with a good user interface, I wouldn't use Veracode because the UI is very dated."
  • "Another problem we have is that, while it is integrated with single sign-on—we are using Okta—the user interface is not great. That's especially true for a permanent link of a report of a page. If you access it, it goes to the normal login page that has nothing that says "Log in with single sign-on," unlike other software as a service that we use. It's quite bothersome because it means that we have to go to the Okta dashboard, find the Veracode link, and log in through it. Only at that point can we go to the permanent link of the page we wanted to access."

What is our primary use case?

The use case is that we have quite a few projects on GitHub. As we are a consulting company, some of these projects are open source and others are enterprise and private. We do security investigating for these projects. We scan the repository for both the static analysis—to find things that might be dangerous—and we use the Software Composition Analysis as well. We get notifications when we are using some open source library that has a known vulnerability and we have to upgrade it. We can plan accordingly.

We are using the software as a service.

How has it helped my organization?

It has improved the way our organization functions mostly because we can perfect the security issues on our products. That means our product managers can plan accordingly regarding when to fix something based on the severity, and plan fixes for specific releases. So, it has improved our internal process. It has also improved the image of the company from the outside, because they can see in the release notes of our products that we take security seriously, and that we are timely in the way that we address issues.

The solution has helped with developer security training because when we open a ticket with information coming from Veracode, it explains, for example, that some code path or patterns that we have used might be dangerous. That knowledge wasn't there before. That has really helped developers to improve in terms of awareness of security.

What is most valuable?

The feature that we use the most is the static analysis, by uploading the artifacts. We have two types of applications. They are either Java Server applications using Spring Boot or JavaScript frontend applications. We scan both using the static analysis. Before, we used to do the software composition on one side and the static analysis. For about a year now, we have had a proper security architect who's in charge of organizing the way that we scan for security. He suggested that we only use the static analysis because the software composition has been integrated. So in the reports, we can also see the version of the libraries that have vulnerabilities and that need to be upgraded.

It is good in terms of the efficiency of creating secure software.

My team only does cloud-native applications. Ultimately, the part that we are interested in, in testing, works fine.

There are some false positives, like any products that we have tried in this area, but slightly less. I would trust Veracode more than the others. For example, we had quite a few issues with Snyk which was much worse in terms of false positives, when we tested it for open source.

Also, the solution's ability to prevent vulnerable code from going into production is perfectly fine. It delivers, at least for the reports that we have been checking on Java and JavaScript. It has reported things that were helpful.

What needs improvement?

What could improve a lot is the user interface because it's quite dated. And in general, as we are heavy users of GitHub, the integration with the user interface of GitHub could be improved as well. 

There is also room for improvement in the reporting in conjunction with releases. Every time we release software to the outside world, we also need to provide an inventory of the libraries that we are using, with the current state of vulnerabilities, so that it is clear. And if we can't upgrade a library, we need to document a workaround and that we are not really touched by the vulnerability. For all of this reporting, the product could offer a little bit more in that direction. Otherwise, we just use information and we drop these reports manually.

Another problem we have is that, while it is integrated with single sign-on—we are using Okta—the user interface is not great. That's especially true for a permanent link of a report of a page. If you access it, it goes to the normal login page that has nothing that says "Log in with single sign-on," unlike other software as a service that we use. It's quite bothersome because it means that we have to go to the Okta dashboard, find the Veracode link, and log in through it. Only at that point can we go to the permanent link of the page we wanted to access.

Veracode has plenty of data. The problem is the information on the dashboards of Veracode, as the user interface is not great. It's not immediately usable. Most of the time, the best way to use it is to just create issues and put them in JIRA. It provides visibility into the SAST, DAST and SCA, but honestly, all the information then travels outside of the system and it goes to JIRA.

In the end, we are an enterprise software company and we have some products that are not as modern as others. So we are used to user interfaces that are not great. But if I were a startup, and only had products with a good user interface, I wouldn't use Veracode because the UI is very dated.

Also, we're not using the pipeline scan. We upload using the Java API agent and do a standard scan. We don't use the pipeline scan because it only has output on the user interface and it gets lost. When we do it as part of our CI process, all the results are only available in the log of the CI. In our case we are using Travis, and it requires someone to go there and check things in the build logs. That's an area where the product could improve, because if this information was surfaced, say, in the checks of the code we test on GitHub—as happens with other static analysis tools that we use on our code that check for syntax errors and mapping—in that case, it would be much more usable. As it is, it is not enough.

The management of the false positives is better than in other tools, but still could improve in terms of usability, especially when working with multiple branches. Some of the issues that we had already marked as "To be ignored" because they were either false positives or just not applicable in our context come down, again, to the problem of the user interface. It should have been better thought out to make it easier for someone who is reviewing the list of the findings to mark the false positives easily. For example, there were some vulnerabilities mentioning parts of libraries that we weren't actually using, even if we were including them for different reasons, and in that case we just ignore those items.

We have reported all of these things to product management because we have direct contact with Veracode, and hopefully they are going to be fixed. Obviously, these are things that will improve the usability of the product and are really needed. I'm totally happy to help them and support them in going in the right direction, meaning the right direction from my perspective.

For how long have I used the solution?

I have used Veracode for quite a long time now, about two years. I have been working here for three years. In my first year, the company was using a different product for security and then it standardized on Veracode because every department had its own before that. There was consolidation with Veracode.

What do I think about the stability of the solution?

The stability is good. What I have seen in the stats is that there is downtime of the service a little too often, but it's not something, as a service, where you really need that level of availability on. So I'm not really bothered by that.

What do I think about the scalability of the solution?

We don't have to do anything to scale, because it's SaaS. 

We started with a smaller number of users and then we extended to full single sign-on.

How are customer service and technical support?

The staff of Veracode is very good. They're very supportive. When the product doesn't report something that we need and is not delivering straight away, they always help us in trying to find a solution, including writing custom code to call the APIs.

From that point of view, Veracode is great. The product, much less so, but I believe that they have good people. They are promising and they listen so I hope they can improve.

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

We started with WhiteSource, but it didn't have some features like the static analysis, so it was an incomplete solution. And we were already using Veracode for the static analysis, so when Veracode bought SourceClear, we decided to switch.

How was the initial setup?

The initial setup is easy and quite well documented. I was really impressed by the quality of the technical support. When I had problems, that the product wasn't good enough for me, they were always there to help and give suggestions.

Being a service, there wasn't really much of an implementation. It's not complex to use.

What was our ROI?

My job is mostly technical. I don't own a budget and I don't track numbers. But as the customers are really keen on having us checking security issues, I would definitely say that we have seen a return on investment.

Most of our customers tend, especially in the software composition analysis, to apply their own in-house tools to the artifacts that we share with them. Whenever we release a new version of software and Docker images, they upload it to their systems. Some of them have the internal equivalent of Veracode and they come back to us to say, "Hey, you haven't taken care of this vulnerability." So it is very important for us to be proactive on each set of release notes. We need to show the current status of the product: that we have fixed these vulnerabilities and that we still have some well-known vulnerabilities, but that there are workarounds that we document. In addition they can check the reports that we attach, the reports from Veracode, that show that the severity is not high, meaning they don't create a big risk.

It delivers because we haven't been thinking, "Okay, let's consider another product." We might see some savings so I think the pricing is right.

Which other solutions did I evaluate?

For open source projects we mostly tested Snyk, which works quite well with JavaScript but much less so with other technologies. But it has some bigger problems because Snyk considers each file inside a repository of GitHub as a separate project, so it was creating a lot of false positives. That made it basically unmanageable, so we gave up on using it.

We have also been using an open source project called the OWASP Dependency-Check that was doing a decent job of software composition analysis but it required a lot of effort in checking false positives. To be honest, it would have been a good solution only if we didn't have a budget for Veracode, but luckily we had the budget, so there was no point in using it.

Another one that we tried, mostly because it was a small company and we had the opportunity to speak directly with them to ask for some small changes, was a company called the Meterian. It doesn't do static analysis, but otherwise the software composition analysis and the library report were the best of the bunch. From my perspective, if we didn't have the need for static analysis, I would have chosen Meterian, mostly because the user interface is much more usable than Veracode's. Also, the findings were much better. We still use it on the open source project because they offer a free version for open source—which is another good thing about some of these products, where the findings are available to anyone. For a company like ours, where we have both open source and enterprise products, this is quite good. Unfortunately, with Veracode, if we scan the open source project, we cannot link the pages of Veracode with the findings because they are private. That's a problem. In the end, for the open source projects, we are still using Meterian because the quality is good.

My main issues with Veracode, in general, are mostly to do with the user interface of the web application and, sometimes, that some pages are inconsistent with each other. But the functionality underneath is there, which is the reason we stay with Veracode.

What other advice do I have?

Usually, we open tickets now using the JIRA/GitHub integration and then we plan them. We decide when we want to fix them and we assign them to developers, mostly because there are some projects that are a little bit more on the legacy side. Changing the version of the library is not easy as in the newer projects, in terms of testing. So we do some planning. But in general, we open tickets and we plan them.

We also have it integrated in the pipelines, but that's really just to report. It's a little bit annoying that the pipeline might break because of security issues. It's good to know, but the fact that that interrupts development is not great. When we tried to put it as a part of the local build, it was too much. It was really getting in the way. The developers worried that they had to fix the security issues before releasing. Instead, we just started creating the issues and started doing proper planning. It is good to have visibility, but executing it all the time is just wrong, from our experience. You have to do it at the right time, and not all the time.

The solution integrates with developer tools, if you consider JIRA and GitHub as developer tools. We tried to use the IntelliJ plugin but it wasn't working straightaway and we gave up.

We haven't been using the container scanning of Veracode, mostly because we are using a different product at the moment to store our Docker images, something that already has some security scanning. So we haven't standardized. We still have to potentially explore the features of Veracode in that area. At the moment we are using Key from IBM Red Hat, and it is also software as a service. When you upload a Docker image there, after some time you also get a security scan, and that's where our customers are getting our images from. It's a private registry.

Overall, I would rate Veracode as a five out of 10, because the functionality is there, but to me, the usability of the user interface is very important and it's still not there.

Disclosure: PeerSpot 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.
Data Privacy Officer at a healthcare company with 51-200 employees
Real User
Top 20
Reduces our costs and timeline and allows us to go very granular and automate the scanning of licenses
Pros and Cons
  • "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."

What is our primary use case?

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.

How has it helped my organization?

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.

What is most valuable?

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.

What needs improvement?

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.

For how long have I used the solution?

I have been using this solution for about two years.

What do I think about the stability of the solution?

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

What do I think about the scalability of the solution?

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.

How are customer service and technical support?

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.

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

We didn't use any solution previously.

How was the initial setup?

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.

What was our ROI?

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.

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

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.

Which other solutions did I evaluate?

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.

What other advice do I have?

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. 

Which deployment model are you using for this solution?

Public Cloud
Disclosure: PeerSpot 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.
Flag as inappropriate
Andy Cox
Product Strategy Group Director at Civica
Real User
Top 5
Helps our developers be aware of duplicate components in their code, but .NET open-source licensing recognition needs work
Pros and Cons
  • "For us, it's seeing not only the licensing and security vulnerabilities but also seeing the age of the open-sources included within our software. That allows us to take proactive steps to make sure we're updating the software to versions that are regularly maintained and that don't have any vulnerabilities."
  • "We use Azure DevOps as our application lifecycle management tool. It doesn't integrate with that as well as it does with other tools at the moment, but I think there's work being done to address that. In terms of IDEs, it integrates well. We would like to integrate it into our Azure cloud deployment but the integration with Azure Active Directory isn't quite as slick as we would like it to be. We have to do some workarounds for that at the moment."

What is our primary use case?

We have two use cases. We're predominantly a products company and we scan our products, in a controlled way, to make sure they're not using open-source software. We want to make sure that we're licensed correctly for our products and the way they are deployed. There are also security reasons for making sure that our products aren't introducing vulnerabilities and, if they are, that we can address them. 

And part of our business is that we build bespoke software. Some of our customers want to make sure that the open-source software is being used correctly in the software we build for them. And, again, we want to protect that software against security vulnerabilities that might be introduced by open-source software.

We also use the solution to help with open-source governance and minimize risk. When we are acquiring a new company, for example, we will automatically, as part of the due diligence on that purchase, scan their products to make sure they don't have vulnerabilities that we are not prepared to accept. So it helps us to make sure, before we make any purchase, that the target acquisition is of suitable quality, in terms of its open-source use.

How has it helped my organization?

The solution has improved the way our company functions in terms of the way that developers think about the components that are being built into their products, making sure they're not being duplicated, for example. The developers now understand that there's a cost associated with including open-source. It may not have a licensing fee, but there is a cost associated with it. That sort of education piece has had a big influence.

It has also brought open-source intelligence and policy enforcement across our SDLC. As the teams are setting up their development environments, we have now gotten them to build Sonatype into their development pipeline. They scan their codebase so they actually catch things at the point that they introduce new, open-source software into the products, to make sure they're not actually introducing vulnerabilities or licensing-policy breaches.

Sonatype has also reduced our risk in releasing secure apps to market. Previously, teams would just release without knowing what risks it was exposed to. Now, we can actually do a better risk assessment.

What is most valuable?

For us, it's seeing not only the licensing and security vulnerabilities but also seeing the age of the open-sources included within our software. That allows us to take proactive steps to make sure we're updating the software to versions that are regularly maintained and that don't have any vulnerabilities.

In addition, the default policies, in general, are quite good. We have adjusted slightly but we're fairly happy with the way that's set up. They provide us with the flexibility we're looking for.

The data quality is pretty good. We don't have masses of false positives. There have been some areas around .NET which haven't been quite as good as some of the other areas, but we know work is being done on that. Overall, the data quality does help us solve problems faster.

What needs improvement?

We use Azure DevOps as our application lifecycle management tool. It doesn't integrate with that as well as it does with other tools at the moment, but I think there's work being done to address that. In terms of IDEs, it integrates well. We would like to integrate it into our Azure cloud deployment but the integration with Azure Active Directory isn't quite as slick as we would like it to be. We have to do some workarounds for that at the moment.

Also, the ability of the solution to recognize more of the .NET components would be helpful for us.

For how long have I used the solution?

I've been using Sonatype for about six years.

What do I think about the stability of the solution?

It's a stable product, especially compared to some of its competitors.

How are customer service and technical support?

The technical support is generally good. A couple of years ago there were some things that had been logged and that had to be chased a few times. They didn't go as quickly as we'd have liked. But recently, things have been better and they have been more timely in their responses.

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

Our company tried with Black Duck, but that was it.

How was the initial setup?

The initial setup was straightforward. One of my team members was able to execute it quite quickly without too much trouble or additional help.

It's deployed internally at the moment but, moving forward, we want to move it to a cloud-based deployment.

What was our ROI?

We have seen return on our investment, but it's a difficult one to quantify because, unless you have a problem, it's like any sort of security or testing; it's difficult to quantify unless you have an issue. In terms of protecting our IP it certainly has provided ROI and, in security issues as well, it has helped us to identify them, reducing our risk. There has been a big risk reduction for us.

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

We pay on a yearly basis.

Which other solutions did I evaluate?

We do a supplier selection every couple of years. One solution that we've evaluated is Black Duck, for example, but it didn't seem to be as stable as the Sonatype solution, when we last tested it.

WhiteSource is another one we tested. It's a cloud-hosted solution so I can't comment on its stability.

Comparing these solutions with Sonatype, the information that comes with Sonatype and its recognition are good. The fact that WhiteSource is cloud-hosted is nice and it's an advantage you don't immediately get with Sonatype. But with WhiteSource we got more false positives than we did with other tools. And Black Duck, when we've last reviewed it, wasn't as comprehensive as what we are looking for.

Sonatype met our needs, what we were looking for, particularly around protection of IP. The knowledge of the Sonatype team, and our good working relationship with them, have helped us to continue to use the product. The fact that they take some of our feedback and incorporate it into the product has also helped.

What other advice do I have?

I would definitely recommend understanding what you're trying to achieve. For us it's quite clear that we want, for the moment, to protect our IP and to identify security vulnerabilities. If the understanding is that you want to protect against open-source from coming into your products in the first place, or you're doing greenfield development, look at the right product stack from Sonatype to make sure that you're choosing the right set of products. We've got a mature product base that we're working with. If you're starting from scratch, you would want to assess what you're trying to get out of your policies and processes around this, and make sure that the products match.

We have about 150 users of Sonatype in our company, and their roles range from managers who review the open-source solutions to make sure they're being licensed properly in the product, to developers who are actually cutting the code. It's also service and project managers looking at their exposure, or maybe the audit team that wants to make sure that there's compliance within the different teams. For deployment of the solution and maintenance we have one person, a junior software engineer.

Sonatype is being used for regular scans on our priority projects, numbering about 20. We plan to eventually get that rolled out much more of our estate, to 50 or 60 business units.

I would rate it at seven out of 10. Some of the scanning around the .NET open-source licensing, the recognition; and the integration with some of our development tools, like Azure DevOps, are where, perhaps, it's lacking.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot 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.
CTO at a computer software company with 11-50 employees
Real User
Top 5Leaderboard
Good knowledge base and management system and helpful for discovering commercial and open-source licenses
Pros and Cons
  • "The knowledge base and the management system are the most valuable features of Black Duck Hub. It has a very helpful management environment. They offer an editor where we can check the discovered license, which is retrieved from their knowledge base. They have a huge knowledge base build over the years. It gives you some possibilities, such as this license with possibility A could cause a vulnerability issue or a potential breach."
  • "It is a cloud-only solution. In many cases, companies like to evaluate the software, but they're very reluctant to give you the software. It would be great if they could offer an on-prem component that could be used to scan the code and then upload the discovery results to the cloud and get all the information from there, but there is no such possibility. You have to upload the code to the Black Duck cloud system. Of course, they have a strong legal department, and they offer some configuration, but it is never enough. You have to give the code, which is a drawback. In modern designs like Snyk or FOSSA, you don't need to give the code. It requires more native integration with Coverity because they go together technically. You need both Coverity and Black Duck Hub. It would be really helpful for companies working in this space to get a combined offer from the same company. They should provide an option to buy Coverity for an additional fee. Coverity combined with Black Duck Hub will provide a one-step analysis to get everything you need and a unified report. It would be really great to be able to connect Black Duck Hub with Coverity unified reports."

What is our primary use case?

We use Black Duck Hub to discover commercial and open-source licenses and the licensed software used by a company. Whenever a company enters the M&A process, a preliminary step called due diligence is done. A part of it is the technical discovery that includes finding out what software the company is using and whether the software is linked with any open-source software or commercial product for which you have to pay a license.

Our main use case is to discover the license and find out if there is an obligation for the paid license. We also check the exposure of the software to open-source libraries. Open source is great, and it is a preferred solution for many companies. Around 90% of the software is now open source, but it is also exposed to vulnerabilities. So, through the dependencies that we were discovering, we were also working on the security exposure of the software product. For this purpose, we use Black Duck Hub.

What is most valuable?

The knowledge base and the management system are the most valuable features of Black Duck Hub. It has a very helpful management environment. They offer an editor where we can check the discovered license, which is retrieved from their knowledge base. They have a huge knowledge base build over the years. It gives you some possibilities, such as this license with possibility A could cause a vulnerability issue or a potential breach. 

What needs improvement?

It is a cloud-only solution. In many cases, companies like to evaluate the software, but they're very reluctant to give you the software. It would be great if they could offer an on-prem component that could be used to scan the code and then upload the discovery results to the cloud and get all the information from there, but there is no such possibility. You have to upload the code to the Black Duck cloud system. Of course, they have a strong legal department, and they offer some configuration, but it is never enough. You have to give the code, which is a drawback. In modern designs like Snyk or FOSSA, you don't need to give the code.

It requires more native integration with Coverity because they go together technically. You need both Coverity and Black Duck Hub. It would be really helpful for companies working in this space to get a combined offer from the same company. They should provide an option to buy Coverity for an additional fee. Coverity combined with Black Duck Hub will provide a one-step analysis to get everything you need and a unified report. It would be really great to be able to connect Black Duck Hub with Coverity unified reports.

For how long have I used the solution?

I have been using this solution for two and a half years. I was serving as vice president of engineering and integration in a company in Austin, Texas. I was assigned to acquisitions of companies, more specifically to the technical due diligence that takes place during acquisition. So, we used Black Duck Hub very extensively. We had the biggest ever contract with Synopsys for almost $1 million per year, and we used Black Duck Hub to scan the license for each acquired company. We had a very aggressive acquisition plan of almost one acquisition every 15 days. So, I have accumulated quite a big experience with the Black Duck Hub tool.

What do I think about the stability of the solution?

It is stable.

What do I think about the scalability of the solution?

From the company side, it's super scalable, but from the client's side, it's not that scalable. The issue with scalability is that if you have reserved 100 megabytes on Black Duck Hub, and eventually, you like to use 200 or 300 megabytes, the pricing policy requires extending your product permanently. This is really painful because you just need instant access to the higher, bigger space, but you don't want to buy it permanently. They should give the possibility to extend instantly by 50% or 80% more for a week or two weeks. This is quite common, and I have seen many cloud providers that let you pay instantly for a limited time, and you have the possibility to use a little bit more.

I have a team of six users who use Black Duck for the discovery, but the results are forwarded to many more things.

How are customer service and technical support?

In some cases, we have faced delays. We had reported issues, and we got the reply in 15 days or 20 days. Being a big organization, their support is rather slow. They prioritize these issues based on some logic unknown to me. If we have a big problem, we should get priority.

How was the initial setup?

The initial setup is super simple for the user because it is set up on the cloud. You just get an account and upload the code. You don't have to install it. There is no deployment. You just access the service from the cloud.

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

Black Duck is more suitable if you require a lot of licensing compliance. For smaller organizations, WhiteSource is better because its pricing policies are not really suitable for huge organizations.

Which other solutions did I evaluate?

I'm also currently testing WhiteSource, Black Duck Hub, FOSSA, Snyk, and a few more solutions. My assignment is to provide an evaluation for a blockchain platform.

What other advice do I have?

I would advise others to be careful with the provisioning of the space that you need. Black Duck has been the key player in the market for many years. It is totally in conjunction with Coverity and forms a suite of security and quality. It is frequently used in M&A or mergers and acquisition cases. It is the top product in the market.

I would rate Black Duck a nine out of ten. 

Which deployment model are you using for this solution?

Private Cloud
Disclosure: I am a real user, and this review is based on my own experience and opinions.
Get our free report covering SonarSource, Synopsys, Snyk, and other competitors of WhiteSource. Updated: January 2022.
564,997 professionals have used our research since 2012.