Mend.io Reviews

We have two primary use cases. One use case is to find the vulnerabilities related to the open-source libraries that are included in multiple products in our company.

The second use case is to find out whether the licenses associated are for general use or not, or whether there are any license-related restrictions. Sometimes, when you use open-source components, depending on the type of licenses, they may be applicable only for internal use. We use it to check whether we are violating any licensing or not.

Using Mend SCA, it is easy to identify open-source vulnerabilities, but it is not easy to remediate because there are multiple moving components or moving parts in a build frame or a small library, so the impact of one component can be different on different products. To identify open-source vulnerabilities, you just run a scan in your pipeline, but to fix them, you need to do multiple regression tests and check whether your application or product is getting affected by that upgrade or not.

Mend SCA has helped reduce our mean time to resolution (MTTR). Knowing a risk does not necessarily help us in remediating or fixing that vulnerability, but it helps at least in deploying certain compensatory controls so that we can take on the upgrade part later on. Our protection is deployed at the parameter level, at the system level, or at the network level. It has reduced our MTTR roughly by 20%.

Mend SCA has definitely helped us reduce the number of open-source software vulnerabilities running in our production at any given point in time. We have now started to break the build in case there are any high-level or critical vulnerabilities. Certain teams, not all, are now forced to fix them, which is why the vulnerability count is going down. There is about a 20% reduction in vulnerabilities.

The best feature is that the Mend R&D team does their due diligence for all the vulnerabilities. In case they observe any important or critical vulnerabilities, such as the Log4j-related vulnerability, we usually get a dedicated email from our R&D team saying that this particular vulnerability has been exploited in the world, and we should definitely check our project for this and take corrective actions.

I would like to have an additional compliance pack. Currently, it does not have anything for the CIS framework or the NIST framework. If we directly run a scan, and it is under the CIS framework, we can directly tell the auditor that this product is now CIS compliant.

I have been using Mend SCA for more than three years, and we started with Mend SAST this year in January.

It is stable.

It is a SaaS solution, so scalability is something that their teams need to handle on their side. Scalability is in their control, and we are just sending those results over there.

We have about 450 users. We only use the portal. We scan via a unified agent or a CLI component, and we have two extra components. We have the Chrome plug-in and the IDE plug-in. The best thing is that on the CI/CD pipeline that we are using, we only need to call a unified agent that does the scan and then posts the results on the dashboard or the portal. It is deployed at multiple locations and at multiple levels of our pipeline. We are using Gitlab Cloud, Bitbucket and Jenkins. We are using many different tools at different locations.

All levels of their support have very good technical knowledge. They know their tool better than us, so when we cannot find a solution, they give us that in 15 minutes. I would rate them a 10 out of 10.

Positive

I did not use any other solution previously.

It is a SaaS solution. I was not involved in its deployment. It was already in the company for six months when I got my hands on it.

In terms of maintenance, we just need to check which users have left the organization so that we can maintain the number of users under the license that we have purchased. That is a small thing required on our side even though we have SSO integrated.

We have seen an ROI. We were able to find vulnerabilities. If our products were not attacked by an external entity, we consider that as an ROI, but it is difficult to put a dollar value on that.

It is fairly priced.

Mend SCA is better than Mend SAST. They are a market leader in SCA. The adoption of Mend SCA and the scanning of Mend SCA are pretty good. It is one of the best solutions for SCA. It was already deployed for at least six months before I got this tool. At one point, I saw WhiteSource's name on the Microsoft website as a critical solution for open-source scanning, which made me think that this solution must be good if Microsoft mentioned it on its website.

Its adoption was very slow in the beginning. Three years ago, there was no awareness of using this solution, so we had to tell the team about what the solution is for, what are its advantages, how it impacts their product, and so on. The adoption is good now, and people know exactly what it is being used for. They know the types of vulnerabilities that are there. They know the types of features that are there. Earlier, they used to go through me for any support program, but now they are directly raising tickets depending on the priority of the ticket and then directly communicating with my support representative to fix them. The initial one and a half years were difficult. 

We are also using Mend SAST. They have a variety of different application security solutions in addition to SCA. These solutions are complementary. When you use solutions from different vendors, more diversity can lead to problems. When you have a Mend solution for SCA and a Mend solution for SAST, they are complementary, so the results of those scans would be far more helpful than having different vendors at each and every level. Diversification is good to a certain extent, but if you diversify too much, you might get a lot of false positives.

Overall, I would rate Mend SCA a 10 out of 10. It is definitely one of the best ones in the market.

We use open-source libraries or software in projects across our company. We conducted an internal study regarding the legalities, security, vulnerabilities, and license compliance, which is when we decided to implement and deploy Mend. It automates the software composition analysis, which is vital when we want to use third-party and open-source software. 

We have a total of around 1000 projects running in Mend; some of those are being trialed and may be withdrawn, and others will go on to the production stage. We have between 300 and 400 end users, primarily integrators and fewer admins and approvers.

The tool is now a mandatory part of our organization to use as a benchmark, giving us a technical advantage. When we acquire other companies, we look to determine if Mend is applicable to them and bring them into our culture of using the solution where possible. We can leverage it for financial benefits when implemented and used to scan on the technical front. We consider Mend a permanent integration with our company for the foreseeable future, so we decided to reinvest in the solution by renewing our contract twice up to this point.

I am the organizational deployment administrator for this tool, and I, along with other users in our company, especially the security team, appreciate the solution for several reasons. The UI is excellent, and scanning for security threats fits well into our workflow.

The solution is also highly valuable to our Intellectual Property Councils, because as a company that uses open-source software, we need to be aware of intellectual properties, code violations, and adherence to our regulations when we include such software. There are, of course, areas for improvement, but it has become mandatory within our organization to run scans using Mend as part of our workflows.

We don't always use WhiteSource SmartFix, and that depends on the recommendations provided by the solution's analysis. On occasion, we have challenged those recommendations, so for us, the software is not entirely a decision-making tool but a tool that assists us in making decisions. Therefore, there is still a human component in the process, and there is always an admin or approver to accept or reject the recommendation. There have been instances where smart fixes were challenged due to a lack of compatibility with project requirements. For example, the solution recommends a version of PostgreSQL, but the decision is made on the product level to go with a different version because it has better integration with the specific product requirements. However, I would say that SmartFix increases our decision-making effectiveness and successfully alerts us. As a leading lighting company, some product decisions must adhere to strict requirements, which require human involvement in the decision-making process.

Initially, the product didn't save us time but required us to spend more time. Many of our processes require a manual component, so we can't entirely rely on automated processes. Therefore, when we run Mend scans on our projects, around 60% of the software development life cycle is sped up, while the remaining 40% requires human intervention. Per our IP Councils, automation does not help us beyond a certain point, and manual intervention is required. If 60% of a project can be streamlined via automation, that certainly saves us time. 

I would say that Mend certainly helps us detect and reduce vulnerabilities. We bring in the solution at the very beginning of a project, so we build early and often and detect vulnerabilities early. This is a significant contributor to our projects' success. 

Integration using the unified agent and other methodologies has been at the forefront of our deployment. The plugins have been merged into the unified agent approach. The integration methodologies have worked wonders for our CICD pipelines and workflows, and each project team can decide whether to run scans pre or post-build.  

We have been looking at how we could improve the automation to human involvement ratio from 60:40 to 70:30, or even potentially 80:20, as there is room for improvement here. We are discussing this internally and with Mend; they are very accommodating to us. We think they openly receive our feedback and do their best to implement our thoughts into the roadmap.

I consider scan reports to be another area for improvement, but this is also an area of improvement for user management on our end. We need to train end users on how to deal with alerts and the best approach to take for new projects.

We have weekly meetings with Mend and encourage all users who integrate the solution into their product life cycle to attend. This has been very useful, as these technical meetings assist our staff in the best use practices and improving their interpretation of reports, which allows us to leverage the product to our greatest advantage. We are also able to ask for solutions adaptations to suit our requirements, as we produce hardware as a company, not virtual products. 

We have been using the solution for almost five years. 

The solution is highly stable; we had downtime on one occasion for two hours, which was scheduled. Aside from that, I haven't seen any downtime or performance issues, so in terms of stability, I rate the product very highly because we can depend on it.

The solution is scalable, and scalability is vital for such an integral piece of software. Software development scenarios can change fast, requiring support for new languages and apps, so we constantly learn and communicate with Mend to fulfil our fluid requirements and adapt to changes within our environment.

I'm delighted with the technical support, especially as someone involved in the deployment. Technical support has been highly responsive to bugs or errors, helping us mitigate or fix them quickly. It was easy to interpret their technical guidance, which made my job much more manageable. I'm very satisfied and would rate them highly.

Positive

We did not use any other solution.

The deployment was mixed; there's always a window in which we are required to adapt to a tool. This solution isn't an out-of-the-box kind of model. There was some fine-tuning involved in the deployment according to our needs and specific projects, which is expected but somewhat challenging nonetheless. 

The key staff involved in the deployment included me as the deployment manager, a customer success manager from Mend, a leading member of our IP Council, and the security advisers for each product. Once the deployment strategy is decided, the IP Council and security team take a back seat, and I work closely with the product architects moving forward. Deployment, fine-tuning, and getting the scans up and running takes two to two and a half days maximum per product. Ultimately, five or six key staff are involved in the solution's deployment, configuration, and maintenance. 

We have seen an ROI for our projects, and our project managers are happy. This could still be improved, however.

We always negotiate for the best price possible, and as far as I know, Mend has done an excellent job with their pricing. Our management is happy with the pricing, which has led to renewals.

We evaluated Black Duck, but it has several limitations that drove us toward choosing Mend. Black Duck is very expensive, and we require a SaaS solution to ensure the privacy of our source code, and they couldn't provide that. Therefore, our team decided to choose the more affordable and secure product.

I would rate the solution a nine out of ten. 

As a deployment admin, I would say the solution is straightforward to deploy, and deployment is simply the beginning of the process. Then comes the discipline of running scans along the life cycle of a project and deciding to accept or ignore the yielded alerts. This isn't a daily process, but it's an integral part of every project's workflow, and we have successfully made this an embedded part of our product development. Over time, our users have realized the advantages of using this software and appreciate the deployment.

Our staff must be open to change, especially when adapting to alerts and violations yielded by scans. Every scanned report has its interpretations and challenges, which is where input from the Intellectual Property team and Mend's technical team comes in. They support us throughout the product development process and help us calibrate our interpretations of reports. This gives us a clear picture of whether we are legally and technically conforming to our project and company requirements. 

I'm a deployment manager, so I don't know if the merge confidence feature is used, as I'm not involved in projects throughout the entire development cycle. Some teams may be using it, but I can't say with confidence.

We use the SaaS version of the solution, which provides full compliance when it comes to privacy. At no point can Mend view our source code, and we have a complete legal understanding with them.

We currently don't use any other products in conjunction with the SCA product because we are at the beginning of our exposure to these tools. We are in the process of evaluating the tools, and we have a relatively elaborate process. It's also essential to consider different tools fairly by comparing like with like and having consistent parameters for comparison. That process can take some time and requires some patience. These kinds of evaluations should not be rushed, and it's okay to take weeks or even months to determine if a new tool can be a commercial and technical success within an organization.

The integration with Azure DevOps was good.

The results and the dashboard they provide are good.

It was pretty straightforward for me.

I would like to see the static analysis included with the open-source version. That would be good.

I used the trial version of WhiteSource for a month. We chose to work with Veracode instead.

It's was pretty stable. I don't have any complaints about the stability of WhiteSource.

I did not have any contact with the technical support. I did not have any issues in the time that I used this solution.

It was approximately $2,000 per year or per month, I don't recall exactly.

When compared with Veracode, Veracode was very very expensive. It was approximately $200,000.00 per year for the whole Suite.

WhiteSource is much more affordable than Veracode.

We are evaluating Veracode.

It was pretty good. I would rate WhiteSource an eight out of ten.

We use WhiteSource for scanning open source libraries called SCA and both the vulnerabilities and open source licenses. We deployed WhiteSource with Azure DevOps.

WhiteSource is unique in the scanning of open-source licenses. Additionally, the vulnerabilities aspect of the solution is a benefit. We don't use WhiteSource in the whole organization, but we use it for some projects. There we receive a sense of the vulnerabilities of the open-source components, which improves our security work. The reports are automated which is useful.

WhiteSource only produces a report, which is nice to look at. However, you have to check that report every week, to see if something was found that you don't want. It would be great if the build that's generating a report would fail if it finds a very important vulnerability, for instance.

I have been using WhiteSource for a few years.

WhiteSource is a stable solution.

We have approximately 20 people using this solution in my organization.

I have not used technical support.

I have previously used other solutions, such as OWASP Dependency-Check, Snyk open-source, and CheckMark

The initial setup of WhiteSource is straightforward.

We did the deployment of the solution ourselves. We used one person for the deployment.

We have received a return on investment.

WhiteSource is a free solution to use.

We evaluated other solutions before choosing WhiteSource. We ended up choosing WhiteSource because of some of its unique features.

I rate WhiteSource a seven out of ten.

We needed a tool to ensure that we are not using vulnerable libraries or open-source libraries with a copyleft license. We integrated WhiteSource with our repositories and CI server and set up automated policies to reject copyleft licensed libraries because our legal department doesn't allow them. We also have it open Jira issues automatically when a vulnerable library is detected and assign it to an engineer so we can shorten our response time to vulnerabilities detected in our applications. It integrates nicely with our existing workflow.

The best thing is that it changed the mindset of our developers. They are now more aware and proactive when it comes to the security risks in open source vulnerabilities and the need to update packages from time to time.

It gives us full visibility into what we're using, what needs to be updated, and what's vulnerable, which helps us make better decisions.

The WhiteSource prioritization feature provides us with the greatest value as it has cut down the number of security alerts by about 90%. It is only relevant for Java and JS for now, but we understand more is yet to come. This has saved us a lot of time.

WhiteSource is very accurate and covers all of our languages (including C++).

WhiteSource Prioritize is amazing. If we are using a vulnerable library, it shows us if we are actually using the vulnerable method or not. This saves us a lot of time that we can instead invest in other projects.

It also does a great job of automating many activities we used to do manually. Now the system does it for us and it generates a great security dashboard that shows us whether our remediation velocity is improving or not.

WhiteSource Prioritize should be expanded to cover more than Java and JavaScript.
We are currently using WhiteSource Prioritize for Java and it cuts our vulnerability alerts by almost 90%. However, Prioritize doesn't cover python or other languages at this point and our developers are required to deal with many open source security alerts. The problem is that now our developers are aware that most open source security alerts are not impacting the security of their applications and it's harder to get their cooperation. We are waiting for WhiteSource to announce support ifor Python and other languages.

We have been using WhiteSource for almost a year.

From my experience, WhiteSource is pretty solid.

We had a problem with a new library that their engine didn't process. I wrote them an email and got a response within an hour. Two days later they added it to their system.

They provide accurate results and our customer success manager is great.

No complaints so far.

We tested Black Duck as well but detected quite a lot of false positives.

The good thing is that their product just keeps getting better. They are very attentive to their customers.

All in all, if you care about security, this product is a must. We all love open source, but I was always afraid of the headache in handling all the licensing/updates/vulnerabilities. The peace of mind we have now is a total game-changer.

We use WhiteSource to monitor our open-source usage. Specifically to avoid legal issues with open-source licensing, which may deter potential buyers or investors. Additionally, we analysed the code for security vulnerabilities.

We found the effective vulnerabilities report very useful since it lowered the number of actual defects found in the product and saved us a lot of work. Our environment is made of micro-services running in Kubernetes using NodeJS and Typescript for the backend, and AngularJS for the frontend. We use MongoDB, Redis, RabbitMQ, and ELK. 

WhiteSource allowed us to minimize our exposure to open-source vulnerabilities with ease. Aside from identifying the out-dated or compromised packages really easily, it allows us to actually see which vulnerabilities are effectively relevant for us. In this case, it saved us *A LOT* of refactors and redesigns of code, which would have been considered vulnerable otherwise.

We integrated WhiteSource into our build system to ensure we keep our code secure and don't introduce new problems as we go. This allows us to have more predictability into the work process as security now becomes a constant work-in-progress instead of a major bulk of work every now and then.

For us, the most valuable tool was open-source licensing analysis. Although we don't use it on a weekly basis, when we needed to produce a reliable analysis of our open-source licensing exposure, we found it very very effective. Considering the alternatives, which were to analyse manually, WhiteSource saved us a ton of work that we really needed to complete in a short time. It would have involved finding all the different packages, be them in package.json files or analyse the docker images, and then find their effective license, which in itself is not a simple task.

The agent usage was not as smooth as the online experience. It lacks in terms of documentation and the errors and warnings it produces are not always very clear. We were able to get it up and running in a short while by getting help from support, which was very approachable and reliable.

If anything, I would spend more time making this more user-friendly, better documenting the CLI, and adding more examples to help expand the current documentation.

I would also like to get better integration with Google Docs.

We have been using WhiteSource for a few months.

We did not use another solution prior to this one.

We did not evaluate other options.

Overall, this is a great product.

Our primary use for WhiteSource is security and license risk detection in open-source, third-party libraries and components. We run scans from multiple source control and build systems (TFS, ADO, Jenkins, ...). Some of our scans are automated, while others are done manually with the unified file agent in offline mode scan, and then the resulting "wsjson" file is uploaded to the WS SaaS portal.

We moved from Black Duck to WhiteSource as it was a more modern and scalable solution, with better integration support to various build and source environments. The ease of running scans and getting results quickly enables our developers to address issues quicker. 

The most valuable features of this solution are:

1. The vulnerability and license alerts are the main purposes of us utilizing this tool. We don't want to ship software and mistakenly include a GPL component. Similarly, we want to stay up to date on all vulnerabilities in third-party libraries so we can take action if our software solutions are impacted.
2. Implementing policies is helpful because it's great when certain "no-nos" can be codified as policies and auto-rejected.
3. Attribution and license due diligence reports help us with aggregating the necessary data that we, in turn, have to provide to satisfy the various licenses copyright and component usage disclosures in our software.

Places in need of improvement are:

1. Some detected libraries do not specify a location of where in the source they were matched from, which is something that should be enhanced to enable quicker troubleshooting.
2. Manual uploads of "wsjson" files can only be done by a global admin. Product administrators should be given this right for uploading files to their products/projects.
   
3. Better support for proxies is needed when running the unified file agent behind a proxy. It can be made to work, but the Java proxy config and cert trust for MitM traffic inspection are very painful to set up.

We have been using WhiteSource for two years.

In our two years of usage, there has been a negligible amount of downtime. We have, however, experienced occasional issues with certain features of the offer that created some friction and grumblings from our devs using the portal, but those have typically been resolved fairly quickly. 

This is a SaaS offering that has so far taken everything we have thrown at it (150+ products, with multiple projects in each). Certain reports that aggregate data globally could take a while to churn, but well within acceptable time-frames.

Responses are quick; TS works hard to resolve issues quickly. 

Prior to this solution, we used Black Duck. As of two years ago, when we made the switch, WhiteSource's UI was more modern, the SaaS solution more scalable, and the integration capabilities far superior. The detection accuracy between the two was quite similar. 

Setting up the tool for automated usage is very straightforward. Follow the documentation carefully and you will likely be fully up and running in between 15 and 60 mins.

We implemented this solution using our in-house team.

Pricing is competitive.

We also use NPM Audit and Snyk, but as an augmentation; not as competitors. 

Our primary use for WhiteSource Bolt is to gain visibility over third-party libraries in order to perform vulnerability assessments and take care of licensing issues.

We are using this solution within our Microsoft Azure tenants. Essentially, we are using it in a private cloud.

The most valuable feature is the inventory, where it compiles a list of all of the third-party libraries that we have on our estate. This helps us quite a bit.

We specifically use this solution within our CICD pipelines in Azure DevOps, and we would like to have a gate so that if the score falls below a certain value then we can block the pipeline from running. This would give us some sort of automated assurance. This is probably the feature that we'd most like to see.

Generally, the stability is pretty good. The only thing we have noticed in the past couple of weeks is that it's been quite slow at times. We are reaching out to them over the issue.

We haven't deployed it on a massive scale so we may not be able to judge the scalability. We run through perhaps ten deployments in a day, and we have not seen any issues.

We use this for anything that gets deployed, which is every pipeline that we run through our CICD.

I haven't needed to engage with technical support for this solution.

For this use case, we did not use another solution prior to this one.

Given that it is a cloud-based solution, it is really easy. The deployment takes a couple of minutes.

The version that we are using, WhiteSource Bolt, is a free integration with Azure DevOps.

We are still evaluating at the moment, and have not officially adopted WhiteSource as of yet.

For anybody who is researching this type of solution, my suggestion is to try them first. We tried quite a few of the various toolings available, and some of them are just not workable. They're very different on paper, so you have to use them to really compare them.

I would rate this solution a seven out of ten.