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.
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.
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.
IT Service Manager at a wholesaler/distributor with 51-200 employees
Real User
2022-07-17T14:21:00Z
Jul 17, 2022
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.
Intramural OfficialIntramural at Northeastern University
Real User
2022-07-06T19:15:30Z
Jul 6, 2022
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.
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.
Architect/Developer at a insurance company with 5,001-10,000 employees
Real User
2022-05-12T11:02:45Z
May 12, 2022
We use WhiteSource for scanning open source libraries called SCA and both the vulnerabilities and open source licenses. We deployed WhiteSource with Azure DevOps.
Head of Software Engineering at a legal firm with 1,001-5,000 employees
Real User
2022-05-10T15:47:00Z
May 10, 2022
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.
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 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.
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.
Project Manager at a wellness & fitness company with 11-50 employees
Real User
2020-01-06T10:07:00Z
Jan 6, 2020
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.
Co Founder at a consumer goods company with 11-50 employees
Real User
2019-12-31T07:22:00Z
Dec 31, 2019
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 mainly to: * 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. * License reporting and attribution reports. We use attribution reports and due diligence reports to asses risks associated with open-source licenses.
VP R&D at a tech services company with 11-50 employees
Real User
2019-12-23T12:59:00Z
Dec 23, 2019
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.
Mend.io is a software composition analysis tool that secures what developers create. The solution provides an automated reduction of the software attack surface, reduces developer burdens, and accelerates app delivery. Mend.io provides open-source analysis with its in-house and other multiple sources of software vulnerabilities. In addition, the solution offers license and policy violation alerts, has great pipeline integration, and, since it is a SaaS (software as a service), it doesn’t...
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.
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 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.
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 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 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.
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.
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 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.
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.
To my knowledge, we are using the latest, SaaS, version.
I use the solution for free and open source scanning.
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.
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 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.
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 mainly to: * 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. * License reporting and attribution reports. We use attribution reports and due diligence reports to asses risks associated with open-source licenses.
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.
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.
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.