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.

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. 

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 did not have much security compliance implemented in our solutions. Whatever we did, we had to use the AWS built-in OWASP scanning, and we had to manually find out the versions of the open sources that fixed the issues of vulnerability. We then had to make sure that that updated version is sent in and code merged for a test. We found sometimes it took a lot of research to make sure that the version that we are upgrading to did fix the issue, et cetera. However, this is all manual research and is dependent on the knowledge of the developer or the engineer who did this work. It took time and did not ensure a high percentage of security compliance. With WhiteSource in place, we are going to be able to do the whole process automatically and it will be confident that we removed the vulnerabilities and license violations.

We are saving time that we spent on resources because we no longer have to do it manually. We will now have confidence that there are not many errors made.  We are able to do much more vulnerability fixing than we did manually, there are cost-savings, and less work involved.

It saves a lot of money with early fixing. If you can figure out an open-source bug earlier, rather than in production, it can save a lot of, almost 100 times, cost.

It also helps with post-production management because it gives alerts on new vulnerabilities.

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. 

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 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.

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 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.

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. 

WhiteSource is very easy to run and use. It reduced significantly the time our developers used to spend on issues in open-source libraries. We used a free tool before and the number of alerts was too high to handle.

We recently implemented WhiteSource on our Github account.

It provides our developers with better visibility into open source libraries within their code environment, which helps the company in ensuring dev adoption.

When it comes to open-source licenses, it really simplified reporting as it provides an inventory list in a simple report. Before WhiteSource it was almost impossible, mostly due to transitive dependencies.

We were able to integrate the product naturally into our development process and it provided results really fast. You can easily use the unified agent and connect your CICD tools. It scans all of your source code quickly and it took us just a few minutes to run. The REST API is really good as well.

In the past, running similar tools or trying to get feedback on our open-source state was almost impossible.

Our primary goal was to get the license reports, but now we have a full end-to-end process that automates all license management, open-source license approval, rejection, ticket assignment, and more.

To prevent shipping commercial or GPL libraries, we scan our repositories.

We find licenses together with WhiteSource which are associated with a certain library, then we get a classification of the license. This is with respect to criticality and vulnerability, so we could take action and improve some things, or replace a third-party library which seems to be too risky for us to use on legal grounds. Then, we can take some measures to improve things, replace a library, or update a library which was too old or showed severe bugs, etc.

WhiteSource improved our team’s ability to deal with vulnerabilities in a timely manner. Most of the time the alerts pile up and no one wants to deal with it, but the process now is much more simplified and convenient. It is still a task, but the service reduces the time spent on it significantly. It is very easy to use and the research decreased to almost none.

The GitHub integration provides us with the option to prevent security issues related to our open source libraries pre-build. It helped our teams discover vulnerabilities before usage, and fix issues within our existing environment and workflow.

In general, we are covered for open source licensing issues and CVE errors on particular versions for open source dependencies. Moreover, we have covered ourselves for security auditing by stating that we are users of WhiteSource.

With WhiteSource, we have been able to automate the scan of our Open Source dependencies. Before, it was a 50% automated in-house solution.

At first, WhiteSource was great in regards to have a clear picture of what we use in our products.

Then later, we started having different issues with WhiteSource, especially in our containers/Docker images. The problem has not been resolved yet, even after many followups on this matter.