Mend.io Reviews

Mend.io is integrated into our CI/CD processes. Our primary tool for CI/CD is Concourse CI, where all development teams incorporate Mend into their pipelines. In addition to Concourse CI, some dozens of our Dev teams utilize Jenkins, GoCD, and TeamCity, along with integrations for Azure DevOps and AWS Code pipelines. Our environment generally features a variety of tools from the GitHub ecosystem and supports several programming languages tailored to specific use cases.

Mend.io has played a crucial role in lowering our vulnerabilities and has provided valuable education to numerous developers, fostering a transition from a lack of awareness to a focus on security. It has enhanced the understanding of the importance of addressing dependency vulnerabilities early in the software development lifecycle (SDLC), while also promoting a cultural change that has resulted in both measurable and unmeasurable advantages in managing and recognizing vulnerabilities.

Earlier, Mend was used as a tool behind the scenes for periodic vulnerability checks. It was more reactive. We only began exploring its full potential once we started integrating it with GitHub because that helped us control, and manage the process. It centrally controls all the code going into production. We have built-in rules against the license policy vulnerabilities. We don't allow code to go to production if it hasn't met those criteria.

Mend has a SaaS environment where all the data is stored, but we do all scanning and remediation work on a component that scans and identifies dependencies. It can be deployed on-prem or on the cloud using their containers. Then, it talks to the SaaS platform for the final identification of vulnerabilities and license composition.

They have also devised a smart tree containing other tools we plan to evaluate. We haven't used their SAST solution yet, but we're considering it and comparing it to the other SAST tool we use. We use Mend Renovate, which was previously an open-source product. The merge confidence feature is part of Renovate feature. Most of our people are focusing on vulnerability remediation. It gives an excellent idea about how we can move forward with a change. 

Mend is deployed on the AWS cloud, and we have multi-region enabled. It is deployed active-active in both regions. This is a heavy implementation. The company has a centralized GitHub platform where every developer and team manages their code. There are more than 5,000 users. Changes appear in the report, and actions are happening internally based on that. They may not all be going to the Mend platform to see these results. There are only maybe 5,000 active commits happening monthly. The number of records per project enabled for our company is nearly 60,000. 

Mend has reduced our open-source software vulnerabilities and helped us remediate issues quickly. My company's policy is to ensure that vulnerabilities are fixed before it gets to production.

Mend streamlined our release process and improved the quality of the code we used during the production. When we had incidents recently, Mend's reports helped us determine the impacted components and remedy the issue quickly. 

We have quite a bit of open-source in our various products and what we went to Mend (formerly WhiteSource) for was to help us with OSS visibility and OSS governance. 

First, it's able to discover with a very good degree of accuracy what OSS we have in our products. Second, if any of the versions of that OSS are either out of date or have open security CVEs against them, the product will surface that and it will enable us to do remediation and track trends over time.

A lot of these functions are development muscles that need to be baked into the actual SDLC process. We can put this on our pipelines and ensure that all builds go through it. If anything is introduced, the central team is aware and we can go back to the product teams and hold them accountable to make sure they remove it. 

If there are areas that they're not considering in their plan and we see multiple releases go out and the numbers don't move in terms of potential vulnerabilities, we can go back to them and strongly encourage them to adjust their roadmaps and take security more seriously. It helps our organization improve as it makes those issues transparent.

We are using Mend to detect and fix vulnerabilities in our products and we also use it to deliver security reports when we are releasing our products. 

Since we moved to Mend.io, a long time ago, everything has been fully automated and we are saving a lot of time. When it comes to MTTR, we are saving three to four weeks of work over the course of a year. We release our product multiple times a year and we have to check everything in terms of licensing, et cetera.

Mend also has a lot of automation, such as raising pull requests on your code to implement updates. That's a pretty significant gain for our company, not having to manage that anymore.

In addition, since we started using Mend.io, we have been able to deliver products without any high CVEs. For medium CVEs, it's up to the team developing the product if they want to remove all of them or only the critical issues. We have four or five products and Mend.io detects between 20 and 25 high CVEs per month. We solve them because the solution is detecting them.

We use Mend especially for code analysis. I work in the application security part of my company. Developers will build and push the code to the GitHub repository. We have a build server that pulls in the code, and we are using Jenkins to automate that to do the DevOps stuff.

Once the code is built, we create a product for that particular version on Mend. We are currently working with three different versions for our particular product. We have the products created on Mend via White Source, which has a configuration file and a back file that runs. The configuration files basically tell what parameters to use, which server URL to use, which files to ignore, and which files to use.

For example, if I just have to do Python, I can make changes in the configuration files in Excel to include just .py files and exclude all of the files. If I have to do Python and C++, I can make changes in the configuration file itself to make .py, .C++ and exclude all of those. Once that configuration file is ready, then we run a White Source back file that just connects to the server, contacts the configuration file as well, does the scan on all the files that are there in the project, the project being for, and then pushes it to Mend, our Mend page.

On our Mend page, once we go into the product page of it, we can see what libraries have been used by us and what have some vulnerabilities. We also can set policies on Mend. We set some policies for our organization to accept and reject. For each product, we also get the policy violations that the libraries go through and any new versions for any new libraries that are available on that library's parent page - the parent page being the official developers of the library. We can get the new versions as well. We get the licenses we use with the library, and most importantly, we get vulnerability alerts regarding every library we use in our code.

Once the code is pulled, scanned, and pushed, we get the UI. We go to the library alerts. Once we go to the library alerts, we can see the different severities and the different libraries with vulnerabilities. We normally just sort according to higher severity first and go down to lower severity. We check what can be ignored or what is acceptable and what cannot be ignored, and what is of high priority. Ones that are a high priority, we flag and create a ticket on JIRA. That's our platform for collaboration.

Once we create a ticket for JIRA, the developers can see it, the QA team can see it, and they will go through that as well. They can tell if the update or the upgrade of the library is possible or not. They'll check its compatibility and see if it's actually doable or not. If it's not doable, they'll just tell us it's not doable, and probably our next version of the application will have the changes - not this one. We term that as acceptable or within our domains of acceptance. However, daily, if a JIRA ticket is created, the developers get back to us saying yes or no. Mostly they can say yes to changing the library to upgrade the library. If it's upgraded, they upgrade it to the next version. We scan it again. We do a weekly scan. We'll just check the next week if that particular liability is upgraded and the vulnerability has been remediated.

The vulnerability analysis is the best aspect of the solution. It’s my main go-to.

We can't do static code analysis ourselves; it's manual. That's a lot of manual tasks to handle. It's close to impossible to do that. That was a lot for static code analysis of our projects, alerting on vulnerabilities whenever it's possible. Whenever there's a vulnerability available, Mend does that. It vulnerability analyst is a report as well with how many high vulnerabilities, how many medium, how many lows we got, and how many accepted or how many are without any vulnerabilities basically.

I see a lot of it is pretty good and has a high level of trust.

It’s stable and easy to set up.

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.

Mend is a SaaS solution we use to make open source libraries for our products. It covers license usage, license type, and CVE vulnerabilities. We use Mend at our Belfast office, but a subsidiary in Norway also has access to it. There are 67 users at our company. About four are admins, and the rest are developers. 

When talking about security, improvement is hard to measure. We haven't had a security breach yet, and it's probably because we use products like Mend. We would know if it wasn't working. However, I can say that our security posture is excellent because we can address the vulnerabilities Mend reports.

It improved our mean time to resolution, but I can't give a precise figure. The primary benefit is that we no longer download vulnerable libraries. In the past, there wasn't a way to identify them. But based on the number of vulnerabilities in there (and we still have a lot of vulnerabilities in there) I would say it reduced the MTTR by around 70 percent. 

I would say it reduced the vulnerabilities in production by about 80 percent. When we have a release or run the script, it automatically picks up the vulnerabilities. 

We are a law firm, however, we do write some of our own software. Sometimes that software is integrated with our systems and sometimes it's bespoke software for clients. We write code with C#, JavaScript, and more, and we use a lot of third-party libraries. We need to check these third-party open-source libraries for vulnerabilities and go through a process of looking at various tools in the market.

WhiteSource stood out mainly for the way it approached scanning code. Some of these solutions often send the code somewhere else to be scanned, whereas WhiteSource allows us to scan wherever our tenant is. The reason we chose this solution was to look at the security analysis of these third-party libraries.

The way WhiteSource scans the code is great. Being a legal firm, we're a bit more sensitive around our data, and we didn't want that going to different regions. With WhiteSource we can keep our data in the same data sovereignty as it was. That is a big deal for us. In terms of the analysis it can do, it is really useful. This was new to us as an organization, as not only can we find vulnerabilities, but we can also look at the license distribution.

We can understand the open-source licenses, which come with some constraints. That's something we wanted to avoid. Recently, there was a log4j vulnerability that was very prominent in the security community, and we were quickly able to see if we were using it and where. That's the inventory side. It was really useful in that respect.

It’s easy to identify and remediate open source vulnerabilities using this solution. There were a couple of times when something was reported as a vulnerability. When we looked into it a bit more and we talked with the WhiteSource support staff, we found that it was caused by something else. That's pretty rare. Most of the time, it's fairly clear. It says you need to go from one version of the library to another version of the library. It's pretty plain and works well. There have been just a couple of occasions where we needed to dig a little deeper.

Tech support has been very swift and helps us understand false vulnerabilities and they make sure that they don’t happen again in the future. They've got a good support system.

We can detect the vulnerabilities in the SaaS tool itself. We can go to our particular project and see them, or we can see them when we run the code. We can run the tool locally. Even before we scan the code, we can perform a local scan and that's been pretty useful for our developers. It is certainly useful that the vulnerability is displayed both in the WhiteSource platform and our CI/CD tool of choice. We use it as DevOps, and we can see the results with that tool as well. This means that we don't have to use another tool.

WhiteSource helped reduce our mean time to resolution since we adopted the product. More than anything else, it's just shining a light on the work we need to do. We had a lot of legacy code that no one had really explored the software composition analysis on it. The main value is that it showed us what we needed to fix, and with the dashboard security trends feature, we can see over time if we made progress. We had a way to report upward and show our progress. From that respect, it's been very valuable.

The product has helped reduce the number of open-source software vulnerabilities running in our production. It would probably be quite a high number as we didn't really have anything before. I would probably say that we're about 70% through remediating all of the vulnerabilities. This is a good number since nothing existed before.

We've introduced policies as well. If we just rely on good intentions, often people don't follow through. If we have a policy set that makes developers have to stop and fix something, it breaks their workflow in a positive way as it's saying that these are high vulnerabilities. It allows us to set up quite nuanced policies. That has been really useful. Without that, it'd be less effective as a tool.

WhiteSource's portability to integrate with our developers' existing workflows including their IDE, repository, and CI/CD pipelines, is good. It's improving all the time. In terms of integration, it's pretty easy.