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.

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. 

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.

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. 

We have started the trial version of WhiteSource last week. We concluded the trial this week and we are beginning to use the full licensed solution later on in the week.

We use WhiteSource for automating open-source vulnerability, by finding the open-source libraries that were used and fixing them. Additionally, we set up policies to disallow some of the risky open sources to be used in our solutions by developers. We are able to scan and fix vulnerabilities in our containers, to ensure that if there are any licenses that violate the open source usage or put our product at risk, we make sure that either we remove or remediate the open sources with risky licenses. Those are the main three use cases.

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.

It is used to manage open-source associated risks. I'm a consultant, and I provide consultancy and management services in the domain of open-source risk management. I use this product as a part of the services to my customers. I'm not using it in my company because my company is not developing anything.

Its deployment is hybrid where scans are on-premise and the knowledge base is on the cloud.

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. 

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.

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.

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

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.

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. 

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.

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.

To my knowledge, we are using the latest, SaaS, version. 

We use WhiteSource mainly to:

1. Detect and automate vulnerability remediation. We started to research solutions since our dev teams are unable to meet sprint deadlines and keep track of product security. Most of our code scans are automated and integrated within our pipeline, which integrates with our CI server. With some, we run them manually using an agent. We recently started using the repository integration with Github, too, pre-build.
2. License reporting and attribution reports. We use attribution reports and due diligence reports to asses risks associated with open-source licenses.

We started using WhiteSource mainly to scan dependencies and detect open-source licenses, copyright information, and vulnerabilities.

We’ve managed to establish an integration with our CICD pipelines and use pretty much all of the automation that is offered, including automated policies.

Our primary use is to find all the third-party libraries and open source libraries which are hidden in the software, such that no third-party libraries are forgotten.

1. To get an overview of all these third-party components.
2. To get some information from WhiteSource about which licenses are behind the third-party tool, and what implications these might have for us.

I use the solution for free and open source scanning. 

We use WhiteSource mainly to automate open source vulnerability detection and remediation, as well as for license compliance.

I’m less on the side of the license but mainly use the service to get control over vulnerabilities, detect the ones that affect us and remediate accordingly.

We integrate WhiteSource to our pipeline via CI server integration and now started using the GitHub integration too. We also run an agent in specific use cases.

We use this solution for scanning NodeJS and Maven projects during the CI/CD processes. We have hundreds of scans per day for any project that runs on our CI and passes the release build.

This means that any release build runs the WhiteSource scan before deployment to production clusters, which ensures that we are pretty covered in terms of licenses for open source dependencies.

We are running on top of hundreds of microservices and thousands of daily builds, of which part of them are moving to production deployment eventually.  

I use this solution for product inventory trace and 3PPs handling in aspect of License Compliance & Security.

I've been using both the UI & API.