Black Duck SCA Reviews

The primary use cases are compliance and scanning in terms of license compliance and trying to identify snippets, particularly if there are any snippets being identified that are coming from open source. I also focus on identifying any open source components that are being used.

As of now, I am looking more from a compliance perspective, which is acceptable. However, from an SBOM or an SCA perspective, this is not the case because the SBOMs that are being generated from Black Duck SCA are not sometimes fully complete. The vulnerabilities that are being verified after generating this SBOM seem to be incorrect or missing.

The security risks that the tool is producing are questionable. The tool is giving a range for a given open-source component in a version and provides a list of vulnerabilities based on the sources with a lot of information. That part is good. However, the point is how accurate is the tooling and what needs to be pulled out. Based on the source, the tool should exactly point out which components are vulnerable, regardless of the source. If someone pulls a source from somewhere else and uses it, for example, if I have an open source from GitHub and another from Google, the same component. But in the Google version, it may not show vulnerability, while GitHub shows the vulnerability. Regardless of whether the source is from GitHub or Google, if that particular component and that version has a vulnerability, that vulnerability should be shown. A component is a component unless there is a complete change in the source code itself between that component and another. If I take an SSL component 10.1, that means SSL 10.1 is unique, regardless of whether it is in GitHub or coming from Google Open Source or some other source. If that component has a vulnerability from any of the sources, it should be considered and shown regardless of whether it is vulnerable from different sources. The source can be used to justify saying that the vulnerability is because of this source. However, a vulnerability is a vulnerability, and that should be the priority. It does not matter which source it comes from. If you take a source where there is no vulnerability, that should be based on the component and that version. From different sources it may have vulnerability or not, which may still be subjective, but I should ensure that the tool properly identifies all vulnerabilities.

I think Black Duck SCA needs to improve on the overall approach. I assume that the people who developed Black Duck SCA believe that users will use this tool for some time in a full-fledged way with all those features. However, the way it really works with product development or in a software development life cycle is that this is just one of the steps for checking whether something is license compliant, whether it has vulnerabilities, or whether the SBOM is generated. It is just one of those steps in the software development process. The expectation from the tool's perspective is that users have to go into the Black Duck SCA portal, look at each of those items, and if something is not correct, try to find it out and update or configure the right CPEs or PURLs or those kinds of things. In reality, most users would not have time for this because they would have done this as part of the build and would generate an SBOM as part of the build. The tool should be quite usable. If a feature works properly and correctly, then nobody will go back and try to spend time on that. For example, if I generate an SBOM and that SBOM has a particular CPE and there are multiple sources, the tool should produce those CPEs with vulnerabilities, put them into the SBOM, and allow me to move forward. If there are more bugs or more configuration requirements, the usage will come down. It is like a mobile application: if there is too much data that needs to be looked at, configured, and used, then the number of users would come down. The tool should be fast, usable, and accurate. Users should just be able to use it without needing to learn too much. The learning curve should be less when using a tool, and the usage should be easy with basic understanding. They should not need to go through complex processes and can assume that whatever data is given is correct. That is where the whole problem with Black Duck SCA lies.

The documentation is not really on the mark. For example, if there is a functionality, such as wanting to see a CPE, the documentation should show how to get this via API or see it and how to configure that with examples. Most of the time the tool says it is all in the community, which is not ideal. The community is different from a conceptual view. The community is for bugs and issues that users want to report. However, people who are looking at the tool fresh and need to see functionality such as scan configuration need clear documentation. If I want to see the scan configurations and how to do it, there are videos, but there should be clear documentation with examples, such as how to configure for Docker using specific commands and methods. This example could be clear documentation and should not be redirected to the community every time. If there is a problem or those kinds of issues, they should go to the community and solutions will be found. However, for basic documentation on features being provided, I do not see that kind of clear documentation with clear examples.

I have been using Black Duck SCA after they launched it, almost three years ago. I would say it is more than three years because before Black Duck SCA, I had previous versions. I have been using it for quite some time. Now it is almost close to seven-plus years from my point of view.

It is possible that I should be able to see the custom components and should also be able to update them, not only just open source. Those custom components can also have an origin ID.

Vulnerability alerts in real time are not much of a problem.

In terms of compliance, I would say it is around 7 to 8 with a lot of things. However, in terms of SBOM, I would say it is around 6 to 7.

I think Black Duck SCA should be able to add non-open source components because if they are going to be CRA compliant, there should be a possibility to add non-open source components, and they should also store that as part of the database. If that is having any vulnerability with a source from where that is coming from, I think that should be a necessity because today it is not.

My overall review rating for Black Duck SCA is 6 out of 10.

My use case for Black Duck is that it's primarily number one in the world because of the robustness of the solution. It's very accurate and is one of the more accurate solutions in the market. It's very exhaustive in terms of not just the primary source code, but also the dependencies, macros, and binaries. It tracks all of those. The robustness of the solution as well as the accuracy of the solution is what makes me look at Black Duck. The flip side is it is more expensive than the rest of the software solutions.

Black Duck's ability to identify dependencies very accurately has been most valuable in identifying and mitigating risks.

Compared to some of the other software in the world, Black Duck is extremely good at identification of licensing and open-source licensing, but it can improve on the security side of it, specifically vulnerabilities identification.

The robustness of the solution as well as the accuracy of the solution is what makes me look at Black Duck.

Compared to some of the other software in the world, Black Duck is extremely good at identification of licensing and open-source licensing, but it can improve on the security side of it, specifically vulnerabilities identification.

The initial setup of Black Duck is complex. It's not very straightforward. You need a lot of support and hand-holding from the Black Duck team itself for it to be deployed successfully across the organization. It cannot be done straight off the bat.

I have worked with Black Duck for the last 10 to 15 years, but I have not worked with FOSSA yet.

The stability of Black Duck is pretty good, rating around 8 or 9.

I would rate the scalability of Black Duck 8 or 9. It's pretty high.

I would rate technical support from Black Duck as nine. It's very good.

Positive

Before using Black Duck, I explored multiple other solutions. I looked at FOSSology, which is open-source, as well as Palamida. These were all explored before I started using Black Duck in one of my earlier organizations.

The initial setup of Black Duck is complex. It's not very straightforward. You need a lot of support and hand-holding from the Black Duck team itself for it to be deployed successfully across the organization. It cannot be done straight off the bat.

I haven't faced any challenges when integrating Black Duck into the software development life cycle. Anytime you take an open-source identification software system which works on a CI/CD pipeline, you encounter the usual problems that every company and solution will have. Nothing extra specific or special for Black Duck.

I have seen and also not seen a complete ROI from using Black Duck, depending on different organizations. It depends on how you use it. If you're going to use it in the functionality of merger and acquisitions for your target acquisitions, it helps significantly to figure out exactly what you are getting. If you're using it on critical external programs where there is regulatory compliance on ensuring that the source code is clean from open-source, there's substantial ROI. However, in general work and code development, it's not very easy to gauge ROI directly.

Before using Black Duck, I explored multiple other solutions. I looked at FOSSology, which is open-source, as well as Palamida. These were all explored before I started using Black Duck in one of my earlier organizations.

My deployment of Black Duck will take a few hours minimum. In the earlier on-premise scenario, which I've seen in other organizations, it takes a few days because you have to get the server installed, then actually keep installing various patch upgrades as it happens. The cloud version is a lot faster, probably taking only a few hours to complete.

Regarding Black Duck leveraging AI to enhance security scanning of open-source components, I would not be able to address that because I have not yet explored that area significantly.

Based on my experience, I would recommend Black Duck to other people if they can digest the higher cost. It helps in many aspects.

I would rate this solution overall at 7 to 8.

Disclaimer: The review is provided in personal capacity as an individual and not the opinion of the organization or corporate to which I belong to.

I recommend Black Duck for teams that need to identify their software components. It provides visibility for software components, their security risks, operational risks, and license compliance.

The automated code scanning feature and Black Duck's integration with our development tools have enhanced our software compliance process and overall audit readiness.

The software composition analysis is most effective for security risk management. It provides insights into legal issues, security risks, operational risks, and license risks.

There are areas for improvement such as false positives and the scanning of containers. The ability to export the mitigations that are provided is needed, along with improvements in reporting capabilities.

I have been working with Black Duck for seven years.

Their technical support is good. That said, there are some pain points with the response time and first-level support quality.

Neutral

I have not worked with anything similar before Black Duck.

There are many new tools based on specific technologies that could serve as alternatives.

I recommend Black Duck for those using native languages like C and C++. However, for new technologies, there are better tools available.

I'd rate the solution six out of ten.

We use the solution for open-source security management. The product connects the entire customer entity into DevOps and DevSecOps. Solutions like Black Duck and Code Dx enable application testing and onboarding of different applications from entities for security. All the users in different entities have access to the product. They run it by themselves and come to us with their findings. Our security team helps them take action.

The product enables other applications to be secure. We use it to onboard 400 to 500 applications into the DevOps platform, protect them, and have a secure environment. The tool integrates well with different technologies, application stacks, and databases. The APIs are available. We can read the blogs in the community for open-source compliance and security. The community feeds are important. Black Duck is a leader in Gartner. It is a reliable solution.

The solution must provide more open APIs.

I have been working with the product for close to two years.

I rate the tool’s stability an eight and a half out of ten.

I rate the tool’s scalability an eight out of ten. The solution is suitable for enterprises.

The initial setup was easy. I rate the ease of setup an eight out of ten. The deployment takes close to two weeks.

The pricing is a little high. I rate the pricing a seven out of ten. The average price of the product is close to $100.

I will recommend the product to others. It has in-built use cases for different verticals of the industry. Overall, I rate the tool a seven out of ten.

As a DevOps engineer, I am supposed to integrate Black Duck in my CI/CD integration and deployment pipeline. The product teams in my company do a vulnerability scan of our products before we make them available in the market. From the product team's perspective, they check the vulnerability according to the scanning process done from pipelines. My company has a YAML script with which we add the stage, and from there, it gets integrated.

The UI is the solution's most valuable feature since it allows for easy pipeline integration.

The only thing I don't like about the product is that it is quite expensive and it is not very feasible as an open-source platform. One of the other things that I hate about the product stems from my dislike of contacting the support team of Black Duck to know if there are some issues since debugging some issues can be quite difficult. I don't find reliable or feasible documents to help me debug all those issues. The solution's pricing model and documentation areas of concern where improvement is needed.

In our company, we get some issues or errors when we run a pipeline, and debugging those errors can be tedious and time-consuming. To minimize the time for debugging errors, I feel that Black Duck needs to add some documentation or something that will make it easy for users to debug the errors instead of seeking help from Black Duck's support team every time.

Black Duck can add features, like viewing the vulnerability, to help users figure out the next step if they detect some vulnerability while also providing them some steps to help them follow some remedial steps, along with an explanation of measures to mitigate such issues. Black Duck's UI or server doesn't provide functionality to help users view the vulnerability, which is a process that needs to be automated.

The solution's scalability is an area that needs to improve.

I have been using Black Duck for a year. My company is just a customer of the solution.

Stability-wise, I rate the solution a seven out of ten.

Scalability-wise, I rate the solution a seven or eight out of ten.

There are around 30 to 50 users of the solution in my company.

I need to wait to get support since I need first to contact them via email, after which they get back to me. The entire process of getting technical support can be made easier if the chatbot with which you can communicate and sort out the issues. Regarding the product's support team, I don't know why they follow a complex process since I feel that many things can be done in a more feasible manner.

I rate the technical support a six or seven out of ten.

Neutral

The solution is deployed on an on-premises model since my company has its own network.

I rate the product's price one on a scale of one to ten, where one is a high price, and ten is a low price.

My company does vulnerability scanning of its products, so I was evaluating if any open-source products are available in the market to help my company with the vulnerability scanning process. I found comparisons between Black Duck and Snyk.

I recommend Black Duck to those who plan to use it.

I rate the overall product a seven out of ten.

For scanning purposes, we use Synopsys Black Duck.

Primarily, we use it to ensure all our projects go through Black Duck scans. We do this sometimes via source code analysis and sometimes via binary analysis/Docker analysis. It figures out third-party components, any security vulnerabilities, and more. 

Our primary focus is security – it also flags operational vulnerabilities, like outdated software versions or lack of active maintainers, but we generally don't give those as much weight.

We use Black Duck for open-source compliance in our software projects.

We didn't have a central inventory to quickly identify issues or determine how many products were affected. Now under Black Duck, it's all consolidated. You search for a component and immediately see which products use it.

For example, one product might use the latest version and be unaffected, while another uses a deprecated version with vulnerabilities. We can then address these vulnerabilities within our SDLC. A rescan confirms the fixes, ensuring we're protected.

Black Duck also tracks historical data, showing which product versions have specific dependencies. If a newer version is released without those dependencies, the history reflects that. This provides a view of vulnerabilities across versions.

Moreover, the integration with our development is pretty straightforward. Since we use more of a SaaS tool, all we need to do is get the right token, and use the detect tools for our initial implementation. 

Black Duck handles all dependency downloads automatically, and you just have to run your script. They provide changes in plugins and everything, so it's really easy to integrate it into our pipeline.

I like the easy recommendations for fixes – knowing which version has addressed a vulnerability – and the ability to do source mapping. We find the vulnerability, and it will tell us exactly which line or file is affected. Even with transitive dependencies, it rolls up to the specific dependency in your code, showing the full chain.

This is crucial because, with hundreds of dependencies, it becomes difficult to pinpoint the issue if they're indirect. The dependency tree visualization in Black Duck clarifies which dependency has the vulnerability, allowing us to address updates effectively.

So whether we do it via binary scan or port scan, it's all about identifying which dependency or transitive dependency is affecting our overall product capability.

It's still a bit inconsistent. For example, sometimes a scan might reveal components or vulnerabilities, and the next day they might not show up. There's a lack of consistency at times. Of course, this could sometimes be due to new vulnerabilities being identified in the public domain after a scan. So, consistent inputs and more streamlined dependency management are needed.

It doesn’t clearly show whether vulnerabilities are from direct or transitive dependencies. A clear classification between direct and indirect vulnerabilities is crucial. 

If I'm looking to improve my product, I need to know out of 'x' vulnerabilities, how many are direct dependencies. With direct dependencies, I can take action, like replacing a component. But with transitive dependencies, we are helpless at times. Often, we have to raise exceptions and work around them. A clear classification between direct and indirect dependencies is something I'd like to see improved.

I have been using it for three years now. We use the SaaS version, so it's the latest one.

There are likely multiple teams here, each with their own token, including anyone accessing it from QA or their website, so there would be many users.

So, there are around a hundred end users. 

Since Synopsys manages it, we don't even handle the deployment. They just provide us with a deployed version.  

It's integrated with our AD. Now, all we need to do is log in with our ID account, and they've set it up solidly for us. A trouble-free solution. Basically, nothing to deploy.

We use the SaaS version provided by Synopsys, which they maintain. We do not intervene with it.

We have a separate team that takes care of license compliance.

Overall, I would rate the solution an eight out of ten.

I use Black Duck to detect vulnerabilities in open-source software before integrating it into my project.

The most valuable feature for me in Black Duck is its ability to scan binary files effectively. Many other tools on the market struggle with this, either unable to verify properly or providing inadequate results. With Black Duck, I can compare the data accurately.

I would like to see improvements in Black Duck's reporting capabilities. While the reports are useful for developers, they may not cover all the necessary aspects for certain customers, like those in security or government settings. Enhancing the clarity and comprehensiveness of the reports would make Black Duck a better tool overall. Additionally, I would suggest adding more report export options, like PDF or offline formats, to make sharing easier. This would help when sending reports to teams who can't access Black Duck directly.

I have been working with Black Duck for two years.

I would rate the stability of Black Duck as a ten out of ten.

Black Duck is scalable for various environments, including laptop setups and CI/CD pipelines like GitLab, GitHub, or Jenkins. It integrates well with bug-tracking tools like Jira and provides necessary reporting capabilities, making it suitable for different scalability needs. We have approximately 50 users of Black Duck at our company.

Tech support from Black Duck is great. I can easily connect with the technical team through the community site or email, and they help resolve issues.

When comparing Black Duck with competitors like SonarQube and Checkmarx, I find Black Duck to be superior. It is easier to deploy and scale, and it boasts a comprehensive vulnerability database, making it a better choice overall.

The initial setup was simple.

Black Duck is a bit expensive.

I use Black Duck's compliance management capabilities, and they are very helpful. I integrate Black Duck into my CI/CD pipeline and use it to create compliance tools. This helps me block code from other developers if it doesn't comply with my standards.

Integrating Black Duck into my IT environment was straightforward.

Overall, I would rate Black Duck as a nine out of ten. I would recommend it to others.

In terms of advantages, Black Duck offers a big database.

From a customer satisfaction point of view, I am not satisfied with the product. I am also not satisfied with the documentation part of the product. If you want to use the tool, you will have to indulge in self-learning. In terms of customer interaction, I read the product three out of ten.

If you provide a feature in a product, either you should provide training to customers or provide clear documentation with an example of how to use it. The aforementioned aspect is not covered by the solution. You get no response from Black Duck's end if you ask for support to help you deal with the features provided by the product, which doesn't work even though the documentation claims that its functionalities work. The tool's team provides a reason that doesn't even closely relate to the problems faced by the user. In general, certain features in the product don't work. The tool's documentation and support are areas of concern where improvements are required.

I have been using Black Duck for four years. I am a customer of the product.

I have experience with FossID and FOSSA. There are good products available in the market, and I would only be able to choose them based on my company's decision. From a user perspective, Black Duck is not viable for an organization since you cannot rely on a tool that offers not-so-good support or documentation. In the near future, I believe that my company should switch over from Black Duck.

My company does not take care of the installation part of the tool, as it is something that is taken care of in the cloud. The cloud option of the product is always available and a positive aspect of the solution.

The price charged by Black Duck is exorbitant. For the features provided by the product, I would not want to pay a high price. There are many other products in the market that offer better features and support services compared to Black Duck at a lower cost.

Even though my company is ready to pay extra charges for additional support from Black Duck, if a feature is given in a product and if it needs to be used by a user, then proper training and good documentation should be made available by the solution. If a certain set of users want to purchase a product, I believe that the solution should not charge them extra to teach them how to use the tool. A product can charge for the customization requested by users so that the tool is able to meet their specific needs. If a product offers a feature and somebody wants to use it even though they don't know how to use it, it is not acceptable for the solution to charge such users for training on how to use the tool's functionalities.

If there are other products with a better database, then my company would prefer to move to such tools.

We use the solution to detect non-compliance in third-party applications.

I really like the fact that we can define policies at a group level. Based on the foundation we create on the baseline, we can apply specific policies for specific teams. We can apply the same policy to the entire organization and tailor the policies for different teams. Policy management is a valuable feature.

I also enjoy using the license management feature in which we can add or review the terms of the licenses. The component management feature is also good. Black Duck is quite powerful. It has been in the industry for quite a lot of time, for around 30 years.

The documentation is quite scattered. It's really difficult to identify the documentation we need for a specific need. When I was working for an organization, I had to create my own documentation to establish the service for the group. The solution must make it easy for the users to understand what to do when they are getting started.

I have been familiar with the solution for a year, including the demo period.

The solution was pretty stable. We had some issues here and there.

The product is pretty scalable. It depends on the licensing model. We had negotiated a license model that was fit for our needs. Then, we added more applications as we grew. The tool provides both the on-premise and the cloud solution. We chose the cloud solution. We wanted the tool for internal use within our organization. We had more than 250 business units.

We have had a chance to benefit from expert hours with proper engineers who were able to respond to some questions. Some of them were more competent than the others. I'm satisfied with support on average.

Neutral

The initial setup is moderately hard because the documentation is not available. If someone is gathering the documentation and creating custom documentation for the organization, explaining how to connect to the CI/CD pipeline and create an account and everything in between, then it's not difficult. The initial investment in developing the documentation is quite tedious.

We provide an initial onboarding period of two weeks to the deployment team. The team can deploy the solution at its own pace, provided it follows the documentation. The team also has early life support throughout these two to three weeks, in which the team members also get trained and understand how to make the best of the tool’s features.

The deployment time depends on the organization’s application architecture, where they keep their projects, and how they are organized. These variables can extend or decrease the timeline for implementation. We need one or two technical resources to deploy the product.

We paid for the license on a yearly basis.

I have evaluated several other solutions, including FOSSA, but we didn't go forward with them. We chose Black Duck because it has a very strong knowledge base with a lot of customization around license management, component management, and policy management.

Organizations that enter a contract with Synopsys must be very careful about the expert hours. We would need support even if we do not have a premium contract. The expert hours are quite pricey. Whoever enters a contract with Synopsys should secure some expert hours because they will need it at least initially when they establish the system.

It wasn't that easy for us to onboard. It was a very steep learning curve. I was expecting more support from the vendor during the onboarding. I expected they would drive the onboarding since it was my first time using the solution. Instead, we had to discover a lot on our own as a customer. They provided some onboarding materials and training, but we were not hand-held through the process.

Overall, I rate the tool a nine out of ten.