Sonatype Nexus Lifecycle OverviewUNIXBusinessApplication

Sonatype Nexus Lifecycle is the #2 ranked solution in top Software Composition Analysis (SCA) tools and #4 ranked solution in application security solutions. PeerSpot users give Sonatype Nexus Lifecycle an average rating of 8.0 out of 10. Sonatype Nexus Lifecycle is most commonly compared to SonarQube: Sonatype Nexus Lifecycle vs SonarQube. Sonatype Nexus Lifecycle is popular among the large enterprise segment, accounting for 75% of users researching this solution on PeerSpot. The top industry researching this solution are professionals from a financial services firm, accounting for 26% of all views.
Sonatype Nexus Lifecycle Buyer's Guide

Download the Sonatype Nexus Lifecycle Buyer's Guide including reviews and more. Updated: November 2022

What is Sonatype Nexus Lifecycle?

Sonatype Nexus Lifecycle is an open-source security and dependency management software that uses only one tool to automatically find open-source vulnerabilities at every stage of the System Development Life Cycle (SDLC). Users can now minimize security vulnerabilities, permitting organizations to enhance development workflow. Sonatype Nexus Lifecycle gives the user complete control over their software supply chain, allowing them to regain wasted time fighting risks in the SDLC. In addition, this software unifies the ability to define rules, actions, and policies that work best for your organizations and teams.

Sonatype Nexus Lifecycle allows users to help their teams discover threats before an attack has the chance to take place by examining a database of known vulnerabilities. With continuous monitoring at every stage of the development life cycle, Sonatype Nexus Lifecycle enables teams to build secure software. The solution allows users to utilize a complete automated solution within their existing workflows. Once a potential threat is identified, the solution’s policies will automatically rectify it.

Benefits of Open-source Security Monitoring

As cybersecurity attacks are on the rise, organizations are at constant risk for data breaches. Managing your software supply chain gets trickier as your organization grows, leaving many vulnerabilities exposed. With easily accessible source code that can be modified and shared freely, open-source monitoring gives users complete transparency. A community of professionals can inspect open-source code to ensure fewer bugs, and any open-source dependency vulnerability will be detected and fixed rapidly. Users can use open-source security monitoring to avoid attacks through automatic detection of potential threats and rectification immediately and automatically.

Reviews from Real Users

Sonatype Nexus Lifecycle software receives high praise from users for many reasons. Among them are the abilities to identify and rectify vulnerabilities at every stage of the SDLC, help with open-source governance, and minimize risk.

Michael E., senior enterprise architect at MIB Group, says "Some of the more profound features include the REST APIs. We tend to make use of those a lot. They also have a plugin for our CI/CD.”

R.S., senior architect at a insurance company, notes “Specifically features that have been good include:

• the email notifications
• the API, which has been good to work with for reporting, because we have some downstream reporting requirements
• that it's been really user-friendly to work with.”

"Its engine itself is most valuable in terms of the way it calculates and decides whether a security vulnerability exists or not. That's the most important thing. Its security is also pretty good, and its listing about the severities is also good," says Subham S., engineering tools and platform manager at BT - British Telecom.

Sonatype Nexus Lifecycle was previously known as Nexus Lifecycle.

Sonatype Nexus Lifecycle Customers

Genome.One, Blackboard, Crediterform, Crosskey, Intuit, Progress Software, Qualys, Liberty Mutual Insurance

Sonatype Nexus Lifecycle Video

Archived Sonatype Nexus Lifecycle Reviews (more than two years old)

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
Austin Bradley - PeerSpot reviewer
Enterprise Infrastrcture Architect at Qrypt
Real User
Has brought open-source intelligence and policy enforcement across our software development life cycle for almost all of our applications
Pros and Cons
  • "When I started to install the Nexus products and started to integrate them into our development cycle, it helped us construct or fill out our development process in general. The build stage is a really good template for us and it helped establish a structure that we could build our whole continuous integration and development process around. Now our git repos are tagged for different build stages data, staging, and for release. That aligns with the Nexus Lifecycle build stages."
  • "They're working on the high-quality data with Conan. For Conan applications, when it was first deployed to Nexus IQ, it would scan one file type for dependencies. We don't use that method in Conan, we use another file type, which is an acceptable method in Conan, and they didn't have support for that other file type. I think they didn't even know about it because they aren't super familiar with Conan yet. I informed them that there's this other file type that they could scan for dependencies, and that's what they added functionality for."

What is our primary use case?

We have a few applications that we're developing that use several different languages. The first ones we did were Python and Yum Repository applications. Recently we've started scanning C and C++ applications that use Conan Package Manager. We will soon start doing node applications with NPM. Our use case is that we primarily rely on the IQ server to ensure we don't have open source dependencies in our applications that have security vulnerabilities, and to ensure that they're not using licenses our general counsel wants us to avoid using.

How has it helped my organization?

When I started to install the Nexus products and started to integrate them into our development cycle, it helped us construct or fill out our development process, in general. The build stages are a good template for us to help establish a structure that we could build our whole continuous integration and development process around. Now our git repos are tagged for different build stages that align with the Nexus Lifecycle build stages.

Going to the Nexus product encouraged me to look for a package manager solution for our C and C++ development. My customer success engineer, Derek, recommended that we go to one that Sonatype was considering integrating with the product, which was called Conan Package Manager. I started doing research with Conan and realized how beneficial it would be for our C and C++ development cycle. Transitioning to that has really changed our whole C and C++ development. It was because we needed to have Nexus scanning for our C applications and I needed Conan to do that.

It's because of Conan that we've reduced our build timelines from weeks because we have so many architectures that we build for. After we figured out how to use it, we can build everything with only a couple of commands. Now, it's a really integrated process for our C and C++ applications, from development to the build pipelines to the IQ scanning, and the Nexus Repository manager repositories that we're using for building and packaging. It's been a fun process.

In terms of the data quality, everything has been really good for our Python and our Yum repositories. I know that they are still building their capability for the Conan repositories, the C dependencies. Right now, what Derek has told me, is that Conan application are analyzed with what they call Low Quality Assessment, or LQA. Essentially, any package that has identified vulnerabilities will show up, otherwise, there's not much information on the package. So scanning for Conan is not as good as Python right now, but I know they're working on higher quality data for Conan packages.

Comparing LQA in Conan to something like the higher quality data available in Python repositories does show a difference. For example, Nexus IQ identified a vulnerability in a Python package that we don't use, but it's a transitive dependency in four packages that we do use. We discovered the root vulnerability causing the problem in our four packages with the higher quality data, but we may not have been to do that as easily with a vulnerability identified in multiple C packages without the higher quality data. I'm not sure.

Nexus will block undesirable open source components from entering our development life cycle. We've agreed on the governance of our policies for blocking builds automatically and we've set a date, for example, to start failing builds automatically on July 15.

It integrates very well with our existing DevOps tools. The Azure DevOps Nexus IQ plugin was really easy. All we did was go to our DevOps portal, go to the add-ins, and then search the list for Nexus. We just clicked on it and it installed in DevOps. There are a couple of help pages on Sonatype's webpage, and I send those to the developers, they add the IQ plugin to the build pipeline and it just works. It's really nice also because the IQ plugin for DevOps gets updated before I can even go check on it. They've released two updates since we installed it. Every time I hear from Derek that they've updated the IQ plugin, I go to the IQ plugin page on our DevOps server, and it's already been updated. It's totally seamless for us.

It has brought open-source intelligence and policy enforcement across our software development life cycle for almost all of our applications. We're still integrating it with all of our applications, but it definitely has brought the kind of intelligence that we needed.

What is most valuable?

Part of our use case is that we use Azure DevOps, so we have continuous integration, continuous deployment pipelines in Azure DevOps. The Nexus plugin for DevOps allows us to just include the IQ scan as part of the pipeline deployment. It's very seamless for our users. They don't even have to think about it until they have a violation. IQ informs them or stops the build, and the developers have to resolve it. 

The default policies were very good for us. We're using all of the default ones except for setting the warning and the stop features at different build stages. It definitely provides the flexibility we need.

We're not at the point in our deployment of the software to where we're doing automated git pulls and where it will automatically resolve vulnerabilities by downloading new packages. We haven't done that, but the integration with our Azure DevOps pipeline has been very seamless. I don't know of any developers that are using the integration with visual studio IDE.

What needs improvement?

The thing that they're already addressing is high-quality data for the Conan dependencies. They're very responsive to user needs. We're one of the first organizations to use Conan, so I identified a discrepancy in how they were scanning the dependencies, and they added the functionality within four weeks or so. The team is incredible. I can't think of any other ways that it could improve it.

When Conan support was first added to Nexus IQ, it would only scan one file type for dependencies. We don't use that specific method in Conan, but rather, another acceptable method for declaring dependencies that IQ wasn't scanning. I think the Sonatype developers  didn't even know about it because they learning Conan as much as we were. I informed them of the other file type for declaring dependencies and they quickly added the functionality.

Buyer's Guide
Sonatype Nexus Lifecycle
November 2022
Learn what your peers think about Sonatype Nexus Lifecycle. Get advice and tips from experienced pros sharing their opinions. Updated: November 2022.
653,522 professionals have used our research since 2012.

For how long have I used the solution?

I started installing it at the beginning of this year.

What do I think about the stability of the solution?

I've never had any problems with it, so it's been very stable.

What do I think about the scalability of the solution?

I don't know about the scalability yet because we are small and we don't have that many applications or packages yet. I haven't had to scale it. I designed, from the beginning, the storage architecture of my Repository Manager to be scalable because I knew a lot of the large data will sit there. I designed that upfront to be scalable to other storage volumes or even other servers. I know there are features for having multiple IQ servers or Repository manager servers and load balancing or having automatic failover and things, but I haven't done those things yet.

How are customer service and support?

Technical support has been great. I've never had any problems. When I do have an issue, sometimes I'll email Derek or I talk to him about it during our weekly meetings. He'll send off an email or a chat right away and get an answer back quickly about a resolution or resolution timeline.

Which solution did I use previously and why did I switch?

We weren't doing automated vulnerability scans or license scanning. We were pulling straight from the public repositories so everybody had local caches of varying packages, which was different from the repositories of packages on our build servers. It was like the Wild West, but the Nexus products have helped us consolidate our repositories.

The primary reason why our senior director of product management decided he wanted to do this was that we develop sensitive software and need to ensure we don't have vulnerabilities from third party open source packages. We needed an automated way to do scanning instead of having the developers look at a list of their packages and compare them to a list of new vulnerabilities themselves. That would've been a nightmare. That central repository management was a secondary reason, but it was also important.

As important as vulnerability scanning, the licensing was essential to us too because around the time we were evaluating the Nexus product, there was a large company that was getting sued for violating open source GPL-2 license requirements. We wanted to avoid problems like that. Those are the two primary reasons.

How was the initial setup?

The initial setup was easy. We're hosting on-prem and I put Nexus IQ on a VM I created according to Sonatype's recommended specs. It was really easy to install and it's really easy to update. The only thing that took a little longer to do was settings up HTTPS. It was my own fault because I had typos in configuration files that I'd overlooked. Following their instructions makes installation and upgrading really straightforward.

I did the IQ server and the repository manager server at the same time, and it took around less than a day for both of them.

When I first installed the two servers, I followed their recommended system requirements guidelines. In hindsight, because we are so small and we don't yet have that many applications, I probably could have started with IQ and Repository manager as containers. That would be okay for smaller companies that might be restricted on what resources they have available for hosting the servers. They could probably do containers in the beginning and then expand if they needed to later.

The deployment was given to me as a project. I didn't have an implementation strategy when I started building the servers, but Derek and I created implementation strategies as we went, after I installed the servers.

Initially after installing IQ and I putting some Python applications into, we had all of our policies set to warn and not fail builds automatically because we hadn't decided our governance process. That was part of the implementation strategy that we had to figure out. We had to decide a time to roll out our test applications and test groups. Derek was really instrumental in helping me see it in stages. We would test with the Python applications and then move on to other types of repositories and other types of applications for a broader adoption strategy.

What was our ROI?

Since the developers weren't doing really thorough vulnerability assessments in the past, I can only estimate how many hours it's saved and allowed them to continue developing the applications.

For example, if one of our pipeline applications has 15 dependencies and a developer had to look for vulnerabilities in that list of 15 dependencies, it could take a half-hour every day for one application. If they're developing six applications at once, then it could be a couple of hours a day per developer. It would quickly get out of hand.

What's my experience with pricing, setup cost, and licensing?

I don't know anything about the pricing. I know that our license is the most encompassing one you can get. It includes the IQ server (Lifecyle, Firewall) and the Repository Manager Pro. Firewall is really useful for us to keep an eye on our proxy repositories for vulnerabilities. That's another layer of helping us make sure that we don't have vulnerable products. The expense is justifiable because of the potential to save a company a lot of money in lawsuits and risks from having vulnerable packages in their applications.

What other advice do I have?

I don't have any reason to rate it less than 10 out of ten. It's been really solid, really helpful, and it will pay off hugely as we continue to expand.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Enterprise Application Security Analyst at a comms service provider with 5,001-10,000 employees
Real User
Gets our developers to think about the third-party libraries they're pulling into the system, in terms of security
Pros and Cons
  • "The component piece, where you can analyze the component, is the most valuable. You can pull the component up and you can look at what versions are bad, what versions are clean, and what versions haven't been reported on yet. You can make decisions based off of that, in terms of where you want to go. I like that it puts all that information right there in a window for you."
  • "One thing that it is lacking, one thing I don't like, is that when you label something or add a status to it, you do it as an overall function, but you can't go back and isolate a library that you want to call out individually and remove a status from it. It's still lacking some functionality-type things for controlling labels and statuses. I'd like to be able to apply it across all of my apps, but then turn it off for one, and I can't do that."

What is our primary use case?

We have it implemented and integrated into our CI/CD pipeline, for when we do builds. Every time we do a build, Jenkins reaches out and kicks off a scan from the IQ Server.

We use it to automate open source governance and minimize risk. All of our third-party libraries, everything, comes through our Nexus, which is what the IQ Server and Jenkins are hooked into. Everything being developed for our big application comes through that tool.

We have Nexus Firewall on, but it's only on for the highest level of vulnerabilities. We have the firewall sitting in front to make sure we don't let anything real bad into the system.

Our environment is your standard, three-tiered environment. We have the developers develop in their Dev and Test environments, and as the code moves through each environment — Test and a QA environment — it goes through a build process. We build each time we deploy.

We're addressing anything that is a nine and above. If it's a 10, we don't let it into our system; the firewall server stops it. If we have nines we'll let it in, but I'll tag the developers and they'll have to do a little triage to figure out if the problem that is being reported is something we utilize in our system — if it's something that affects us — and if it's not, we flag it as such and let it go. We either waive it or I'll acknowledge it depending on how much it's used throughout the system and how many different components are being built with that bad library.

How has it helped my organization?

It really hasn't an improved way we function, but it's helped us to get the developers to start thinking about the security posture that we want to have, going forward, with applications that we develop in-house. It's helping to educate the developers who don't think about these things when they're throwing code together.

It has also brought open source intelligence and policy enforcement across our software development life cycle. That's what we're moving to. We're not 100 percent there, but that's the goal. It's getting the developers to actually think about the third-party libraries they're pulling into the system and to think of them in a different light, in terms of the security aspects of them. I was a developer for 20 years before I got into security. As a developer, you don't always think about the security aspect of things. You're looking for a library that does X, Y, and Z. Lifecycle helps keep that security issue front and center, because as you're bringing it into the system, or as you're doing the build, it's breaking a build or it's doing other things.

It's helping to block undesirable open source components from entering our development lifecycle at least once or twice with every round of releases or library upgrades.

It has also improved the time that it takes to release secure apps to market, although we haven't put a number on that. 

And we have seen an increase in developer productivity because the tool allows them to go out and look for the libraries that aren't affected, or that don't have all the negatives in them. The component piece and the IQ Server aspect has saved time. Without this solution in place, the developers wouldn't care. If this tool wasn't in their face, making them care, a lot would slip by. This is our way to make sure we're watching the gate. Without it, we would be in a much worse spot in terms of exposure, risk, and data exfiltration.

What is most valuable?

The component piece, where you can analyze the component, is the most valuable. You can pull the component up and you can look at what versions are bad, what versions are clean, and what versions haven't been reported on yet. You can make decisions based off of that, in terms of where you want to go. I like that it puts all that information right there in a window for you.

The default policies are a good start. Within our environment, I tweaked each level to have its own policy, just because of the control it gives us. It provides us with the flexibility we need.

The data quality is pretty good. I have not had any major problems. It helps us solve problems faster.

It integrates well with the existing DevOps tools. We plugged it right in. It was an "after-the-fact" thing that we added into our pipeline and it integrated quite easily. We use Jenkins and it was a nice fit with that. We don't have it creating tickets yet, so we don't have it integrated with a ticketing system, but it is integrated with our Jenkins platform.

What needs improvement?

One thing that it is lacking, one thing I don't like, is that when you label something or add a status to it, you do it as an overall function, but you can't go back and isolate a library that you want to call out individually and remove a status from it. It's still lacking some functionality-type things for controlling labels and statuses. I'd like to be able to apply it across all of my apps, but then turn it off for one, and I can't do that. I have to go to all 100 apps and do it individually in order to get something on each one, and I don't like that. I should be able to add it as a group and remove it as a single.

Everything else has been really good.

For how long have I used the solution?

I have been using Sonatype Nexus Lifecycle for a year and a half, going on two years.

What do I think about the stability of the solution?

The stability is good. There have been no problems that I'm aware of.

What do I think about the scalability of the solution?

It's handling a lot of code but if we wanted to roll out more servers and do more build outs, I wouldn't think that it would involve much more than just adding a few servers. So the scalability should be good.

It is being fully utilized in our build process — where our applications are built and deployed. Where we're lacking use is getting the developers to get it plugged into their Eclipse environments and actually using it on a more regular basis. That's where the struggle has been. That's not the tool, that's more an issue with our developer management side. The adoption is just not happening at the pace it should, because of a whole multitude of other things that are going on right now in our company.

The only other thing we might eventually want to do is get it hooked into a ticketing system where it could create tickets if there are libraries that are bad. Outside of that, it's pretty much integrated into our pipeline as far as we're going to integrate it.

How are customer service and technical support?

Their tech support is pretty good. I only know of one or two instances where the gentleman in our company who does the upgrades had a question, and they were answered and resolved quite quickly.

Which solution did I use previously and why did I switch?

We did not have a previous solution.

As I was moving into my security role, the pipeline team was already looking at something and it played nice with Nexus. It was an extra add-on piece or something like that. They were the ones who actually introduced it. I liked it and pushed it along.

How was the initial setup?

The initial setup was straightforward and easy. I didn't set it up but I know there weren't any problems. It took less than a day and it took one person to deploy it. We had one person, at that time, setting up the servers. 

Sonatype came in and did a little demo for us and, while they were here, we got the information set up. It was really easy. We didn't have any major issues that I'm aware of.

In terms of maintenance, we just went through a library upgrade and that was done by one person. It took about a day. We have one person who knows the administrative aspect of it at our company. He works on the pipeline team. I'm on the security aspects and the security policies.

Overall, we have over 50 people using it across our organization. They are developers, architects, managers, and in security.

What was our ROI?

I'm not sure it's saving us anything. I don't have a way to gauge that as far as return on investment goes.

The return on investment for us is that we have the process in place that has our security aspects tied into it. That's more the type of return on investment we were looking for, and it is doing that. We're still in the early stages.

What's my experience with pricing, setup cost, and licensing?

I'm not familiar with the pricing in detail, but I believe it was pretty reasonably priced, compared to the market.

What other advice do I have?

The biggest thing we've learned from using it is that, from a development point of view, we just never realized what types of badness are in those third-party libraries that we pull in and use. It has been an eye-opener as to just how bad they can be.

As far as Lifecycle's integration into developer tooling like IDEs, Git Repos, etc., I don't set that up. But I have not heard of any problems from our guys, from the team that set that stuff up.

I like the tool overall and would rate it at about nine out of 10. There are a few UI-type things that I don't like, that I would like to work a different way. But overall, the tool is good.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Buyer's Guide
Sonatype Nexus Lifecycle
November 2022
Learn what your peers think about Sonatype Nexus Lifecycle. Get advice and tips from experienced pros sharing their opinions. Updated: November 2022.
653,522 professionals have used our research since 2012.
Computer Architecture Specialist at a energy/utilities company with 10,001+ employees
Real User
Before using Lifecycle we were almost blind to the vulnerabilities in open source libraries
Pros and Cons
  • "The scanning capability is its most valuable feature, discovering vulnerable open source libraries."
  • "The reporting capability is good but I wish it was better. I sent the request to support and they raised it as an enhancement within the system. An example is filtering by version. If I have a framework that is used in all applications, but version 1 is used in 50 percent of them and version 2 in 25 percent, they will show as different libraries with different usage. But in reality, they're all using one framework."

What is our primary use case?

We use it to scan applications for open source libraries and to find libraries with a clean version for developers. If one version is vulnerable, they can switch to another version which is clean.

Our situation is that we are running it as a pilot. Hopefully, this year we will be moving the environment into production. Delays happened due to some of our workforce being allocated to different organizations, and then we had the pandemic.

It's deployed on-premise, on a virtual host.

How has it helped my organization?

We can automate the pipeline of CI/CD. For example, if a publication uses an open source library and it's vulnerable, then the security team will mark it in the Lifecycle suite and it can go through the pipeline without manual interaction by the developer.

I'm not a security guy but I have sat with the security team. Once you set the policies, you wont need to change them. The policies wouldn't change that frequently. It covers the needs that we have.

Using the solution we have been able to clean our environment, providing more protection for our applications. We have a more hygienic environment than before. Before using Lifecycle we were almost blind to whatever we had and didn't look into the vulnerabilities within open source libraries. Now we do.

It has helped to increase our productivity a lot, especially with Nexus Repository Manager. It is way more agile. There is no comparison between our productivity before and now.

In terms of the accuracy of the data from Sonatype, at first the teams were challenging whatever the solution provided, but they then verified with the vendor of the open source libraries or via the related community, and they realized that the data from Sonatype is something that is done carefully. It's accurate and valid data. We are now introducing a security layer for open source. Before, there was no security on open source and they did whatever they wanted but that is no longer the case. They have to fix things before deploying them. It helps them resolve issues. It works most of the time, but sometimes there are challenges for the developer in solving them.

We also use the solution to automate open source governance and minimize risk with policies. Some of our developers, although not all of them, have their own Jenkins installed and they set rules and policies. They have integrated Jenkins with Lifecycle and, whenever they push into production, it verifies they are not violating any policies. Once everything is smooth, it goes into production. We haven't formalized that process yet.

What is most valuable?

It's a great tool. We have it connected live to the Sonatype database. Whenever there is a new vulnerability, it's discovered. We have early detection of any vulnerability in our open source library. The scanning capability is its most valuable feature, discovering vulnerable open source libraries.

What needs improvement?

The reporting capability is good but I wish it was better. I sent the request to support and they raised it as an enhancement within the system. An example is filtering by version. If I have a framework that is used in all applications, but version 1 is used in 50 percent of them and version 2 in 25 percent, they will show as different libraries with different usage. But in reality, they're all using one framework.

For how long have I used the solution?

This is my second year using Sonatype Nexus Lifecycle.

What do I think about the stability of the solution?

It's very stable. I don't recall ever seeing problems. The main concern would be data-disk corruption, but I haven't seen it, even though the server, due to patching, has been rebooted multiple times.

What do I think about the scalability of the solution?

When it comes to scalability, there's a limitation in terms of high-availability. Sonatype recommends you go with high-availability. However, you have to have an Active-Passive solution and we don't use a separate installation for each organization. I know there are ways you can install multiple instances for each organization and proxy between them. Because we are a single organization that uses one installation, we have to set it to Active-Passive and manually switch the Passive on and off.

How are customer service and technical support?

My experience with their technical support has been good, overall.

The problem for us is that we work in a different time zone than they do and the workdays are different. We don't work on Friday and Saturday. If we send them something on Sunday, we don't hear until on Monday. If it is urgent they get back to us.

Which solution did I use previously and why did I switch?

We used OWASP Dependency-Check, but for only about five months. It needs maintenance. You have to maintain the database library manually, and install it on the developers' workstations. There are a lot of drawbacks with that solution.

If we depend on OWASP Dependency-Check, it is a public vulnerability tool and it is not a good database, to be honest. If you have a library where one version is marked as vulnerable and you go to the community, the owner of the library says all versions are vulnerable. You would not see the vulnerability reflected regarding the versions. You would see it on one version and the others would be marked as clean. The team at Sonatype is doing a good job of maintaining this information very well.

We were working with Repository Manager and the security team switched to a Nexus server to reduce the effort and eliminate duplication. We now also have one, unified solution to cover all the possibilities.

How was the initial setup?

The installation is straightforward in terms of the application itself. However, with our setup, with our environment and the restrictions we have, we had to do a lot of things. But that work was from our side, not from the application's side. 

We did the installation within about two to three days. I was part of our support team at that time. Later on, I added enhancements on-the-go, such as certification. If I were to do the installation now, I would do it within an hour. It is the configuration that you have to get to know. Once you know it, that's it. When it's new to you, you have to take the time to read the documentation to understand what's going on and do things right.

What about the implementation team?

I only worked with the support from Sonatype and I was the only person in our organization involved in the installation. I am also the only one who runs this part of our environment, in terms of maintenance.

What was our ROI?

We expect to see ROI once we're using it fully in production.

What's my experience with pricing, setup cost, and licensing?

Lifecycle, to the best of my recollection, had the best pricing compared with other solutions.

What other advice do I have?

We ran into too many debates and there was this culture of "security is not mine" and someone else should have to deal with it. After using the solution, they realized this is not the case. Security vulnerabilities had to be addressed. I was a developer and I understood their complaints, but security is important and you have to go with it. The tool is there to automate and simplify your work and you should utilize it. It has been a very good experience.

We are introducing Lifecycle and developers will be aware, with the IDE plugin, from the beginning, whether whatever libraries they are using are vulnerable or not. There should be no delays if they work with it from the beginning.

It is used, or should be used, by all of our 120 developers. But in a group developing a given application, not everyone would commit to it and scan the application. One would do the scanning. But, overall, all of them should be directly or indirectly using it or depending on it.

When we move it to production we will need to do a recertification of the users and find out who is not using it, who would use it, and who is shifting to other organizations. Then we will decide on the number.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Application Development Manager at a financial services firm with 501-1,000 employees
Real User
If new libraries need to be used, we can scan them to see if they are secure or valid
Pros and Cons
  • "The report part is quite easy to read. The report part is very important to us because that is how we communicate to our security officer and the security committee. Therefore, we need to have a complete report that we can generate and pass onto them for review."
  • "One thing that I would like to give feedback on is to scan the binary code. It's very difficult to find. It's under organization and policies where there are action buttons that are not very obvious. I think for people who are using it and are not integrated into it, it is not easy to find the button to load the binary and do the scan. This is if there is no existing, continuous integration process, which I believe most people have, but some users don't have this at the moment. This is the most important function of the Nexus IQ, so I expect it should be right on the dashboard where you can apply your binary and do a quick scan. Right now, it's hidden inside organization and policies. If you select the organization, then you can see in the top corner that there is a manual action which you can approve. There are multiple steps to reach that important function that we need. When we were initially looking at the dashboard, we looked for it and couldn't find it. So, we called our coworker who set up the server and they told us it's not on the dashboard."

What is our primary use case?

During the development, if there are new libraries that need to be used, then we scan them first to see if they are secure or valid. If there is a threat, can we avoid it or use alternatives. Also, before each release, it is mandatory for us to scan the code before we go to release it.   

It was installed at the beginning of the year, so I think we are using the latest version.

How has it helped my organization?

We rely on the default policies because we are new to the system. We haven't adjusted any policies and are sticking with whatever policies were shipped to us. We are mostly focused on policies 9 and 10 for the highest threat levels. These are the ones which we are focusing right now. We don't want to make any modifications or adjustments in terms of 9 or 10. Mostly, it will be the security officer's decision if we need to update the policies. I'm the manager of the development team and my developers usually will not make any changes in terms of policies.

It provides a very detailed analysis of our library. Then, when some of the scans identify a licensing issue, we look at them and know if we have the license. It sort of scans everything. Without this tool, I don't think that there's even a capability to go through all these libraries, because some of the libraries were introduced by contractors and a developer who no longer works here anymore. When Nexus comes in with its scans, it reports on licensing or other vulnerabilities. This is easier to do instead of asking around.

What is most valuable?

The most valuable feature is the scanning part, then the report part, as it is quite easy to read. The report part is very important to us because that is how we communicate to our security officer and the security committee. Therefore, we need to have a complete report that we can generate and pass onto them for review.

The solution’s data quality has been pretty accurate. The ones that we are focusing on now are 9 and 10. Once we adjust and scan them again, they are no longer deemed to be the same threat level, which is good. If I replaced the library with a safer one, they still complain that that's not good. So far, we're pretty happy with the quality.

What needs improvement?

One thing that I would like to give feedback on is to scan the binary code. It's very difficult to find. It's under organization and policies where there are action buttons that are not very obvious. I think for people who are using it and are not integrated into it, it is not easy to find the button to load the binary and do the scan. This is if there is no existing, continuous integration process, which I believe most people have, but some users don't have this at the moment. This is the most important function of the Nexus IQ, so I expect it should be right on the dashboard where you can apply your binary and do a quick scan. Right now, it's hidden inside organization and policies. If you select the organization, then you can see in the top corner that there is a manual action which you can approve. There are multiple steps to reach that important function that we need. When we were initially looking at the dashboard, we looked for it and couldn't find it. So, we called our coworker who set up the server and they told us it's not on the dashboard. This comes down to usability. 

There is another usability thing in the reports section. When the PDF gets generated, it is different from the web version. There are some components from some areas which only reside inside the PDF version. When I generate the PDF for my boss to review, she comes back with a question that I didn't even see. I see on the reporting page whatever the PDF will be generating. The PDF is actually generating more information than the web version. That caught me off guard because she forwarded this to the security officer, who is asking, "Why is this? Or, why is that?" But, she has no idea. I didn't have anything handy because I saw the PDF version, which should be same as what I see on the web. This is a bit misrepresented. I would like these versions to speak together and be consistent. Printing a PDF report should generally reflect whatever you have on the page.

For how long have I used the solution?

We have been using it for two or three months now.

What do I think about the stability of the solution?

It is stable.

Users of the solution include our security officer, our application architect, and me. I manage all of the development and the developers who work on upgrading libraries.

Not many people are needed to maintain this solution. We need two or three people. One person is from our service support where the Sonatype Server is deployed and managed. Another person is the application architect who reviews the libraries.

What do I think about the scalability of the solution?

Scalability is not applicable to us at the moment.

The solution is pretty much involved in every release that we have. So, it's quite frequently being used. We don't have current plans to increase usage. We are working on our continuous integration process. Once that's done, then there will be a need to increase usage.

How are customer service and technical support?

I haven't opened a support ticket yet.

Which solution did I use previously and why did I switch?

We did not have another solution that we previously used before Sonatype.

We had one job file we used a long time ago (it was over 10 years ago). At that time, we had purchased a license, but nobody has really used it for a really long time.

How was the initial setup?

I wasn't involved in the initial setup.

What about the implementation team?

This was all done by our service support.

What was our ROI?

This solution has increased developer productivity by 20 percent. They know the version that they need to use. It is a lot easier.

What other advice do I have?

We are still in the process of automating our deployment.

In terms of the developing the IDE, I don't see a big need because we are mostly focusing on enhancing existing projects. We mostly will be focusing on addressing existing issues and vulnerabilities. For a developer to use a new library all the time, this is not a high priority. Right now, we are working on continuous integration continuous deployment solutions. Then, we will integrate the Sonatype Scanner as part of the build, testing, and release.

I would give it an eight (out of 10). Right now, it is sufficient for us to identify our vulnerabilities. It is quite easy to use and not too much trouble.

Which deployment model are you using for this solution?

On-premises
Disclosure: I am a real user, and this review is based on my own experience and opinions.
PeerSpot user
Ryan Carrie - PeerSpot reviewer
Security Analyst at a computer software company with 51-200 employees
Real User
Enables me to choose a vulnerable library and see versions that don't have any listed vulnerabilities
Pros and Cons
  • "The policy engine is really cool. It allows you to set different types of policy violations, things such as the age of the component and the quality: Is it something that's being maintained? Those are all really great in helping get ahead of problems before they arise. You might otherwise end up with a library that's end-of-life and is not going to get any more fixes."
  • "The biggest thing that I have run into, which there are ways around, is being able to easily access the auditing data from a third-party tool; being able to pull all of that into one place in a cohesive manner where you can report off of that. We've had a little bit of a challenge with that. There are a number of things available to work with, to help with that in the tool, but we just haven't explored them yet."

What is our primary use case?

Our use case for Nexus is to monitor all of our dependencies and the main thing we're using it for is tracking vulnerabilities listed against those.

How has it helped my organization?

It gives alerts for new vulnerabilities before our clients do, so we have time to review them, audit them, and determine how we need to proceed with resolving the issues before we get any client communication.

Before we had this in place, we had a much more reactive approach to CVE listings.   Since integrating this, and as we've refined our process over the past eight months or a year, we have moved to a proactive approach allowing auditing and decisions on mitigation before any incoming client submissions.

In addition, it has brought open-source intelligence and policy enforcement across our software development lifecycle. As a component of the lifecycle, it gives us more controls in place. As far as bringing in dependencies goes, we're able to see what a dependency is introducing, from a security and licensing perspective, before we publish a release to the public. So within the build stage, if we pull in a new dependency, Nexus will very quickly tell us whether it has issues or not. And we catch it. It scans in the build stages; we have it checking our staging where we're doing our regression; and it's also monitoring our released branches and letting us know if issues are found in our releases. It really does hit all stages of that lifecycle.

What is most valuable?

I like the JIRA integration, as well as the email notifications. They allow me to see things more in real-time without having to monitor the application directly. So as new items come in, it will generate a JIRA task and it will send me an email, so I know to go in and have a look at what is being alerted.

The policy engine is really cool. It allows you to set different types of policy violations, things such as the age of the component and the quality: Is it something that's being maintained? Those are all really great in helping get ahead of problems before they arise. You might otherwise end up with a library that's end-of-life and is not going to get any more fixes. This can really help you to try to get ahead of things, before you end up in a situation where you're refactoring code to remove a library. The policy engine absolutely provides the flexibility we need. We are rolling with the default policy, for the most part. We use the default policy and added on and adjusted it a little bit. But, out-of-the-box, the default policy is pretty good.

The data quality is good. The vulnerabilities are very detailed and include links to get in and review the actual postings from the reporters. There have been relatively few that I would consider false positives, which is cool. I haven't played with the licensing aspect that much, so I don't have any comment on the licensing data. One of the cool things about the data that's available within the application is that you can choose your vulnerable library and you can pull up the component information and see which versions of that library are available, that don't have any listed vulnerabilities. I've found myself using that a lot this week as we are preparing for a new library upgrade push.

The data quality definitely helps us to solve problems faster. I can pull up a library and see, "Okay, these versions are non-vulnerable," and raise my upgrade task. The most valuable part of the data quality is that it really helps me fit this into our risk management or our vulnerability management policy. It helps me determine: 

  • Are we affected by this and how bad is it? 
  • How quickly do we need to fix this? Or are we not affected?
  • Is there any way to leverage it? 

Using that data quality to perform targeted, manual testing in order to verify that something isn't a direct issue and that we can designate for upgrade for the next release means that we don't have to do any interim releases.

As for automating open-source governance and minimizing risk, it does so in the sense of auditing vulnerabilities, thus far. It's still something of a reactive approach within the tool itself, but it comes in early enough in the lifecycle that it does provide those aspects.

What needs improvement?

The biggest thing that I have run into, which there are ways around, is being able to easily access the auditing data from a third-party tool; being able to pull all of that into one place in a cohesive manner where you can report off of that. We've had a little bit of a challenge with that. There are a number of things available to work with, to help with that in the tool, but we just haven't explored them yet.

For how long have I used the solution?

We're going on our second year using the solution.

What do I think about the stability of the solution?

I've never had any stability issues with the application. I haven't performed any of the upgrades, but we've never had any downtime and we've never had any issues with notifications or an inability to access the information we need.

How are customer service and technical support?

The technical support is fantastic. I reached out with a suspected false negative and had a response within hours, and within the next day they had determined that, yes, it was a false negative and, that same day, the notification came in when they had resolved the issue. So within less than 48 hours of reporting a false negative, I had a full turnaround and the result returned in the tool.

Which solution did I use previously and why did I switch?

Before IQ server we used an open-source solution called OWASP Dependency-Check. We wanted something a little more plug-and-play, something a little more intuitive to configure and automate.

How was the initial setup?

For the initial deployment, it was in place within a couple of days of starting the trial.

We did have an implementation strategy sketched out as far as requirements for success during the PoC go. The requirements were that it would easily integrate into our pipeline, so that it was very automated and hands-off. Part of the implementation strategy was that we expected to use Jenkins, which is our main build-management tool.

In terms of the integrations of the solution into developer tooling like IDEs, Git repos, etc., I wasn't really part of the team that was doing the integration into the pipeline, but I did work with the team. We didn't have any problems integrating it. And from what I did see, it looks like a very simple integration, just adding it straight into Jenkins. It integrated quite quickly into the environment.

At this point we haven't configured it to do any blocking or build-blocking just yet. But that's something we'll be reviewing, now that we have a good process.

What was our ROI?

We have absolutely seen ROI with Sonatype. The more proactive approach is definitely a return on investment. It significantly lowers the turnaround for responding to incoming issues. It also empowered our support staff to be able to pass along audit results without having to loop in the security team directly. There is a much lower overhead involved when doing it that way.

Also, the ability to better manage our vulnerability management by getting the detailed information from the scan results or the listings, and being able to audit them thoroughly and test them really helps with development resources in our case. We do not have to cram in a bunch of upgrades just for the sake of upgrading if we're constrained elsewhere. It really helps prioritize dev resources.

I don't know if it has directly saved time in releasing secure apps to market. It has definitely made everything more efficient, but unless things are critical and can definitely be leveraged, we don't necessarily delay a release.

The upgrade processes are definitely a quicker turnaround because it allows us to actually target versions that are not vulnerable. But it is hard to quantify whether, in the grand scheme of things, our developers are more productive as developers.

Which other solutions did I evaluate?

We looked at things like Black Duck, White Source, and White Hat.

The biggest issue, and this is why we went with Nexus, is that there were more results and there were far fewer false positives than in the other tools.

What other advice do I have?

Take some time configuring your notifications and your JIRA integration properly, along with the policy tweaks. As you integrate and as you first deploy the tool, don't block any builds until you start to catch up on any issues that may be there. Really spend some time with that policy review and make sure it encompasses and aligns with your vulnerability management policy appropriately.

It is incorporated in all of our software branches, and we keep our most recent end-of-life branch active in it just to monitor for critical issues, so we can notify the community to upgrade. We may also add our new mobile application to it.

Nexus Lifecycle is definitely a nine out of 10. I would say 10 if it were a little easier to get the audit information out. Again, there are ways around that so I am not taking off much for that. It's a solid nine. The results are amazing. The quality of the data coming back is great. The audit interface is easy to use.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Russell Webster - PeerSpot reviewer
VP and Sr. Manager at a financial services firm with 1,001-5,000 employees
Real User
We built it directly into our continuous integration cycles and have been able to catch things at build time
Pros and Cons
  • "The data quality is really good. They've got some of the best in the industry as far as that is concerned. As a result, it helps us to resolve problems faster. The visibility of the data, as well as their features that allow us to query and search - and even use it in the development IDE - allow us to remediate and find things faster."
  • "As far as the relationship of, and ease of finding the relationships between, libraries and applications across the whole enterprise goes, it still does that. They could make that a little smoother, although right now it's still pretty good."

What is our primary use case?

The Lifecycle product is for protection, and licensing vulnerabilities issues, in our build lifecycle.

How has it helped my organization?

Without it we didn't have any way to detect vulnerabilities except through reactive measures. It's allowed us to be proactive in our approach to vulnerability detection.

Sonatype has also brought open-source intelligence and policy enforcement across our SDLC. It enforces the SDLC contributors to only use the proper and allowed libraries at the proper and allowed time in the lifecycle of development. The solution blocks undesirable open-source components from entering our development lifecycle. That's its whole point and it does it very well.

We use the solution to automate open-source governance and minimize risk. With our leaders across our different organizations, we set policies that govern what types of libraries can be used and what types of licenses can be used. We set those as settings in the tool and the tool manages that throughout the lifecycle, automatically.

It's making things more secure, and it's making them higher in quality, and it's helping us to find things earlier. In those situations where we do find an issue, or there is an industry issue later, we have the ability to know its impact rapidly and remediate more rapidly.

What is most valuable?

Its core features are the most valuable:

  • protection
  • scanning
  • detection
  • notification of vulnerabilities.

It's important for us as an enterprise to continually and dynamically protect our software development from threats and vulnerabilities, and to do that as early in the cycle as possible.

Also, the onboarding process is pretty smooth and easy. We didn't feel like it was a huge problem at all. We were able to get in there and have it start scanning pretty rapidly.

The data quality is really good. They've got some of the best in the industry as far as that is concerned. As a result, it helps us to resolve problems faster. The visibility of the data, as well as their features that allow us to query and search - and even use it in the development IDE - allow us to remediate and find things faster.

The solution also integrated well with our existing DevOps tool. That was of critical importance to us. We built it directly into our continuous integration cycles and that's allowed us to catch things at build time, as well as stop vulnerabilities from moving downstream.

What needs improvement?

Overall, it's pretty good. The drill-through and search capabilities are pretty good, they're not horrible. 

As far as the relationship of, and ease of finding the relationships between, libraries and applications across the whole enterprise goes, it still does that. They could make that a little smoother, although right now it's still pretty good. It's taking an eight out of ten and asking it to be a ten.

For how long have I used the solution?

We've been using Nexus Lifecycle for over a year.
We use the Nexus repository for a long time.

What do I think about the stability of the solution?

It's very stable. We have not had any issues with it.

What do I think about the scalability of the solution?

They're really good with scalability. We have an implementation that spans production use plus a disaster recovery area. The synchronization between those two and the high-availability are awesome.

We're at 100 or 150 licenses, maybe more. Developers are the main role as well as DevOps. The plan is to use it across every single application where we do development. We have a lot of applications, on the order of 500.

We have plans to expand usage, as far as the user base and the number of teams utilizing it go. 

How are customer service and technical support?

Tech support is really available and very helpful.

Which solution did I use previously and why did I switch?

We did not have a solution with this type of capabilities. We had some type of Nexus product but we layered this on top. We didn't have that capability.

How was the initial setup?

The initial setup was straightforward. There weren't a lot of manual steps involved. There wasn't a ton of configuration. It has very smart defaults. There's not a high level of subject matter expertise required in the setup of the software. 

As for the decisions that you need to make about your policies, there are smart people out there to give you a lot of industry standards. But there is still a lot of work you need to do to make decisions for your enterprise. It can't do that no matter what it is. What you are going to do with those settings and the findings from those settings, that's the hard part. You have to make decisions about what to do with the data that it provides for you. That's not the setup, per se. That's just getting it to be very meaningful in your enterprise.

Our deployment was an interrupt-driven process because we had other work to do also. It took a few days.

The strategy for deployment was to involve legal, development, info security, and DevOps together - the leadership - to understand the tool's capabilities; to understand the defaults and also to come up with a strategy to manage the outcomes, the findings. That group of leadership had to set those settings and automatically be part of SDLC. Along with that, we had to implement a process that ensured that the findings - the breaks and the vulnerabilities that are found - would be visible. Notifications had to be made so that someone can triage and deal with them.

Deployment and maintenance require half a person. It's a side role because there's nothing to do most of the time. It's something you do occasionally, so we don't have a role dedicated to it.

What about the implementation team?

We deployed it ourselves. We worked with Sonatype a little bit but we didn't need much from them. They were available when we needed them, but it was pretty straightforward.

What was our ROI?

The solution has improved the time it takes us to release secure apps to market. I can't approximate how much, there are too many factors there to consider.

If you find a problem reactively without the tool, there's the remediation cost, versus the savings of finding it in the first place. It would be really hard for me to go back right now and say how many things we found and how often because it's happening very dynamically. Those findings are not anything I can measure right now.

Then there are the things that we found that we might not have remediated. Maybe they were just okay, they weren't high-ranking and they weren't low-ranking errors. Now, we can decide that because we found them really early that we're not going to take that risk. Whereas before, we might've taken the risk - or not even have seen the risk. So it's hard to measure that. 

It's not literally speeding up our release to market. It's helping us avoid reactive costs and maintenance to the cycles after the fact. If an industry vulnerability is found, we get that notification really early.

We have seen a return on our investment. In some cases, where we've needed to find out the footprint of a certain library across our enterprise, we've been able to do that research in seconds or minutes, rather than long, drawn-out processes with people and teams involved to hunt it down through source code and the like.

As far as spinning up councils and people saying, "What's our vulnerability footprint look like?" we've been able to answer those questions much quicker and remediate quicker with other tools. Those things alone will probably pay for it. The safety stuff pays for it on its own too.

We've more recently also been able to leverage it as a solid containers repository solution.

What's my experience with pricing, setup cost, and licensing?

Pricing is decent. It's not horrible. It's middle-of-the-road, as far as our ranking goes. They're a little bit more but that's also because they provide more. They put more manpower and time into their research - the details on their findings and the way they bring those to the surface. They offer some more features that others don't have, so I understand why it's a little bit more.

They were pretty good with us on pricing, working through it.

Which other solutions did I evaluate?

We looked at Artifactory as well. We went with Sonatype because it is more comprehensive, it's a market leader, has a great feature set, and support is really good. It's a good team and company. They provide much more granular details, as well as assistance in the remediation and understanding of vulnerabilities, than their competition.

What other advice do I have?

In the early stages of planning and design for rolling this out, ensure that you get all of your stakeholders involved; those who will have an input on the policy settings. Also, ensure you have a process and people involved to deal with the findings. Have that baked into your standard enterprise processes. Don't just turn it on and not know what to do with it.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Ricardo Van Den Broek - PeerSpot reviewer
Software Architect at a tech vendor with 11-50 employees
Real User
Checks our libraries for security and licensing issues
Pros and Cons
  • "With the plugin for our IDE that Sonatype provides, we can check whether a library has security, quality, or licensing issues very easily. Which is nice because Googling for this stuff can be a bit cumbersome. By checking it before code is even committed, we save ourselves from getting notifications."
  • "One of the things that we specifically did ask for is support for transitive dependencies. Sometimes a dependency that we define in our POM file for a certain library will be dependent on other stuff and we will pull that stuff in, then you get a cascade of libraries that are pulled in. This caused confusing to us at first, because we would see a component that would have security ticket or security notification on it and wonder "Where is this coming in from?" Because when we checked what we defined as our dependencies it's not there. It didn't take us too long effort to realize that it was a transitive dependency pulled in by something else, but the question then remains "Which dependency is doing that?""

What is our primary use case?

We use the Nexus IQ Server. That is the only product that we use, though there are other affiliated products Sonatype offers which integrates with it. We use it to categorize and index all libraries used in our software. Every time that a new build is created in our CI server, Nexus IQ server will check exactly what libraries that we're using. It does this for our Java libraries, JavaScript, and other things that it finds. Then, it checks a number of things for each of those libraries. E.g., it checks the license that is being used in it. Sometimes with open source software, the license is a bit more restrictive than might be convenient for what you are doing. Maybe it doesn't allow you to make changes to the library. Or, it's free to use for nonprofits, but if you're using a product which does make a profit, then you might have to purchase a license. Therefore, it protects us from accidentally misusing open source software and is protection against legal issues.

A bigger, ongoing use case is security. Sonatype checks security vulnerabilities that come up for all these libraries. Oftentimes, as a developer, you add a library that you want to use, and then you might check for security issues. Sometimes a problem comes up after your product is already live. IQ Server checks all libraries that we're using for security issues, reporting these, and allowing us to go through and see them to determine, "Is this something that we can waive?" It might be a very specific use case which doesn't actually affect us or we might have to mitigate it. Also, if a vulnerability or security issue is found in libraries later, it will send out alerts and notifications if a library is being used in our production environment, letting us know there is an issue. This allows us to address it right away, then we can make the decision, "Do we want to do a hotfix to mitigate this? Or is it something that isn't an issue in our case because we're not using it in a way that exposes the vulnerability?" This gives us peace of mind that we will be notified when these types of things occur, so we can then respond to them. 

How has it helped my organization?

One of the things that it detected was a small library that we use to generate PDFs. It pointed out this needed a purchased license. We had already bought the license because we did have some people in-house who were aware of that. However, it's still one of those things where I can see this easily going wrong for companies who are younger and don't pay as much attention to this type of stuff.

When IQ Server finds a problem a Jira ticket is created and an email is sent out. Usually, one of our technical people will check it out right away to see if this is something that can be simply scheduled in the next sprint or if it's something big. If it is something big that affects us and needs to be addressed right away, I know that we would likely be able to address it almost immediately, either by doing an update of the library or mitigation. We should be able to start work on it almost immediately. In very severe cases, we should be able to do this in just a matter of hours. We should be able to update our environments after we get a notification that the problem exists.

We have had cases where we wanted to add certain libraries, but the Nexus IQ IDE plugin showed there were some security issues with this library. Instead of using it, we found an alternative right away. Because it is easy to have this information available, it saves us the hassle of having to refactor later.

Nexus IQ Server has made it easier to address company or legal policies when it comes to the libraries we use. Sometimes, as a developer, you don't think about the legal aspects of a free and open source software. While we were aware that you occasionally need to buy a license for something, we're also paranoid of falling victim to giant lawsuits because we overlooked something in the license. We did have some enforcement of this before using Nexus IQ Server, but it would be done periodically and sometimes long after implementation of a problematic library was already done. Now it's all categorized in one place and we can very easily check license issues ahead of time. The awareness was there before, but now we have a definite way that it's all completely indexed. Enforcement is now easier and nothing can slip through the cracks. Everything is checked and will be reviewed unless someone specifically says, "This license is okay and you can use it."

It triggered a review of everything that's used and their licenses, since there are so many different open source licenses. Someone does have to go through each license and actually check off on it, with IQ Server we were able to do that more easily. It provides an ease of mind that if anything really bad would pop up, then it would easily show us in the report that it's there.

Since we started using IQ Server we have received a number of alerts regarding newly discovered security vulnerabilities in libraries we use in production. When that happens we delve in to it almost immediately. Up until now all of them have turned out to be for specific use cases that didn't actually occur in production. Just as a precaution though, we still schedule tickets to have such libraries updated anyway, in case it's later discovered that there are additional use cases that would allow exploitation of the vulnerability in production.

What is most valuable?

IQ Server also checks the overall quality of library. Often as a developer, to solve a certain programming problem we do some research online and may find suggested open source libraries that would address what we need. However, we don't always check how old it is or how maintained it is, but that is another thing that IQ Server will point out. "This version (or the whole library) you are using is like five to six years old. Maybe it's time to check if there are alternatives which are better kept up." That's another useful thing for us.

We enjoy how it works together with other stuff that we have. We integrated it with Jira to keep track of things. We have it set up so it will generate tickets in Jira automatically when it finds something, then those can be added to our sprints.

The quality of data seems very thorough. It compiles data from a couple of different sources. Sonatype double checks the vulnerability itself. I've seen instances where there will be a message saying something like, "According to official sources, this only occurs in version 4.2 or later, but our research team indicates that the vulnerability also exists in versions 3.x." This shows IQ Server gives you more information than what we previously would find, unless we did a lot of research and happened to stumble on that piece of information. Busy developers will usually prefer to spend the majority of their time implementing features and fixing bugs to meet customer time lines rather than indefinitely research possible vulnerabilities in a library they want to use. The information that we're getting through IQ Server makes it all easily accessible, and it's also thorough and comes with steps and descriptions of when this issue occurs for specific use cases, so it allows our developers to not lose a lot of time on research.

What needs improvement?

One of the things that we specifically did ask for is support for transitive dependencies. Sometimes a dependency that we define in our POM file for a certain library will be dependent on other stuff and we will pull that stuff in, then you get a cascade of libraries that are pulled in. This caused confusing to us at first, because we would see a component that would have security ticket or security notification on it and wonder "Where is this coming in from?" Because when we checked what we defined as our dependencies it's not there. It didn't take us too long effort to realize that it was a transitive dependency pulled in by something else, but the question then remains "Which dependency is doing that?" This is the biggest thing that we have talked to Sonatype about. Even though we have found an way to see where transitive dependencies are coming from, it would be nice if this was visible through IQ Server as well.

Another issue is that, although Sonatype categorizes and indexes a lot of different repositories, it doesn't index every single repo in existence. One of the components we used switched where it came from, so a later version was actually coming from a different repository that Sonatype didn't index, as it was relatively smaller. They cover a large amount of available libraries, but they don't cover 100 percent of them. In this case, that component that was marked as an unknown component. When we get this kind of notification, we have to double check it. That is how we found out that these are components aren't covered by Sonatype yet. We have put in requests to have this particular repository added to the sources Sonatype indexes. It's something to be aware of if you use obscure repositories.

For how long have I used the solution?

We set it up in July 2019. Therefore, we have been using it about seven or eight months.

What do I think about the stability of the solution?

The stability is good. We have never had an issue with it being unreachable. I've not noticed any downtime with it. 

The single issue and change that our administrator ran into was that after he setup the solution, it used a file database locally. After he switched it from running in the foreground to running as a service on a VM, we realized that the database was gone, it had somehow reset. He was able to find the previous file used as the database though and successfully migrated the data to Postgres. That was all the way in the start and we noticed the issue right away. After that, we've had no issues with it.

Our system administrator has not had any issues installing updates to IQ Server.

We haven't had any major security things that we had to fix last minute or on production, which is a good thing. However, we have had vulnerability issues come up. We were able to check them out and notice that they wouldn't affect us immediately because they applied to a specific use case which doesn't occur in our application. However, it does show that things come up. Security issues are found, and if we would've done a manual scan with our previous product/project, we may not have known that something happening on production or we would have found it a lot later. Whereas now, these things pop up right away. It has seemingly increased the overall stability and how fast we can respond to things.

We think about software issues in healthcare. We always want to be very careful of security things in this application because of HIPAA and patient privacy and vulnerabilities to applications from things like ransomware. We get questions about this stuff from potential clients about how we can protect ourselves. We have continuous monitoring of security vulnerabilities, which is very good advertisement for our company. This was not something we could say before because we'd have to do it manually. Sometimes, a few months would go by before we could run another scan.

What do I think about the scalability of the solution?

We have a relatively small number of people using IQ Server, consisting mostly of a few developers and project managers. Under those conditions it is performing very well. We have plenty of room to grow with it. We don't have any huge plans to expand use of the solution because it's fulfilling our current needs.

How are customer service and technical support?

We filed a ticket for some unknown components and got quick feedback. They gave us pointers on how to figure out what it is. One of the things that we were impressed with was that they wanted to do a review of how we were using it after a few months. I guess this is a problem with us technical people. We often don't like reading manuals and like to figure out how stuff works. I initially was skeptical, but I figured that if they were offering it we should do it.

They had us show them how we had set it up, then they had a number of pointers for how we could improve it. E.g., we weren't fully using the JIRA integration and notifications and they pointed that out. There were a few other things they pointed out as well, such as a list of things for us to double check, like whether all our Javascript libraries and open source Javascripts were indexed correctly. Double checking that is what actually triggered the unknown component notification because we weren't 100 percent sure what it was. They then talked us through how to handle those. I'm happy they reached out to do the review. A lot of times, after you buy a piece of software, you just cost the vendor money every hour that they spend on you. In this case, the review was offered and initiated by them. We really appreciated that and we have had good experiences with them as a company.

It has been fun to work with Sonatype. We have been happy with them as a company.

Which solution did I use previously and why did I switch?

We were using a product before and weren't super happy with it. I found this solution through an Instagram ad. I don't even know how it popped up there, but it was an ad on Instagram that was from Sonatype about one of their free publications that you could get about issues in DevOps. After that, we talked as a team, decided to check it out, and that's how it happened. As annoyed as I've been by those Instagram ads, this one actually worked out very well for us. I guess for Sonatype too.

We used a different enterprise solution (Palamida/Flexera) previously which was a bit cumbersome to run. It would only check when we manually triggered it. Previously, because the scan was sort of deferred, you would find out a month or two later (or whenever you did the scan) that the library might have an issue. Then, we would have to find an alternative library. However by that time, you've already used it and have to refactor what you were doing before. A refactor like this will take time away from our developers and testers and also will require a redeploy. The process now is a lot smoother because the scan is done automatically and immediately after each build, so we get feedback right away.

Additionally, with the plugin for our IDE that Sonatype provides, we can check whether a library has security, quality, or licensing issues very easily. Which is nice because Googling for this stuff can be a bit cumbersome. By checking it before code is even committed, we save ourselves from getting notifications at all.

Nexus IQ Server integrates well with our other ecosystem. Palamida required us to run it locally, like physically, because they would send you the hard drives that had all the mappings on it. These were used to index the components our software is using. We had trouble trying to figure out how to keep it up to date because they would have to send this to us every couple of months or so. Whereas now, we're running IQ Server in AWS and it actually connects to Sonatype's own service for updates. These live updates are a huge improvement to what we were using before.

Releasing a new version of our application used to take between three to six months. What would happen is before we would release it, that's when we'd do a scan and see if there was anything that we needed to fix. We have had it where enough issues came up where we're like, "We need to decide should we still release this or continue trying to work out all these different issues, then release it?" This would push back the release by two to four weeks. Now, because it's a continuous process and we can evaluate new components early on, it doesn't mess with that timeline so much. We know what the status is already at this point. If something comes up, then we can address it right away instead of having to do it near the end. It has helped us to solidify timelines a bit. Because of it, we have not had a delay in a release due to unknown security issues that we found near the end of our version release cycle.

How was the initial setup?

On June 26, we got our license key for it. It was a week or so to get the whole thing up and running, from getting license keys to telling our IT department to set up the VM and install it, and then logging in to configure it.

The initial installation was rather straightforward. It was easy for me because we have a system administrator who takes care of it. But he did not report having any problems installing it. He had to also set up a database, then figure out some of the networking stuff, as sometimes the connectivity with the cloud services behind a VPN gets a bit tricky. But all in all it was fairly straight forward to integrate it. Once in the same virtual network, our VMs, Bamboo service, and Jira talked to each other and didn't have any issues. Installing updates has been straightforward as well.

Obviously there's a learning process that starts when you first log in. But things are pretty easy to figure out. Besides that Sonatype's support has been very good. They showed us how to use it immediately after installation, and they followed up some time later to see how we've implemented using it. They had some very useful tips and pointers at that time too. We've been impressed by their user support.

What about the implementation team?

We had a call with the Sonatype team and they talked us through the setup. Their assistance with it was really good. That may have mitigated any complications that we would've had. As far as I'm aware, even the installation of the application was easy.

The DevOps stuff is a combo between the system administrator and developers. After he does all the VM and networking setup, we do the configuration from within the application once it is ready. I did some of the integration with Bamboo, then another developer set up the integration with Jira. I'm sure there are plenty of people who have the skill set which covers all those things and would be able to do the deployment with just one person. 

All our system administration is done by a company called Infidati. We've been using them for a long time, about five to six years and our experience with them has been excellent. They are fully remote, my immediate boss is the only one who has met people from their company. We mostly communicate with them through their email ticketing system. They're an easy, wonderful company to work with that has great response times.

What was our ROI?

This product was cheaper than the one we were using, so that is a direct savings. Though, it's hard to estimate time saved.

There is definitely a lot less frustration with it, because we had some frustration earlier with the last product. Some of the frustration that we still have was trying to find an updated version of the library, which is not really Sonatype's fault. That is just how open source software works. However, there is definitely a lot less frustration with a lot more clarity about what exactly we're looking at and what the step is needed to get rid of the vulnerabilities that we do find. It's hard to measure the impact of reducing developers' frustration, but I think we can all agree that having happy developers is good for a company!

Another thing that's hard to measure is the positive impact on company image. We get security questionnaires from potential clients, which will ask how we detect and address security issues. In our industry, what is that worth to a health system that houses patient information that we continuously monitor for security vulnerabilities? And that we are able to address these concerns as soon as they come out? It's a marketing thing and it's hard to quantify what that's worth, but we know in healthcare these things are definitely valued and appreciated.

What's my experience with pricing, setup cost, and licensing?

In addition to the license fee for IQ Server, you have to factor in some running costs. We use AWS, so we spun up an additional VM to run this. If the database is RDS that adds a little bit extra too. Of course someone could run it on a pre-existing VM or physical server to reduce costs. I should add that compared to the license fee, the running costs are so minimal they had no effect on our decision to use IQ Server.

The license fee may be a bit harder for startups to justify. But it will save you a headache later as well as peace of mind. Additionally, it shows your own customers that you value security stuff and will protect yourselves from any licensing issues, which is good marketing too.

Which other solutions did I evaluate?

We did not evaluate other options. Though, we did compare it to what we were using. When we looked at what Sonatype did and how it was able to run in the cloud, we were eager to give it a shot. We honestly didn't do extensive research into other alternatives. We knew we wanted to switch from what we were using rather quickly and Sonatype's response time was very good.

What other advice do I have?

Do it as early as possible. You will have to clean up sooner or later. I remember when we fired it up it immediately found things that the last solution didn't find. This made sense after we realized that IQ Server gets continued updates and our last solution was just getting updates whenever we were able to get new hard drives sent to us. Our first scan popped up with a number of high vulnerability and security issues. At that time the Sonatype people were on a call with us to help us out setting it up. We asked them if seeing this many alerts was pretty average and they told us it was pretty normal in their experience. So that's when the cleanup started.

Our awareness of how many of these open source libraries have things that you got to watch out for has increased a lot. We would find some stuff out through our previous solution, but sometimes it was unclear exactly how serious it was, where it came from, or how to fix it. Additionally we've gotten a lot better at manual dependency resolution, because sometimes the problematic version of a component you're trying to eliminate is a transient dependency. so you have to figure out which alternative version you can use and then tell the top level dependency to use that instead.

None of our people who went to college to learn how to write software or do Java certification remembers ever getting a class on how to deal with these kind of things. Nobody remembers taking a class where they warn future developers: "You're going to have licensing issues that you will need to solve. You will need to do dependency resolution and be asked to mitigate security issues in this stuff as you use it." But this is actually a pretty important aspect of proper software development. Our team already had this awareness, but now it is now something we can also easily check. It is a continuous part of our sprints to check and handle notifications of these security issues. We've had to learn a lot more about how to fix transitive dependencies.

While we don't have integrations directly with our version control systems, we do integrate with our continuous integration service and ticketing system. We use a host of Atlassian products: Jira is one of them and Bamboo is another. You can use this solution to automate open source governance and minimize risk. E.g., we could have a build fail when it finds security issues, but we have not done that for our development and test environments as of yet. The solution also integrates with things like user directories.

We did look through the default policies. We also received some help from Sonatype to go over them. As a default, the security policies were good. Therefore, we decided to stick with them.

I would give the solution between an eight and nine (out of 10). If there was a way to easily see where a transient dependency is pulled in from, and if Sonatype would add a few more of the repositories that we pull dependencies from, then I'd probably give them a 10 (out of 10).

Which deployment model are you using for this solution?

Private Cloud
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Julien Carsique - PeerSpot reviewer
DevOps Engineer at a tech vendor with 51-200 employees
Real User
We no longer have to write or maintain scripts, but important features are still missing
Pros and Cons
  • "The REST API is the most useful for us because it allows us to drive it remotely and, ideally, to automate it."
  • "We do not use it for more because it is still too immature, not quite "finished." It is missing important features for making it a daily tool. It's not complete, from my point of view..."
  • "It's the right kind of tool and going in the right direction, but it really needs to be more code-driven and oriented to be scaled at the developer level."

What is our primary use case?

We have many use cases. Our main use case is focused on Nexus Repository and a little bit on Nexus IQ, including Lifecycle. The basic use case is storing Maven, Java, JavaScript, and other kinds of artifacts. For some years now we have implemented more complex solutions to manage releases and staging. Since Nexus Repository introduced that feature for free and natively, we moved to the feature provided for managing release staging.

How has it helped my organization?

It has only improved things very little because, for now, we use the reports from IQ to improve the libraries, but it doesn't yet have enough coverage.

It has helped to enforce open-source intelligence and policies across our software development lifecycle, mainly by automating controls that we had put in place before. It has helped to enforce things. It has blocked some open-source components or, more accurately, raised warnings about them. It's not a blocker in our system because, for now, it's only implemented as an informative system.

The solution has also improved the time it takes to release secure apps to market. We have been able to replace homemade scripts, which took a few hours to create, by very much simpler workflows provided natively by Nexus, which are working in a few minutes, or tens of minutes. It has saved us about 40 percent, in terms of time. But more than the duration, it's helpful that we don't have to maintain or make scripts. That's the most important thing.

It has improved developer productivity and accuracy. That happened a long time ago because we have been using it for so long, but as soon as we deployed the Nexus solution in the company, people didn't need to locally build a lot of stuff. So we were much more easily able to work together, to collaborate, and consume other teams' products. That was a long time ago, but it was definitely an important step.

What is most valuable?

The REST API is the most useful for us because it allows us to drive it remotely and, ideally, to automate it.

We have worked a lot on the configuration of its capabilities. This is something very new in Nexus and not fully supported. But that's one of the aspects we are the most interested in.

And we like the ability to analyze the libraries. There are a lot of filters to output the available libraries for our development people and our continuous integration.

The solution integrates well with our existing DevOps tools. It's mainly a Maven plugin, and the REST API provides the compliance where we have everything in a giant tool.

What needs improvement?

We do not use it for more because it is still too immature, not quite "finished." It is missing important features for making it a daily tool. It's not complete, from my point of view. All the Lifecycle tools are not yet finished and usable in production. We are using it in production, but it's not fulfilling all our needs. It's not yet finalized.

It's the right kind of tool and going in the right direction, but it really needs to be more code-driven and oriented to be scaled at the developer level. Nowadays, developers need to be autonomous, so we need to be able to supply them tooling and then everything should be orchestrated around the principle of GitHubs. That is really important in IQ because developers will want to make changes and they need things very quickly. Everything should be driven by that but that is not yet the case. The features are interesting but the way those features are configured and tuned is not quite there yet.

There is room for improvement in the way it is managed, having code-driven configuration, and automation. It needs not to be an old-style tool. Today, a computer tool must be usable in many ways: as a client for developers, as a webpage and reporting tool for managers, and as an automated blocker for continuous integration. It must have a REST API and it must have many features that make it usable in many ways. Currently, that's not the case. 

One thing I can say that is very positive is that it is much better than the other tools. But regarding usage, it's not perfect. It's missing everything around the tuning and usage.

For how long have I used the solution?

We have been using Nexus Repository, version 2, for about 10 years or so. We switched to the Nexus 3 a little bit more than one year ago, along with Nexus Lifecycle.

What do I think about the stability of the solution?

Nexus 3 is not yet stable enough. IQ is perfectly stable. We have not had any stability issues with it.

What do I think about the scalability of the solution?

It is currently not scalable. While we haven't encountered a scalability issue regarding Nexus IQ directly, but for maintenance and configuring there is a scalability issue because developers need to make modifications and reports. And those modifications must follow our workflow model, things like a code review and evaluation by a manager. Currently, this is not possible. They cannot make a request for changes in the software. There is no solution to contribute changes and that is a scalability issue. That is with respect to Nexus Lifecycle.

With Nexus Repository, we had a lot of scalability issues with version 2. With the new version 3, we tried to set up a certain type of architecture but it is not available. So scalability is an issue regarding the load, not the amount of data. We have been using Nexus software for 10 years now with very big storage and that is not an issue. But when the number of users increases, that's an issue. We are an open-source company, so we have many consumers of our artifacts, and that means there can be a heavy load on the projects.

Which solution did I use previously and why did I switch?

Twelve years ago we tried other solutions, like Artifactory. But we quickly moved to Nexus. We may change the solution in the next month or year. It's a possibility. It depends on the pricing and whether the solution provides HA.

The main purpose of using the IQ solution was to have an efficient solution to spot and block security risks. We tested and compared a lot of solutions and found that IQ was the best and the most evolved. But a lot of it is not completed, it's still a prototype, from my point of view. That means it cannot yet be used exactly the way it is marketed. There are some features that are missing. But compared to other products on the market, it appeared to be the most accurate one.

How was the initial setup?

My team was responsible for setting up the whole system. It was complex in the end because the way we wanted to set it up was not yet defined. It was not designed to be used the way we want to use it.

For IQ, the deployment only took a few days, but it's not usable yet. We set it but we are not really using it as we wanted to. For Nexus Repository, it took many months and many issues are not resolved yet. The fact is that IQ is not very useful without the repository.

Internally, we had a deployment plan, but a lot of those requirements were not met by Sonatype and we have had to work with support to make it work. But there are still remaining issues.

What about the implementation team?

Sonatype assisted us with the initial setup and their help was average. It was pretty good most of the time, but sometimes it was not because we were outside of their defined environment. I feel that they are a little bit behind in this field, that they are missing modern requirements. So their support was pretty good, but not enough.

Which other solutions did I evaluate?

We evaluated Artifactory by JFrog. It also seemed very good, very similar. The other solutions we tried were not as good. Nexus and Artifactory were the finalists.

At the time, the UI was a difference between them, but that is not true anymore. The two are very similar now. The integration with development tools was very important; the ability to implement GitHubs, and so on. The fact of being open-source is very important to us; being able to contribute to and look at the code for reliability and quality.

What other advice do I have?

My advice would be to look at your needs and the features the solution provides. In the last version they released, we were a little bit disappointed by the difference between the marketing and the reality. The product was not yet finished compared to how it was described. Aside from this bad aspect, it's mainly about good practices and looking at common, standard practices. Start with the basics and common stuff and try to evolve it eventually and change some things. Don't try doing something too much complex at the beginning.

The tool's default policies and the policy engine seem pretty good. We have been using it for so long that we are using our own policies. Regarding Lifecycle, we have not gone far enough with it to have a real opinion on it, although it looks consistent.

In terms of its integrations into developer tooling like IDEs, Git repos, and automated pull requests, we have not used it enough. It is a little bit too soon for us. It's a goal, but we want it to be done in a transparent way through the automation. It's not used yet because all of the developers are free to choose the tools they use, the IDEs, and only a few people are looking at this kind of stuff.

Internally, we have about 50 developers for Nexus Repository. We have five to 10 specialists for the Nexus IQ. We don't know many customers there are for Nexus Repository in our public sphere.

It is used across the whole company. It's a central tool and most people in the company cannot work without it. Everybody uses it either directly or indirectly or by proxy. Some people use it without knowing it, but all the technical people in the company are using it, so around 150 depend on it.

For deployment and maintenance of the solution there have been three people on my team doing this, but that was not the only responsibility of the team and they were not enough. We spent a lot of time setting up automation, including maintenance and deployment, and that made it scalable for three people in maintenance. We had to work on this. It was not provided natively, but now three people are enough.

I would rate IQ at six out of ten. That's very good compared to other products on the market.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Julien Carsique - PeerSpot reviewer
Julien CarsiqueDevOps Engineer at a tech vendor with 51-200 employees
Real User

s/GitHubs/GitOps
Read "GitOps", not "GitHubs", as described in https://www.cloudbees.com/gito... and https://www.weave.works/techno...


The idea is to work with code everywhere, with Git (indeed GitHub) as a central underlying technology. Not only managing the infrastructure as code but also the application configuration and content.
Two examples here: contribute configuration changes from the code such as new repositories, contribute rule changes from the code such as blacklist libraries. That allows to perform GitHub Pull Request, Code Review and Merge following the modern workflows the developers are used to, and then control the same way the deployment to production.


That is distributing and scaling the responsibilities (and abilities!) to the relevant people and teams, with full security, audit, automation and unique source of truth from end to end.

Sr. Enterprise Architect at MIB Group
Real User
Provides us with ease of development, the ability to automate a lot of the build-and-deploy process
Pros and Cons
  • "Some of the more profound features include the REST APIs. We tend to make use of those a lot. They also have a plugin for our CI/CD; we use Jenkins to do continuous integration, and it makes our pipeline build a lot more streamlined. It integrates with Jenkins very well."
  • "Some of the APIs are just REST APIs and I would like to see more of the functionality in the plugin side of the world. For example, with the RESTful API I can actually delete or move an artifact from one Nexus repository to another. I can't do that with the pipeline API, as of yet. I'd like to see a bit more functionality on that side."

What is our primary use case?

We are using the Nexus Repository Manager Pro as exactly that, as an artifact repository. We tend to store any artifact that our application teams build in the repository solution. We also use it for artifacts that we pull down from open-source libraries that we use and dependencies that come from Maven Central. We use it to proxy a few places, including JCenter. We also use it as a private Docker registry, so we have our Docker images there as well.

We're on version 3.19. We also have Nexus IQ server, which wraps up within it Nexus Firewall.

How has it helped my organization?

We have a lot of legacy applications here and they're all built with Ant scripts and their dependencies come from a shared folder. There's not a lot of "accountability" there. What we get out of using Nexus is that all of our dependencies are in the same place and we can specify a specific version. We no longer have a situation where somebody has pulled down a .jar file and stuck it in this folder and we don't know what the version is or where, exactly, it came from. That's one of the benefits.

Another of the main things we get is what Sonatype calls a "bill of materials." We can go into our Nexus product and say, "Okay, here is our ABC application. What are its dependencies?" And we can be specific down to the version. We know what's in it and, if a vulnerability gets reported, we can look and see if we use that particular component and in which applications, to know if we're vulnerable. If we find we're exposed to that vulnerability we know we need to go and remediate it.

The biggest benefit we get out of it is the overall ease of development. The ability to automate a lot of the build-and-deploy process comes from that.

The data quality helps us solve problems faster, as in the security vulnerability example I just mentioned. In those circumstances, we have to solve that problem. Previously, we wouldn't have seen that vulnerability without a painstaking process. Part of the Nexus product, the IQ Server, will continually scan our components and if a new CVE is reported, we get that update through Nexus IQ. It automatically tells us, "Hey, in this open-source library that you're using, a vulnerability was found, and you use it in these four applications." It immediately tells us we are exposed to risk and in which areas. That happens, not in near real-time, but very quickly, where before, there was a very painstaking process to try to find that out.

A year ago we didn't have DevOps tools. We started building them after I came on. But Nexus definitely integrates very well with our DevOps tools. Sonatype produces plugins for Jenkins to make it seamlessly interact, not only with the repo product, but with the Nexus IQ product that we own as well. When we build our pipelines, we don't have to go through an array of calls. Even their command-line is almost like pipeline APIs that you can call. It makes it very simple to say "Okay, upload to Nexus." Because Jenkins knows what Nexus is and where it is — since it's configured within the Jenkins system — we can just say, "Upload that to Nexus," and it happens behind the scenes very easily. Before, we would have to either have run Maven commands or run Gradle commands via the shell script to get that done. We don't need to do that sort of thing anymore.

The solution has also brought open-source intelligence and policy enforcement across our SDLC. We have defined policies about certain things at various levels, and what risks we're willing to expose ourselves to. If we're going to proxy a library from Maven Central for example, if the Nexus IQ product says it has a security-critical vulnerability or it's "security high" or it's "component unknown," we can set different actions to happen. We allow our developers to pull down pretty much anything. As they pull something down from say, Maven Central, it is scanned. If it says, "This has a critical vulnerability," we will warn the developer with the report that comes out: "This has a security-critical vulnerability. You're allowed to bring it down in development, but when you try to move to QA or staging, that warning about the 'security-critical' component will turn to a failure action." So as we move our artifacts through that process, there are different stages. When someone tries to move that component to our staging environment, it will say, "Oh no, you can't because of the security-critical thing that we've been warning you about. Now we have to fail you." That's where we get policy enforcement. Before, that was a very manual process where we'd have to go out and say, "Okay, this thing has these vulnerabilities, what do we do with it?" It's much more straightforward and the turnaround time is a whole lot faster.

Automating open-source governance and minimizing risk is exactly what Nexus is for. Our company is very security conscious because we're governed by a number of things including the Fair Credit Reporting Act, which is very stringent in terms of what we can and cannot have, and the level of security for data and information that we maintain. What Nexus does is it allows us to look at the level of risk that we have in an application that we have written and that we expose to the companies that subscribe to us. It's based on the components that we have in the application and what their vulnerabilities are. We can see that very clearly for any application we have. Suppose, all of a sudden, that a Zero-day vulnerability — which is really bad — is found in JAXB today. We can immediately look for that version in Nexus. We can see: Do we have that? Yes, we do. Are we using it? Yes, we are. What applications are we using it in? We can see it's in this and that application and we can turn one of our teams to it and get them to address it right away.

I don't know exactly how much time it has saved us in releasing secure apps to market, but it's considerable. I would estimate it saves us weeks to a month, or more, depending upon the scope of a project.

And it has definitely increased developer productivity. They spend a lot less time looking for components or libraries that they can download. There was a very manual process to go through, before Nexus, if they wanted to use a particular open-source library. They had to submit a request and it had to go through a bunch of reviews to make sure that it didn't have vulnerabilities in it, and then they could get a "yes" or "no" answer. That took a lot of time. Whereas now, we allow them to download it and start working with it while other teams — like our enterprise security team — look at the vulnerabilities associated with it. That team will say, "Yeah, we can live with that," or "No, you have to mitigate that," or "No, you can't use this at all." We find that out very much earlier in the process now.

It allows us to shift gears or shift directions. If we find a component that's so flawed that we don't even want to bring it into the organization from a security standpoint, we can pivot and say, "Okay, we'll use this other component. It doesn't do everything we needed, but it's much more solid."

What is most valuable?

I won't say there aren't a ton of features, but primarily we use it as an artifact repository. Some of the more profound features include the REST APIs. We tend to make use of those a lot. They also have a plugin for our CI/CD; we use Jenkins to do continuous integration, and it makes our pipeline build a lot more streamlined. It integrates with Jenkins very well.

The default policies and the policy engine provide the flexibility we need. The default policy was good enough for us. We didn't really mess with it. We left it alone because the default policy engine pretty much works for our use cases.

The integrations into developer tooling work just fine. We primarily use Gradle to build our applications. We just point the URL to what we call our "public repository group" in Nexus. It's a front for everything, so it can see all of the other underlying repositories. Our developers, in their Gradle builds, just point them to this public repository and they can pull down any dependency that they need. It doesn't really integrate with our IDE. It's just simply that we use Gradle and it makes it very straightforward.

Nexus blocks undesirable open-source components from entering our development lifecycle because of the IQ policy actions. We define what sort of level of risk we're willing to take. For example for "security-critical," we could just fail them across the board; we don't want anything that has a security-critical. That's something we define as a CVE security number of nine or 10. If it has a known vulnerability of nine or 10 we could even stop it from coming down from Maven Central; it's quarantined because it has a problem that we don't want to even introduce into our network. We've also created our own policy that we call an "architecture blacklist," which means we don't want certain components to be used from an architectural standpoint. For example, we don't want anybody to build anything with Struts 1. We put it on the architecture blacklist. If a component comes in and it has that tag, it fails immediately.

What needs improvement?

Some of the APIs are just REST APIs and I would like to see more of the functionality in the plugin side of the world. For example, with the RESTful API I can actually delete or move an artifact from one Nexus repository to another. I can't do that with the pipeline API, as of yet. I'd like to see a bit more functionality on that side.

For how long have I used the solution?

I, personally, have used Nexus for a number of years. I have been with my current company, MIB, for just over a year. We brought it in just over a year ago right after I started.

What do I think about the stability of the solution?

I've had no trouble with it. We're currently running it even on a single server and we don't have many problems with it. It seems very easy to move into what we call a high-availability mode. Upgrades to a new version are done within a 30-minute timeframe, so we can easily schedule them.

What do I think about the scalability of the solution?

Even though we don't employ it in a high-availability mode, looking at the documentation, it's very easy to scale out. You can put up multiple servers and point them at the same shared file system. Sonatype also has a cloud offering if you want to go completely hands-off. But it seems to scale very well. We haven't had to scale it yet, but it seems very straightforward to do so.

How are customer service and technical support?

We talk with John Burke, our rep at Sonatype. He was originally our sales rep and now he's their regional sales director and we have a new sales rep. But we still keep in very close contact with John.

Sonatype also has a concept, a position called a success engineer. We have regular meetings every two weeks with a representative from Sonatype. We talk about our implementation, where we are, where we want to go, and how we can get to the point that we need to be at. We are still very engaged with them.

Technical support is great. But because we also have this customer success engineer, a lot of times if we have questions on how something works, we can ask him. While he's not a technical expert, he's a very good end-user person. He can say, if we need to change how a policy works or we want to do this or that, "Well here, you go in here and you do that." We get some ongoing customer support from that customer success engineer. 

We have only set up two technical support tickets with them and they've been pretty good about them. I have nothing bad to say about the technical support. They've stepped up when we have needed them to.

Which solution did I use previously and why did I switch?

We weren't using anything prior to this.

How was the initial setup?

Having set it up myself in previous companies, I know there are ways to set it up that are easy. You can just drop a .war file into a Tomcat container and you're set up. You then just have some configuration to deal with. 

We didn't do that. We set it up as a process on a host server and set it up with specific memory and a very specific file system for it. We had help with that from Sonatype. We had a Professional Services person here who set that up with us.

We were done in one day. From downloading the executable, to running it, to installing it, to having it set up and configured, it was done in a day, but again, we had Professional Services here for that day.

Our strategy was to implement the repository first. But we also added Nexus IQ. Sonatype has best practices for this and, while we were close to what they offered, we weren't exactly it. So both of those servers are on the same physical hardware. Sonatype recommends separating Repository and IQ Server on different servers, but we didn't do that. Our implementation isn't fast enough to really warrant that. We're a smaller shop so we don't really need that vastness of setup.

What about the implementation team?

The person who came out to help us actually runs Sonatype's customer service center. We keep in very close contact with them.

What was our ROI?

In the productivity, and the turnaround time of producing new applications and updating old applications, the return on investment is that it takes much less time to add features or produce a new product out to our subscribers than it did before. That allows us, obviously, to start billing for those services sooner. Without Nexus, it would take a considerably greater amount of time. Our return on investment is based upon how many applications we bring out and the turnaround time of the development team.

What's my experience with pricing, setup cost, and licensing?

I'm not involved in the financial aspects, but I don't think it's overly expensive. We use the professional version. There's an open-source version that would cost us next to nothing, but we do use the professional version.

Which other solutions did I evaluate?

We did look at Artifactory and one other solution when we were doing our due diligence before picking a product. We did a proof of concept for Artifactory, but we ended up choosing this one.

What other advice do I have?

Nexus Repository is a very specific product. It does very specific things. It's an artifact repository. I would suggest, if you're starting out, to start out with the open-source version and see if it meets your day-to-day needs. If it does, as you start to use it your development teams come to rely on it and it becomes one of those things that if it were to go down, all of your development would stop. So it mandates you to look at the professional version so that you get some backend support from Sonatype in the case that something should happen to it.

Our company, as a whole, has about 150 employees, but not everybody uses it. There's a group repository that's open and anyone can go to it. You can pull down anything you want, anonymously. You don't even have to log in. But there are very few people — four Nexus admins — who can upload stuff. And on our continuous integration server, Jenkins, those four are the only users who can upload anything or push anything into the repository. Our developers don't push anything into the repository. They build some stuff, they check it into Source Control, and then the continuous integration engine sees that, picks it up, builds it, takes the artifacts, and puts them into Nexus. The lion's share of the users who use it are pulling stuff down from it to their desktops and into their IDEs. There are about 25 of those users. They use it to pull dependencies and other things and then they check it into a source code repo and Jenkins takes over from there and does the building and the deploying, etc.

For maintenance and deployment, we usually have a staff of two, although we currently have only one. I will back-fill that as needed. But there's really no maintenance that we have to do to, other than updating to newer versions from time to time.

I would rate it at about a nine out of 10. A perfect 10 comes from what I mentioned earlier. I would like to see a little bit more functionality from the CI plugin aspect. I'd like to be able to do more of what I can do with the REST APIs, in the plugin, so I could automate some of those tasks. But that's the only negative thing I have to say about it.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Wes Kanazawa - PeerSpot reviewer
Sr. DevOps Engineer at Primerica
Real User
Enables our developers to proactively select components that don't have a vulnerability or a licensing issue
Pros and Cons
  • "The proxy repository is probably the most valuable feature to us because it allows us to be more proactive in our builds. We're no longer tied to saving components to our repository."
  • "It would be helpful if it had a more detailed view of what has been quarantined, for people who don't have Lifecycle licenses. Other than that, it's pretty good."

What is our primary use case?

We're using it to change the way we do our open-source. We used to actually save our open-source and now we're moving towards a firewall approach where we are proxy to Maven repos or NPM repos, and we are using those proxies so that we can keep ourselves from pulling in known bad components at build time. We're able to be more proactive on our builds.

How has it helped my organization?

It's allowed our developers, instead of waiting till the last minute before a release, to know well ahead of time that the components are bad and they are able to proactively select different components that don't have a vulnerability or a licensing issue.

Also, the solution's data quality seems to be good. We haven't had any issues. We're definitely able to solve problems a lot faster and get answers to the developers a lot faster.

And Nexus Lifecycle integrates well with your existing DevOps tools. We were able to put it right into our build pipelines. We use Jenkins and we're able to stop the builds right in the actual build process whenever there's a quarantined item.

In addition, it has brought open-source intelligence and policy enforcement across our SDLC. It has totally changed the way we do our process. We have been able to speed up the approval process of OSS. Given the policies, we're able to say, "These are okay to use." We've been able to put in guardrails to allow development to move faster using the product. Our pipelines are automated and it is definitely a key component of our automation.

Finally, the developers like it because they're able to see and fix their issues right away. That has improved. For example, let's say a developer had to come to us and said, "Hey, scan this. I want to use it," and we scan it and it has a vulnerability. They've already asked us to do something that they could have done through the firewall product or Lifecycle. Suppose it takes us a day and then we turn around and say, "Okay, here are the results," and we say they can use this version of that product. They've got to download it and see if it works. So we're already saving a day there. But then let's say they have to send it off to security to get approval on something that security would probably approve anyways. It's just they didn't know security would approve it. They would have to wait two or three days for security to come back and give them an answer. So we're looking at possibly saving four days on a piece of code.

What is most valuable?

The proxy repository is probably the most valuable feature to us because it allows us to be more proactive in our builds. We're no longer tied to saving components to our repository.

The default policies are good, they're a good start. They're a great place to start when you are looking to build your own policies. We mostly use the default policies, perhaps with changes here and there. It's deceptively easy to understand. It definitely provides the flexibility we need. There's a lot more stuff that you can get into. It definitely requires training to properly use the policies.

We like the integrations into developer tooling. We use the Lifecycle piece for some of our developers and it integrates easily into Eclipse and into Visual Studio code. It's a good product for that.

What needs improvement?

It would be helpful if it had a more detailed view of what has been quarantined, for people who don't have Lifecycle licenses. Other than that, it's pretty good.

For how long have I used the solution?

We've been using it for about a year now.

What do I think about the stability of the solution?

The stability has been great. We haven't had any issues in the year that we've had it running. So far, so good.

What do I think about the scalability of the solution?

It's probably not that scalable in its current state. That has to do with the way that the applications are designed. I think they're working on that when they start working on the HA solutions. For Nexus and Nexus IQ I think that will change. But right now, it's not very scalable.

How are customer service and technical support?

Sonatype's technical support for this solution has been great. They answer my questions, even my stupid questions. I might be asking them, "Hey, how do I do this? I can't find it." and they'll say "Oh, it's just this button right here." They never make me feel too bad about it.

Which solution did I use previously and why did I switch?

We didn't have something that does what a firewall does. We used a different repository and used Nexus IQ to do the enforcement of policies by scanning OSS's individually. It's nice having it happen automatically on the repositories now.

How was the initial setup?

The directions on the site are good. Once you follow those, you're good. But if you're looking to set it up by just clicking around, you will probably have a hard time figuring it out. But it's easy once you know what you're doing.

From inserting the license file to proxying my first repos, it took about an hour, at the most.

We were doing a conversion. So the implementation strategy, if we're just talking about firewall, was that we already had Nexus. We bought Nexus and the firewall at the same time. Once Nexus was installed and set up, it was a matter of importing our repositories from Artifactory Pro and then connecting the proxy repositories. I can't say there was any "super-strategy." It was just turning it on, getting it going, and then moving the developers over to it using their settings, XML, etc. And we had to set our NPM RC files to point to our new repository using the firewall and, for those repositories that have a firewall, they had to be turned on with them.

What about the implementation team?

We did it ourselves.

What was our ROI?

We don't have any evidence that the solution improves the time it takes us to release secure apps to market because we haven't released an app yet, but I'm sure it will.

Just the dev happiness is already a type of ROI, in addition to how fast they're able to go using it.

What's my experience with pricing, setup cost, and licensing?

We pay yearly.

Which other solutions did I evaluate?

I looked at a few others, like Black Duck, and I was not impressed by them. I didn't get a chance to actually use Black Duck but everything I read said that Black Duck came up with more false positives than Sonatype.

What other advice do I have?

My advice would be to use it as soon as you can. Get it implemented into your environment as quickly as you can because it's going to help. Once you get it, get your devs on it because they're going to thank you for it.

All of our development is happening using the firewall. All our build pipelines are going through there. As far as licensed users go who can look at Nexus, we've got about 35. They range from devs to security personnel to DevOps people.

All our applications are moving over to it, so that's definitely going to increase the usage. We've got about another 200 applications on the board that will come into our greenfield process so they will be pulled straight into that repository using the firewall. It's definitely going to keep growing.

For deployment and maintenance of this solution there is really just our DevOps team of about four people, but I'm primarily responsible.

I would rate it a 10 out of 10. It does everything I need it to do.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Andy Cox - PeerSpot reviewer
Product Strategy Group Director at Civica
Real User
Helps our developers be aware of duplicate components in their code, but .NET open-source licensing recognition needs work
Pros and Cons
  • "For us, it's seeing not only the licensing and security vulnerabilities but also seeing the age of the open-sources included within our software. That allows us to take proactive steps to make sure we're updating the software to versions that are regularly maintained and that don't have any vulnerabilities."
  • "We use Azure DevOps as our application lifecycle management tool. It doesn't integrate with that as well as it does with other tools at the moment, but I think there's work being done to address that. In terms of IDEs, it integrates well. We would like to integrate it into our Azure cloud deployment but the integration with Azure Active Directory isn't quite as slick as we would like it to be. We have to do some workarounds for that at the moment."

What is our primary use case?

We have two use cases. We're predominantly a products company and we scan our products, in a controlled way, to make sure they're not using open-source software. We want to make sure that we're licensed correctly for our products and the way they are deployed. There are also security reasons for making sure that our products aren't introducing vulnerabilities and, if they are, that we can address them. 

And part of our business is that we build bespoke software. Some of our customers want to make sure that the open-source software is being used correctly in the software we build for them. And, again, we want to protect that software against security vulnerabilities that might be introduced by open-source software.

We also use the solution to help with open-source governance and minimize risk. When we are acquiring a new company, for example, we will automatically, as part of the due diligence on that purchase, scan their products to make sure they don't have vulnerabilities that we are not prepared to accept. So it helps us to make sure, before we make any purchase, that the target acquisition is of suitable quality, in terms of its open-source use.

How has it helped my organization?

The solution has improved the way our company functions in terms of the way that developers think about the components that are being built into their products, making sure they're not being duplicated, for example. The developers now understand that there's a cost associated with including open-source. It may not have a licensing fee, but there is a cost associated with it. That sort of education piece has had a big influence.

It has also brought open-source intelligence and policy enforcement across our SDLC. As the teams are setting up their development environments, we have now gotten them to build Sonatype into their development pipeline. They scan their codebase so they actually catch things at the point that they introduce new, open-source software into the products, to make sure they're not actually introducing vulnerabilities or licensing-policy breaches.

Sonatype has also reduced our risk in releasing secure apps to market. Previously, teams would just release without knowing what risks it was exposed to. Now, we can actually do a better risk assessment.

What is most valuable?

For us, it's seeing not only the licensing and security vulnerabilities but also seeing the age of the open-sources included within our software. That allows us to take proactive steps to make sure we're updating the software to versions that are regularly maintained and that don't have any vulnerabilities.

In addition, the default policies, in general, are quite good. We have adjusted slightly but we're fairly happy with the way that's set up. They provide us with the flexibility we're looking for.

The data quality is pretty good. We don't have masses of false positives. There have been some areas around .NET which haven't been quite as good as some of the other areas, but we know work is being done on that. Overall, the data quality does help us solve problems faster.

What needs improvement?

We use Azure DevOps as our application lifecycle management tool. It doesn't integrate with that as well as it does with other tools at the moment, but I think there's work being done to address that. In terms of IDEs, it integrates well. We would like to integrate it into our Azure cloud deployment but the integration with Azure Active Directory isn't quite as slick as we would like it to be. We have to do some workarounds for that at the moment.

Also, the ability of the solution to recognize more of the .NET components would be helpful for us.

For how long have I used the solution?

I've been using Sonatype for about six years.

What do I think about the stability of the solution?

It's a stable product, especially compared to some of its competitors.

How are customer service and technical support?

The technical support is generally good. A couple of years ago there were some things that had been logged and that had to be chased a few times. They didn't go as quickly as we'd have liked. But recently, things have been better and they have been more timely in their responses.

Which solution did I use previously and why did I switch?

Our company tried with Black Duck, but that was it.

How was the initial setup?

The initial setup was straightforward. One of my team members was able to execute it quite quickly without too much trouble or additional help.

It's deployed internally at the moment but, moving forward, we want to move it to a cloud-based deployment.

What was our ROI?

We have seen return on our investment, but it's a difficult one to quantify because, unless you have a problem, it's like any sort of security or testing; it's difficult to quantify unless you have an issue. In terms of protecting our IP it certainly has provided ROI and, in security issues as well, it has helped us to identify them, reducing our risk. There has been a big risk reduction for us.

What's my experience with pricing, setup cost, and licensing?

We pay on a yearly basis.

Which other solutions did I evaluate?

We do a supplier selection every couple of years. One solution that we've evaluated is Black Duck, for example, but it didn't seem to be as stable as the Sonatype solution, when we last tested it.

WhiteSource is another one we tested. It's a cloud-hosted solution so I can't comment on its stability.

Comparing these solutions with Sonatype, the information that comes with Sonatype and its recognition are good. The fact that WhiteSource is cloud-hosted is nice and it's an advantage you don't immediately get with Sonatype. But with WhiteSource we got more false positives than we did with other tools. And Black Duck, when we've last reviewed it, wasn't as comprehensive as what we are looking for.

Sonatype met our needs, what we were looking for, particularly around protection of IP. The knowledge of the Sonatype team, and our good working relationship with them, have helped us to continue to use the product. The fact that they take some of our feedback and incorporate it into the product has also helped.

What other advice do I have?

I would definitely recommend understanding what you're trying to achieve. For us it's quite clear that we want, for the moment, to protect our IP and to identify security vulnerabilities. If the understanding is that you want to protect against open-source from coming into your products in the first place, or you're doing greenfield development, look at the right product stack from Sonatype to make sure that you're choosing the right set of products. We've got a mature product base that we're working with. If you're starting from scratch, you would want to assess what you're trying to get out of your policies and processes around this, and make sure that the products match.

We have about 150 users of Sonatype in our company, and their roles range from managers who review the open-source solutions to make sure they're being licensed properly in the product, to developers who are actually cutting the code. It's also service and project managers looking at their exposure, or maybe the audit team that wants to make sure that there's compliance within the different teams. For deployment of the solution and maintenance we have one person, a junior software engineer.

Sonatype is being used for regular scans on our priority projects, numbering about 20. We plan to eventually get that rolled out much more of our estate, to 50 or 60 business units.

I would rate it at seven out of 10. Some of the scanning around the .NET open-source licensing, the recognition; and the integration with some of our development tools, like Azure DevOps, are where, perhaps, it's lacking.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Scott Hibbard - PeerSpot reviewer
DevOps Engineer at Guardhat
Real User
The analysis provides a lot of very valuable information
Pros and Cons
  • "The integration of Lifecycle is really good with Jenkins and GitHub; those work very well. We've been able to get it to work seamlessly with them so that it runs on every build that we have."
  • "We had some issues, and I think we might still have some issues, where the Sonatype Nexus Repository has integrations with IQ and SonarQube. We're getting some errors on the UI, so we've had Sonatype look into that a little bit."

What is our primary use case?

We have it running on the majority of our builds for all of our applications and we use Jenkins for our build system. Eventually, the goal is to incorporate this into Jenkins so that if we don't get a good enough result on both Nexus IQ and SonarQube, we'll actually fail the Jenkins build. That way we force ourselves to maintain good metrics on both of them. So Nexus IQ is making sure that we're using dependencies that don't have known vulnerabilities. And SonarQube is making sure that our code maintains a certain level of quality.

Unfortunately, we haven't been able to take full advantage of Nexus. It's set up and it's working, but we haven't rolled it fully into our development process. Our builds use it, but we're not using the information from it a whole lot. The solutions are running, but we're not enforcing the results from them and, therefore, our developers aren't driven to make absolutely sure that they are going well. Hopefully, we'll get there soon.

What is most valuable?

So far, the information that we're getting out of both the Nexus Lifecycle and SonarQube tools is really great.

And the integration of Lifecycle is really good with Jenkins and GitHub; those work very well. We've been able to get it to work seamlessly with them so that it runs on every build that we have. That part is easy to use and we're happy with that.

We're able to use Jenkins Pipeline and the integrations that are built into Gradle to incorporate that into our build process where we can have control over exactly when Nexus IQ and SonarQube analyses are run — what kinds of builds — and have them run automatically.

For how long have I used the solution?

We've had it in place for about six months now.

What do I think about the stability of the solution?

Overall, the stability is pretty good. I haven't figured this out yet, but occasionally we do see failures in the Jenkins build. I haven't figured out why yet. I don't know if it's an issue with our Jenkins server or if it's with Sonatype. But otherwise, it seems pretty stable.

What do I think about the scalability of the solution?

We haven't looked at its scalability at this point. We do have plans to use it more in the future, enforcing the results of the analysis to fail builds and force the developers to fix the issues in there before moving on.

How are customer service and technical support?

We've used Sonatype's technical support a few times. We had some issues, and I think we might still have some issues, where the Sonatype Nexus Repository has integrations with IQ and SonarQube. We're getting some errors on the UI, so we've had Sonatype look into that a little bit. 

But they were responsive and had good suggestions, things to try. Overall, they're good.

Which solution did I use previously and why did I switch?

We didn't have a previous solution.

How was the initial setup?

The initial setup was pretty straightforward. The documentation is done well. It was easy to follow and I was able to set it up and get it working without a lot of effort.

I probably spent a day getting it installed, understanding it, and figuring out how to integrate it with our current solution.

In addition to myself, about 10 developers will eventually be looking at it to give them feedback on code quality and dependency management.

In terms of deployment and maintenance, it's me and a little bit of our CTO. He did the installation initially on our server and then I set up the integration with the rest of our process.

What other advice do I have?

So far, it seems to be a good solution and there is a lot of very valuable information that the analysis provides.

Which deployment model are you using for this solution?

Public Cloud

If public cloud, private cloud, or hybrid cloud, which cloud provider do you use?

Amazon Web Services (AWS)
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
IT Security Manager at a insurance company with 5,001-10,000 employees
Real User
Its data helps us with fixing/understanding an issue more quickly
Pros and Cons
  • "The key feature for Nexus Lifecycle is the proprietary data they have on vulnerabilities. The way that they combine all the different sources and also their own research into one concise article that clearly explains what the problem is. Most of the time, and even if you do notice that you have a problem, the public information available is pretty weak. So, if we want to assess if a problem applies to our product, it's really hard. We need to invest a lot of time digging into the problem. This work is basically done by Sonatype for us. The data that it delivers helps us with fixing or understanding the issue a lot quicker than without it."
  • "The GUI is simple, so it's easy to use. It started as great to use, but for larger scale companies, it also comes with some limitations. This is why we tried to move to more of an API approach. So, the GUI could use some improvements potentially."

What is our primary use case?

At the moment, we are primarily targeting security vulnerabilities, and only those with high severity. 

We have it configured not to block anything at this stage. We only aim for visibility at the moment. We might eventually start blocking or failing builds, but right now, we only want to have visibility.

We are still pretty early in our adoption phase. We are onboarding new applications much quicker than we are remediating issues in the existing ones.

How has it helped my organization?

For the application onboarding, we are focusing on automating that as much as possible. Considering the amount of applications that we scan, it's probably not feasible to do all that within the GUI, but the APIs provided by the solution are really good. We have some positive impressions for that. The automatic onboarding seems to work quite well.

One thing we recently did is we automatically onboarded every application that we deployed to production. We scanned each one of them and now have a complete picture of our estates. Every single vulnerability introduced from an open source component is now visible, and we have a clear number. That number was big. Really, we have a lot of issues which we were unaware of. We suspected that we had them, but we now have a clear number that makes selling the solution internally a lot easier.

The solution brought open source intelligence and policy enforcement to a small extent across our SDLC (software development lifecycle) because we have only fully rolled it out in a small number of teams. However, where we did do this, we have started scanning right at the built face, seeing issues really early in the lifecycle.

The solution automates open source governance and minimizes risk. We are trying to reduce the amount of vulnerabilities that we introduce using open source codes. The entire goal of why we're doing this solution is to have it in the lifecycle of our software development and reduce risk.

What is most valuable?

The key feature for Nexus Lifecycle is the proprietary data they have on vulnerabilities. The way that they combine all the different sources and also their own research into one concise article that clearly explains what the problem is. Most of the time, and even if you do notice that you have a problem, the public information available is pretty weak. So, if we want to assess if a problem applies to our product, it's really hard. We need to invest a lot of time digging into the problem. This work is basically done by Sonatype for us. The data that it delivers helps us with fixing or understanding the issue a lot quicker than without it.

The solution integrates well with our existing DevOps tools. We have a few different ways of integrating it. The primary point is the Jenkins plugin to integrate it into the pipeline, but we also use the API to feed applications from our self-developed systems. So, the Sonatype API is very valuable to us as well. We've also experimented with IDE plugins and some other features that all look very promising.

What needs improvement?

The GUI is simple, so it's easy to use. It started as great to use, but for larger scale companies, it also comes with some limitations. This is why we tried to move to more of an API approach. So, the GUI could use some improvements potentially.

Something else that's a bit lacking is most of our components are not explicitly included but are transitive dependencies. We have 50 applications that all report security issues, but they all come from one central library that we built ourselves, which is also scanned by Lifecycle. So, we have 51 components, and we are not seeing that only one of them is really the one we should be targeting. What would be really great in the solution would be some dependency graphing, or at least collecting the transitive dependencies. That would help for larger scale implementations.

The Success Metrics report is really focused on very specific numbers that are not interesting to us. They are for when you are much further along in the onboarding process. There is an API which allows you to retrieve the data on which the Success Metrics are based. We use this API to create our own charts, reflecting what we're looking for.

For how long have I used the solution?

My company started its POC about two years ago. 

I only started at the company in September last year, so my experience only accounts for the last four months.

What do I think about the stability of the solution?

I think we have had zero downtime since I have been here. I didn't hear that there ever was an issue before, so it's been absolutely great.

Part of the deployment and maintenance is done by me. Upgrading the solution to a new level has only been done by one single person in the past, who spent three to four hours per upgrade on it. It's really low maintenance for us.

What do I think about the scalability of the solution?

We have had absolutely no issues with scalability. We built it for a small PoC. We have now scaled it to scan our entire application landscape on the exact same hardware that it was sized on at the beginning and we have had zero issues. So, it's absolutely great.

The solution is only very limited in its current usage. Our current adoption rate is 10 percent. We plan to hopefully introduce it into every application that we build in a language that is supported by Nexus.

At the moment, we have 20 licensed users. These are primarily IT security managers (such as myself), developers, and product owners.

How are customer service and technical support?

This technical support is very good and extremely quick. I have had two or three support cases and none of them took longer than a day to get a response. Sometimes, they respond, "No, the solution cannot do that. We have built it in that way and you need to raise a product improvement requests." So, it's not always what you hope to receive, but at least the answer is always clear and quick.

Most of the time, the data quality is very good. We have had some cases where there were some weird results or errors in it. But, when I contacted support, most of the time they managed to fix it or explain why it wasn't displayed in the way I was expecting.

How was the initial setup?

The central IT service organization in our firm manages all our Linux setups and stuff like that. He primarily repackages the installer into an RPM for our Linux service. Usually, the upgrade is just totally painless and right off the books.

What was our ROI?

ROI on a security product is always hard to argue because you never know how expensive a security issue could become.

What's my experience with pricing, setup cost, and licensing?

The price is good. We certainly get a lot more in return. However, it's also hard to get the funds to roll out such a product for the entire firm. Therefore, pricing has been a limiting factor for us. However, it's a fair price, and I'm confident that we can sell this story appropriately.

Which other solutions did I evaluate?

I think OWASP Dependency-Check was evaluated before Nexus Lifecycle.

Nexus Lifecycle was chosen primarily for the quality of its scan results.

What other advice do I have?

Look into the API early. Try to scan as much as possible to get an impression of your landscape before you start rolling it out, then you can easily target the teams and applications mostly needed.

The solution makes it easier for us to deploy secure applications. On the other hand, it also introduces a new something that developers didn't really care about before. In some cases, it increases time to market, but for very good reasons. We produce more quality products.

If you consider that developers would test their own research in the past, then their productivity should increase. Unfortunately, most of the time, the hygiene of open source components is a new topic. This is basically new work that we are introducing, so it's hard to compare it to something that wasn't properly done before.

I would rate the solution as an eight (out of 10).

We haven't used the grandfathering feature.

Which deployment model are you using for this solution?

On-premises
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Configuration Manager at a wellness & fitness company with 1-10 employees
Real User
Interactive view provides recommendations on particular versions or licenses needed
Pros and Cons
  • "The grandfathering mode allows us to add legacy applications which we know we're not going to change or refactor for some time. New developments can be scanned separately and we can obviously resolve those vulnerabilities where there are new applications developed. The grandfathering is a good way to separate what can be factored now, versus long-term technical debt."
  • "If they had a more comprehensive online tutorial base, both for admin and developers, that would help. It would be good if they actually ran through some scenarios, regarding what happens if I do pick up a vulnerability. How do I fork out into the various decisions? If the vulnerability is not of a severe nature, can I just go ahead with it until it becomes severe? This is important because, obviously, business demands certain deliverables to be ready at a certain time."

What is our primary use case?

Our primary use case is preventing major security vulnerabilities.

We use it as part of build our pipeline. We have a plugin that gets scanned by Sonatype as the build runs and it scans for all third-party dependencies. We haven't yet gotten to the point where we fail a build, but we make the matrix visible so we know where we need to focus. In the coming months, we plan to actually start failing builds and preventing releases which have certain vulnerabilities, from going into production.

How has it helped my organization?

One of the ways it has improved the way our organization functions is that it has created awareness of unlicensed, third-party dependencies and insecure vulnerabilities. That's what it has done at the moment. It's going to have a bigger impact when we start enforcing it on the build pipeline. Then they will be at a point whereby they have to conform to the policy.

There are a number of open-source components that it has highlighted. It means that we have to find a replacement for them. There's a recommendation that's given when it highlights them. So we can remain in the same open-source components, it's just that there has been a patch or an update to them to close off vulnerabilities.

In the context of remediation costs, there is the issue of reputation if you are not releasing secure apps to market. That's one major problem. Secondly, if you know you're releasing insecure applications, you're incurring technical debt because you're going to have to, at some point, mitigate those security vulnerabilities.

It's become a mandatory control now. We just went through a process of defining all the DevOps controls, and one of those controls is to use Nexus IQ. They can't skip that part of their build pipeline. Every code has to be scanned.

What is most valuable?

There are a number of features that we find valuable. The basic functionality of Sonatype is its scanning feature. Out of that, you get the reporting capability as part of your build and it gives you the statistics as part of the build report.

There's also a feature whereby, in your IDE, you can get immediate feedback as you're developing. That's also quite a handy feature.

In addition, in our Nexus repository - we have Nexus OSS and Nexus Lifecycle linked together - all our third-party dependencies are scanned.

The policy management is quite federated, in a sense, whereby we can assign a policy specific to an application.

The grandfathering mode allows us to add legacy applications which we know we're not going to change or refactor for some time. New developments can be scanned separately and we can obviously resolve those vulnerabilities where there are new applications developed. The grandfathering is a good way to separate what can be factored now, versus long-term technical debt. In most cases, these legacy applications are simply retired, so to refactor them wouldn't make sense. Most of them go through a rewrite cycle or are replaced by something we have purchased.

There's a very interactive view where there's a recommendation, as part of the reporting. You can click on a certain vulnerability and it will give you a recommendation. For example, if you're using something that's not licensed or has a certain license type, it will recommend to you, "You should go onto this license," or, "Go to this version, which covers this vulnerability." There are actual recommendations that are synchronized with the database in the States.

The solution integrates well with our existing DevOps tools. We're using Atlassian and using Bamboo as part of that Atlassian set. Bamboo is our continuous integration tool. There's an out-of-the-box Nexus IQ plugin for Bamboo. It's really simple to configure and it gives you results as you're building. Also, the API is very rich, meaning that we don't necessarily have to get a report from the front end. We can build custom reports through the API.

What needs improvement?

They have recently released some online training documentation, because we had to a lot of our own learning. If they had a more comprehensive online tutorial base, both for admin and developers, that would help. It would be good if they actually ran through some scenarios, regarding what happens if I do pick up a vulnerability. How do I fork out into the various decisions? If the vulnerability is not of a severe nature, can I just go ahead with it until it becomes severe? This is important because, obviously, business demands certain deliverables to be ready at a certain time. So, some online tutorials around the administration, around developers, on how to use the tool effectively, would be a good idea.

Where we have extended is that we're using third-party Docker containers. So, we're not just using third-party libraries, but we also have third-party-type Docker containers, or containers from Docker Hub, for example. Somebody else has built the Docker image and we're using the Docker image. Scanning of security and vulnerabilities on that image, specifically, would be useful. It would be good, as we're building an image, or as we're running an image, if we could decompile that image and scan it, to look for any vulnerabilities or any areas where there's been a violation of licensing. For example, we could download a WebLogic container, which could be an infringement of licensing. It's things like that which our developers need to be mindful of. They could simply download any container from Docker Hub, without being aware of the licensing violations or the security vulnerabilities.

For how long have I used the solution?

We've been using it for about two years.

What do I think about the stability of the solution?

The stability is very good. It's extremely stable. We haven't had an instance where it's running out of memory or anything else.

What do I think about the scalability of the solution?

We haven't had an instance where we have run into such high volume that we needed to scale. The only change we made was to increase memory, because we started utilizing the API. In terms of redundancy, all the data is sitting in the database. We have backed up the folder structure, and the worst case is we just restore that folder structure onto any server. You could run it in Docker if you wanted to, as well so that is immutable. It's been made to be a lift-and-shift type of product.

We have 100 users actively using it at the moment. They are developers, mostly.

How are customer service and technical support?

We haven't had an instance where we needed to call tech support. There haven't been issues to the extent that we needed to get hold of tech support. Most of it we deal with in-house. The last issue was probably a year ago, where we ran out of memory and that was a simple config change.

Which solution did I use previously and why did I switch?

We did not have a previous solution. We brought on Nexus Lifecycle because there has been a heightened, more aggressive stance on security.

How was the initial setup?

The initial setup is pretty straightforward, both the installation and upgrades. We're running it on a Linux environment, so there's not much that we needed to do there. 

Policy management is probably where it gets a bit complex. That's where I referred to the need for some tutorials, some more comprehensive documentation.

The initial deployment took less than an hour. It's very quick. Download it and run the .jar and you're good to go. We do use an Oracle Database, so we did need to set up the database. We just pointed it to one of our Oracle instances.

The implementation strategy was to start enforcing the policies and, eventually, to prevent things. We are implementing it in such a way that the developers will, at the point of development, in their IDE, be faced with these warnings that they are using insecure, third-party dependencies and where they are violating the licenses. That's the strategy, whereby we simply block such releases from getting into production. That's where we aim to get.

For deployment you literally just need one person. For maintenance, we have just two people, and that's for an entire pipeline. They're automation specialists so they provide automation solutions. They also act as application administrators.

What was our ROI?

We haven't seen ROI as yet, simply because we haven't been harnessing the full potential of the tool. The way I think we will potentially see a return on investment is if we are using any licenses that could be costing us indirectly. We could be looking at certain technical debt which we could be dropping. Those are the aspects we could look at, but we haven't yet maximized the true, full capability.

What's my experience with pricing, setup cost, and licensing?

Our licensing is bundled. We pay a single licensing cost for both Nexus OSS and Nexus Lifecycle together. So I'm not sure what the individual costs would be. We bought both Nexus Repo - we're using Nexus 2.0 and Nexus 3.0 - and Nexus Lifecycle.

Which other solutions did I evaluate?

There's SonarQube which does static code analysis, but not at the level that Nexus IQ offers it. There is Artifactory, which does do Docker scanning now.

One thing that Nexus IQ has been able to do is to be almost proactive in its integration. You can be in your IDE, you can be in the build pipeline, you can be in the Nexus Repository, and you can get a view of the vulnerabilities. Also you can get recommendations, so you don't necessarily have to waste time in searching the web for a patching solution or an update to fix the vulnerability. It actually gives you recommendations about what you can do to mitigate the problem. That's a distinguishing feature from the other toolsets.

What other advice do I have?

Have a key, a defined goal because, as much as the tool is there, it isn't able to create a goal. The goal is, "We would like to improve the security of our codebase by at least X percent, ensure that 90 percent of our applications, for example, going to market are secure applications." With that goal in place, I would look at purchasing the tool because it would be an immediate implementation of that strategy. We bought the tool with that idea in mind, but nothing clearly defined on a granular policy level. But that's ultimately what makes the difference, to say we are focusing on looking at these types of either licensing or dependencies. The tool is then just automating that process or enabling us to do that. It's taken us about two-and-a-half years to implement a strategy. Whereas, if we had the strategy initially in place, it would have gone much faster.

The governance is centered around security and licensing. Those are the core governance factors around the policy. From a dev SecOps perspective, it's fundamental for governing your third-party dependencies. That's where the enforcement comes in. Once you've defined the policy, it becomes the law, and you can enforce that law. If you are working in a SecOps-type environment then you would sign off on that policy to enforce that.

We haven't used the Success Metrics to its full potential. We understand it revolves around targets that need to be set and how far you are from those success targets, but we haven't used that as yet.

I wouldn't look at it as a root-cause analysis or a monitoring tool. Yes, it does scan for security vulnerabilities and where we've violated licensing, but it's not used as an Elasticsearch, a Splunk-type, or Dynatrace-type of tool. When it comes to troubleshooting and root cause analysis, will we use our Dynatrace and our Elasticsearch to look at the logs.

A lot of the third-party dependencies are open-source dependencies. A lot of them are provided through Apache, etc. We always look at enterprise solutions because of the nature of our business, but where the is an open-source piece of software which we can utilize as part of our enterprise solution then we do. We haven't scoped Nexus IQ to focus on open-source software. Nexus IQ in and of itself is commercial. If we had to use Jenkins or any of the open-source build tools, it would easily integrate with those open-source tools.

Using Nexus Lifecycle, it might end up taking longer to release to market because you may need to refactor. In an industry where these applications have already been developed and now you end up scanning them and you pick up all these issues, you are going to have to refactor them. That means that either new requests must go into a backlog or you fix technical debt, which is what Nexus IQ is going to tell you to do. It might have an adverse impact at first, but the goal is to get to a point where you break even. 

Now we are at a point whereby our apps are being released into production as secure applications. There is the opportunity with new applications, from the onset, to ensure that they are released as secure apps into the market. That doesn't mean that they might be released faster because that could depend on a number of factors. It could depend on your testing cycle, it could depend on your release process, etc.

We haven't had a one-on-one sit-down, or a survey done to really gauge the type of developer engagement. Our level of adoption has been a little inconsistent. Right now, they're getting the visibility of these metrics, but they don't actually have to do anything about it. But once we enforce the policy that their builds and releases will fail, then they will be forced to do something about it. From a SecOps perspective, it enables them to put that application on a risk register and say, "Listen, we need business to focus on fixing this application, making sure it's secure." That's the direction we are currently headed in. Developer productivity could be based on how automated our pipeline is. We are there. We just have to focus on dev and nothing else. This might actually give them that awareness.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Sebastian Lawrence - PeerSpot reviewer
Solutions Delivery Lead at a financial services firm with 201-500 employees
Real User
Improved the time it takes us to release secure apps to market by saving us weeks of rework
Pros and Cons
  • "The dashboard is usable and gives us clear visibility into what is happening. It also has a very cool feature, which allows us to see the clean version available to be downloaded. Therefore, it is very easy to go and trace which version of the component does not have any issues. The dashboard can be practical, as well. It can wave a particular version of a Java file or component. It can even grandfather certain components, because in a real world scenarios we cannot always take the time to go and update something because it's not backward compatible. Having these features make it a lot easier to use and more practical. It allows us to apply the security, without having an all or nothing approach."
  • "We use Griddle a lot for integrating into our local builds with the IDE, which is another built system. There is not a lot of support for it nor published modules that can be readily used. So, we had to create our own. No Griddle plugins have been released."

What is our primary use case?

Our primary use case is for the SAS testing. This is the dynamic composition analysis that we need to do. In our apps, we do a lot of bespoke development and use a lot of third-party components. Therefore, it is critical to know what number is embedded within the third-party components that we may not directly be responsible for. The main use case is for scanning and ensuring that the deployments that we are adding to our servers is as secure as we can make it.

We use it for scanning alone. That is our way of mitigating risk.

We just upgraded to the latest version.

How has it helped my organization?

We have increased the digital footprint of our company over the last few, extensively. We have extensive open source development happening which depend on open source components. Using the scanning with Nexus IQ, a lower count of false positives has helped us roll out our security policies across the development cycle and ensure that our deployments to production are as secure as possible. This helps us avoid critical vulnerabilities being exposed onsite. It saves us time in any remediation activities that we may had after deployment, because if we had discovered security issues after the application was completely developed and deployed, it would be more difficult to go back and make changes or put it back into a cycle. Then, we would have to shift to multiple outcomes due to business expectations, member expectations, and our client expectations. Bringing it back into the development cycle would take a lot of time. Attaching it to the development cycle and by integrating Nexus IQ into our plans, we have a policy that will not allow vulnerable artifacts to be deployed to production. This forces it to be handled during the development cycle.

The solution has increased developer productivity when remediating issues, as the issues are clearly laid out. We are saving five to 10 percent in developer productivity. 

This solution integrates well with our existing DevOps tools. We use it in our Jenkins build pipeline. If the Nexus IQ scan fails, then it produces an error that fails the build. When a developer builds on their machine, as well, it flags issues and lets them know which component has a problem.

This solution brought open source intelligence and policy enforcement across our SDLC (software development lifecycle). The enforcement is simply because the build pipelines use Nexus IQ, then it fails when Nexus IQ has an error and identifies a component with multiple security issues because it breaks the release pipeline. The enforcement is there because you can't release anything without going through that pipeline.

What is most valuable?

The scanning is fantastic. 

The dashboard is usable and gives us clear visibility into what is happening. It also has a very cool feature, which allows us to see the clean version available to be downloaded. Therefore, it is very easy to go and trace which version of the component does not have any issues. The dashboard can be practical, as well. It can wave a particular version of a Java file or component. It can even grandfather certain components, because in a real world scenarios we cannot always take the time to go and update something because it's not backward compatible. Having these features make it a lot easier to use and more practical. It allows us to apply the security, without having an all or nothing approach.

The application's onboarding and policy grandfathering features are very easy to use. Most developers who I have given access have picked it up easily. The documentation is fantastic. I've never had a reason to contact support or asked a question, as most of the answers are available.

It provides all up-to-date data information on the vulnerable issues for the various components that are available. I am able to see that various versions of the application are clear. Sometimes, there is a direct reference , so we can see what the issue is and what are the workarounds, if any, that there are available. It will even suggest certain steps which could be taken to remediate the issue. This helps streamline all the information available instead of us going to multiple sources and having to correlate information. Everything is easily available in a streamline manner. It is easy to access, review, make decisions, and proceed with fixes.

What needs improvement?

We use Griddle a lot for integrating into our local builds with the IDE, which is another built system. There is not a lot of support for it nor published modules that can be readily used. So, we had to create our own. No Griddle plugins have been released.

One of the challenges is getting the policy correct. You need to understand when to grandfather components, then come back and do it. Currently, there's no feature in Nexus IQ which says when you grandfather a component, or behave a component. There's no feature to remind me again in two months' time, for example. I had to access a grandfather competent today because I couldn't afford to fix it because of different constraints. I might grandfather it for now, or I might leave it for now, but if there was an option to remind me in two months, or unwaive it in two months' time, that would make it seamless. That way I wouldn't have to remember that there's something to be done. It would automatically start breaking bills and automatically someone will look at it.

For how long have I used the solution?

We've had Nexus IQ since 2017.

What do I think about the stability of the solution?

I haven't had any issues with it crashing. It is very stable. However, when we use it in real-time builds (or very frequent builds), there is sometimes a bit of lag between getting results back by 10 to 30 seconds. Other than that, we haven't had any issues.

What do I think about the scalability of the solution?

We haven't scaled it because we just had this one server running. We have not had a reason to scale it as of yet.

We have 10 people who can use it, and they are developers in DevOps.

We started off using Nexus IQ very sporadically on an ad hoc basis. Now, we have moved into putting it into some of our pipelines, especially for applications that are in the forefront, e.g., digital footprint applications. There is now a high interest to make this mandatory for all data points. We are definitely looking at an increasing usage.

How are customer service and technical support?

The technical support is fantastic. The few times when we have asked for help, their answers were immediate and to the point. 

Which solution did I use previously and why did I switch?

Nexus was our first implementation.

How was the initial setup?

The setup was very easy. The instructions were very clear and the install was easy. There was almost no need for us to contact support or get anyone to handhold us during the installation and set up. There is more than enough documentation which covers what the policies are and how you implement them, etc. We didn't need a consultant to come in and implement it. We could do it ourselves.

The deployment didn't take very long. The deployment was finished in days because we had prepped the environment. What took longer was including using the tool in different projects.

We started off with ad hoc scanning, then moved toward a more automated scanning. Since there are there are multiple different types of applications and pipelines. We started off using Nexus as a standalone ad hoc service where people could use it just to launch the application, as required. Then, when they started seeing the value, they started embedding it into their pipelines.

What about the implementation team?

One of our developers can install this solution. Anyone from DevOps can install and maintain it. We don't have a delegated person for it.

What was our ROI?

We have seen ROI.

Nexus has improved the time it takes us to release secure apps to market by saving us weeks of rework.

Which other solutions did I evaluate?

We evaluated different Black Duck and WhiteSource, but chose Nexus because we felt it was the best product offered.

In early 2017, Black Duck had an approach of uploading everything all at one time, then coming back later to see the report, which Nexus IQ didn't. Also, with the price points, there were distinct differences between Black Duck and Nexus IQ.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Java Development Manager at a government with 10,001+ employees
Real User
Tells us in what version of a .jar a vulnerability was introduced, when it was fixed, and recommends the version to use
Pros and Cons
  • "The way we can define policies and apply those policies selectively across the different applications is valuable. We can define a separate policy for public-facing applications and a separate policy for the internal applications. That is cool."
  • "Since Nexus Repository just keeps on adding the .jar artifacts whenever there is a build, whenever an application is going up, there is always a space issue on the server. That is one of the things that we are looking for Nexus to notify us about: if it is running out of space."

What is our primary use case?

We use it as a repository or manager. We store all our software application artifacts. We also use it for the vulnerabilities.

How has it helped my organization?

Before, we had open-source Nexus Repository, but with Lifecycle we have Nexus RM and IQ Server as well and we can scan .jars. In addition, we have the plugins for individual developers, which benefits us and the developers when they introduce a new artifact into their applications. It helps them identify what are potential risks and defects. They can resolve them right there and proceed there with their development.

It also brings intelligence to the open-source artifacts, because intelligent servers scan all the vulnerabilities, identify the problems, and then we can ask the individual teams to fix them. That is a plus.

The solution blocks undesirable open-source components from entering our development lifecycle. There are certain .jars which we can block.

In terms of open-source governance, the tool tells us all the threats that are out there in the public sector repositories, threats which, potentially, no one knows. We get to know them and we can use the tool to let other people know which direction to go in.

The solution has improved the time it takes us to release secure apps to market by at least 50 percent. It has also increased developer productivity to some extent because of the plugin which is included for the IDE. It gives a report of the vulnerabilities. It does save time in figuring out the right open-source versions that we need to use. It has helped improve the productivity of the developers by about ten percent.

What is most valuable?

The way we can define policies and apply those policies selectively across the different applications is valuable. We can define a separate policy for public-facing applications and a separate policy for the internal applications. That is cool.

Since we have public-facing applications, they are more vulnerable, because anyone from anywhere can access them: for example, Excel and Java scripting. We can detect if we potentially have any .jar open-source product that can become vulnerable. We can define stricter policies for the public-facing applications, versus internal where we are protected by the firewall. We already have a more secure way of accessing those internal applications, so we can limit the strictness of the internal policies a little bit. We can relax some of the rules there defining the different levels, from a security perspective. That is useful.

In addition, we like the way, when the product has found a vulnerability, that it also recommends the version in which that particular vulnerability was fixed. It generates a report with all the different types of vulnerabilities that were found. We can then go to individual vulnerabilities and look into the historical information: When, and in what version of the .jar, it was introduced, when it was fixed, and what the usage in the market is for that particular open-source component. That is very useful information to us.

The solution's data quality shows in the way that it recommends the correct artifact that we should use and the different versions that are available. Based on that data we can make better decisions.

It also integrates well with the IDEs. Instead of discovering a problem during deployment, we can identify the problem right at the development phase. That is a cool feature of Lifecycle. We use Bamboo for our builds and the Nexus IQ plugin is compatible with Bamboo. We can scan the vulnerabilities at build time.

What needs improvement?

It doesn't provide real-time notifications from the scans. We have to re-scan every time, whenever a build happens.

Also, since Nexus Repository just keeps on adding the .jar artifacts whenever there is a build, whenever an application is going up, there is always a space issue on the server. That is one of the things that we are looking for Nexus to notify us about: if it is running out of space.

For how long have I used the solution?

We have been using the product for more than six months now.

What do I think about the stability of the solution?

It is stable as of now, the version we are using. We hope that it continues to work as we expect.

What do I think about the scalability of the solution?

We haven't actually explored scalability. But in terms of scalability, if there is anything that we need to add, like CPU, memory, or any extra RAM, that can be added dynamically. But we are not sure if Nexus would need downtime for things like that.

How are customer service and technical support?

Technical support has been really prompt.

Which solution did I use previously and why did I switch?

We used the open-source version before moving to the licensed version of Sonatype.

How was the initial setup?

The initial setup was okay. It was pretty straightforward. We had some hiccups in the migration itself when we migrated from open-source to licensed Nexus. At that time we faced some issues with the configuration and we had that resolved. But the deployment took only an hour.

Because we had an existing, open-source Nexus RM, we had to migrate it to the new, licensed Nexus Pro version. So we had to coordinate with other teams, come up with a plan, and then execute accordingly.

What was our ROI?

We have only been using the licensed version for six months. But long-term, we definitely see it saving time and that will be our long-term return on investment.

What's my experience with pricing, setup cost, and licensing?

Pricing is comparable with some of the other products. We are happy with the pricing.

Which other solutions did I evaluate?

We didn't look at any other options. We have been using Nexus for years. We had some initial sessions with them, we did a PoC and we liked the product. We went ahead with it.

What other advice do I have?

Their support is good. They help with understanding the environment. They helped us with the initial PoC work. Their product is configurable. We can customize the policies. We had some hiccups, but it was pretty self-explanatory once we understood all the different parts. It was easy to set up and get going. From an implementation perspective, it's not a complex setup, which is a good thing.

We have ten people using the solution, which includes developers, some of our managers, and architects. For deployment and maintenance of Nexus, we need just one person, a developer.

We have pretty much scanned all of our applications. We have around 30-plus Java applications. Based on the current set of applications and the number of users who are using this product, there are no plans to increase usage at this time. 

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Gus Orologas - PeerSpot reviewer
Lead IT Security Architect at a transportation company with 10,001+ employees
Real User
Scans code libraries, flags vulnerable versions, and shows if a newer version is available
Pros and Cons
  • "The application onboarding and policy grandfathering features are good and the solution integrates well with our existing DevOps tools."
  • "The biggest thing is getting it put uniformly across all the different teams. It's more of a process issue. The process needs to be thought out about how it's going to be used, what kind of training there will be, how it's going to be socialized, and how it's going to be rolled out and controlled, enterprise-wide. That's probably more of a challenge than the technology itself."

What is our primary use case?

We're using it for looking at code libraries, for its automatic build process for cloud. We want to look at code libraries that have security, to make sure that there are no vulnerabilities in the code libraries that people are uploading, and we want to do that early in the process so it's not being caught at the tail end.

We use it to automate open source governance and minimize risk.

What is most valuable?

  • The application onboarding and policy grandfathering features are good.
  • The solution integrates well with our existing DevOps tools.
  • It also blocks undesirable open-source components from entering our development lifecycle. It scans code libraries and it flags them if there's a vulnerable version. It shows us very quickly if there is a newer version available, and what generation that non-vulnerable version is.

What needs improvement?

Getting it integrated depends on your structure and how your DevOps teams are structured. The biggest thing is getting it used uniformly across all the different teams. It's more of a process issue. The process needs to be thought out about how it's going to be used, what kind of training there will be, and how it's going to be socialized, how it's going to be rolled out and controlled, enterprise-wide. That's probably more of a challenge than the technology itself. It's pretty simple to get up and running. It's not really an enterprise solution, like Active Directory, which you can enforce on everyone. It's something that's done through each little vertical.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

It looks pretty stable to me.

What do I think about the scalability of the solution?

I don't know how well it's going to scale.

Which solution did I use previously and why did I switch?

We did not have a previous solution. We had nothing.

How was the initial setup?

The setup was straightforward, it was easy to install. On the pilots, it didn't take it long to get it up and running. We only did limited portions. For a pilot, the setup only took a couple of days.

What about the implementation team?

It was pretty much all done internally.

What other advice do I have?

We have one person assigned to this solution for maintenance. It's not being used extensively, and there's no plan to increase it, even though there's a desire to increase use of it. In other words, everyone wants to deploy this, but no one has figured out how they're going to do that enterprise-wide. It's a process problem, not a technology problem.

Overall, I give it a nine out of ten. It has a very intuitive interface and clearly displays the problems and the solution.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
EdwinKwan - PeerSpot reviewer
Security Team Lead at Tyro Payments Limited
Real User
Low false-positive count and the vulnerability-upgrade overview are key features for us
Pros and Cons
  • "It scans and gives you a low false-positive count... The reason we picked Lifecycle over the other products is, while the other products were flagging stuff too, they were flagging things that were incorrect. Nexus has low false-positive results, which give us a high confidence factor."
  • "What's really nice about that is it shows a graph of all the versions for that particular component, and it marks out the ones that have a vulnerability and the ones that don't have a vulnerability."
  • "We created the Wiki page for each team showing an overview of their outstanding security issues because the Lifecycle reporting interface isn't as intuitive. It is good for people on my team who use it quite often. But for a tech engineer who doesn't interact with it regularly, it's quite confusing."
  • "Another feature they could use is more languages. Sonatype has been mainly a Java shop because they look after Maven Central... But we've slowly been branching out to different languages. They don't cover all of them, and those that they do cover are not as in-depth as we would like them to be."

What is our primary use case?

It's mainly used to scan for security issues in any components that we use. There are two parts to it, the license part and the security part. We use it generally for the security, but we also do have scans for the license stuff too.

How has it helped my organization?

One of the ways that it has helped us is that it has given us visibility into security issues. It has made us a bit more proactive in dealing with things. Before, we depended on how much news there was about a particular issue in a component, just learn about it. And when we learned about it, we didn't know which applications we had that were affected by it. Lifecycle helps really well with that. 

We put it into our pipeline. Whenever a developer builds, he can choose to do a scan - we don't enforce it. But what we do enforce is that when a developer makes a change in the repository, which means pushing it into production, as part of the build pipeline we scan it to make sure they are not introducing anything new in there. That has been a really good feature to make sure we've got that base level of hygiene.

It also has something called continuous scan. We run that every night and scan our build materials - all the components that we know we are using, based on the previous scans. We re-scan them to see if any of them have any new vulnerabilities that have been detected. That is really beneficial because in our company we're always building new applications, and some of them are more actively developed than others. What we found was that we had a lot of vulnerabilities in applications that weren't being actively developed, things that needed to be fixed. If it weren't for Lifecycle, they would have just fallen off our radar.

It has brought open-source intelligence and policy enforcement across our SDLC. We have two kinds of build pipelines. They are centrally managed by a team which handles all the build infrastructure. We integrated it so they have to do those scans. The policy enforcement will break a build, so you can't move forward without addressing it. The solution blocks undesirable open-source components from entering our development lifecycle, based on the policies that we set. It will break the build straight away. There's no way you can ship code that introduces new vulnerabilities. We just don't allow it at all.

It has improved our security but, in terms of developer productivity, if you asked the developers about fixing security issues, I don't know if they would consider that productive for them. But from my point of view, it has improved developer productivity.

What is most valuable?

There are two things that allow us to do what we want to and that's why we chose Nexus Lifecycle. 

First, it scans and gives you a low false-positive count. When we were looking for a product to solve this need, we looked at different products, Nexus Lifecycle being one of them. The reason we picked Lifecycle over the other products is, while the other products were flagging stuff too, they were flagging things that were incorrect. Nexus has low false-positive results, which give us a high confidence factor, which is something we like about it.

The other thing that we thought that was really good about it was that it gives an overview. We find something that has a vulnerability and say, "Hey, what can I upgrade to?" What's really nice about that is it shows us a graph of all the versions for that particular component, and it marks out the ones that have a vulnerability and the ones that don't have a vulnerability. It also shows the popularity, so we can look at it and say, "Alright, from where we are, what is the next version that we can move to that is not vulnerable and that is quite popular?" If it's popular, we tend to prefer it because then more people are looking into it, and it gets a bit more scrutiny.

What needs improvement?

We created a Wiki page for each team showing an overview of their outstanding security issues because the Lifecycle reporting interface isn't as intuitive. It is good for people on my team who use it quite often. But for a tech engineer who doesn't interact with it regularly, it's quite confusing. We did that because we got so many questions about it all the time.

There are other areas for improvement. 

The most recent one - something I haven't shared with Sonatype yet but I intend to - is with the creating of defect tickets. The solution has something that is really useful, its integration with JIRA, and it creates tickets if there's an issue. What I thought would be really good was, from the moment we break builds, there is no way to track, from a management perspective, how we are doing. We are looking at creating tickets. The problem with the tickets, which is the where there is room for Sonatype to grow, is that there is no flexibility in terms of customizing the entries in the tickets. There are certain things they put in for you, they tell you what application it is, but what I'd really like to be able to do is say, "Fill in this field with the name of the application. Fill in this field with the name of the owner. Or set a due date to be X days from when it was raised. They don't allow that. They allow hard-coded values across everything in Nexus IQ. It doesn't work well because the tickets created depend on the use case. We would like to create these tickets and give them directly to the teams that have to look after them. We want to be able to assign them to the right person, based on the application that is used. " We are looking at finding ways to integrate with it because they don't have that.

Another feature they could use is more languages. Sonatype has been mainly a Java shop because they look after Maven Central. And we have been mainly a Java shop in development. But we've slowly been branching out to different languages. They don't cover all of them, and those that they do cover are not as in-depth as we would like them to be. They don't have the same level of coverage as the main language, which is Java.

For how long have I used the solution?

Three to five years.

What do I think about the stability of the solution?

The stability has been pretty good. We're pretty happy with it. There have been no issues there.

What do I think about the scalability of the solution?

Scalability is not an issue. We have a microservices architecture and we've got about 150 applications in there and we scan them quite regularly. When we first started, we had a lot fewer applications, we were sending about five gigs of scanning data requests to the Sonatype servers every day. They were able to handle that. We had issues before, but I think they were more networking configuration issues, and they could have been on our side. But that has all been resolved and there are no issues.

How are customer service and technical support?

Their technical support has been pretty good. They're based in the US and the turnaround time tends to be overnight. We generally send out requests in the afternoon and we normally hear back from them when we come into the office the next day.

The depth of the responses vary, although it's generally pretty good. Sometimes they just don't have enough information, and that could be that from our side, that we have not provided enough information, enough context. But generally, it's been alright.

How was the initial setup?

We had a few issues initially when we set it up. We had a problem with not having enough space because it would keep the reports indefinitely. We were running out of disk space. But I know they've addressed that now because, in one of the updates that we did last year, the disk space was reduced considerably. They've been telling me that they were actively looking into it.

The initial deployment took a few days. Most of the challenges that we had for the deployment were mainly to do with the rollout of our policies. Imagine an application that never had any scans, and we wanted to get to this SLA model, where you shall not introduce any more vulnerabilities and you need to fix existing issues. What took so long was we had to turn on the policies slowly and we had to grandfather everyone. Otherwise, everyone would just stop working straight away. When we first turned it on we discovered so many vulnerabilities in there that we never knew existed before.

The implementation strategy was not to have the SLA initially - how long you had to get something fixed. We turned the solution on and said you can not introduce any more new components that have vulnerabilities. We drew a line in the sand and said, "That's it." Then, we created a list of all the things that we knew were a problem - that was a very manual process. We started from the top saying, "What are the critical ones that we will work on with teams to try and address them?"

Some of the fixes were not trivial, they were quite a big change. One of the reasons was because, being an old application, it was using really old versions and the fix required a newer version. But the jump from where you were to where you needed to be was quite a big jump. That resulted in quite a lot of backward incompatibility with the other components in the system. That was what took a lot of time. We worked our way down. It took us a good year-and-a-half to get to where we wanted to be because we were competing with product engineering time to either work with features or fix security. We needed to find the right balance.

For deploying it there were two people from my team to set it up and get it all going. And to address the issues it was a combined effort within the whole company. In terms of maintenance, now that it's configured, we have one person a week who is on the support roster to address any issues that we have. The maintenance is more to field questions the engineering team might have. They may say, "Hey, I just got this report that this application has an issue. Can I have more information about it?" Maintenance isn't about maintaining the system, it is more about providing consultation to teams and advising them on how to fix those issues that have been discovered.

What was our ROI?

The area where we've seen ROI is security hygiene. We're using a lot fewer vulnerable libraries. What we have seen is that when there is news about something that is vulnerable, and that there is a tool that someone has created that allows you to exploit it, we normally already know about it and we've addressed it. There's peace of mind knowing that we're on top of it.

What's my experience with pricing, setup cost, and licensing?

We're pretty happy with the price, for what it is delivering for us and the value we're getting from it.

Which other solutions did I evaluate?

We did a PoC with a few companies and we picked Sonatype and we've been happy with them since.

We looked at Black Duck, and we also look at the free version, the OWASP, a dependency checker. We also looked at Veracode. The difference between Sonatype and the competitors is the accuracy. But having said that, I'm not too sure how Lifecycle compares to Black Duck. I know Black Duck is pretty good too. The main difference between Lifecycle and Black Duck for us was the price point.

What other advice do I have?

My advice is that you should definitely use it. You need to think about the rollout and to make sure you integrate it into the software development lifecycle. That's where you get the most value because it provides quick feedback for developers. Be mindful of the rollout and breaking the builds. I don't think other companies that we spoke chose to break builds, but we do that and that is a sensitive topic for developers if you choose to do that.

We don't use the application onboarding and policy grandfathering features at all. I suggested that to them, but the main reason we don't use them is, while we had that problem when we started out, we don't have the problem anymore.

We don't use the Success Metrics feature as much. When it first came out I was quite excited about it, I thought it would be quite useful. But it hasn't really been as useful as I would have liked it to be. I was going to use it for figuring out trends. I was hoping to figure out how are we are tracking the number of vulnerabilities being discovered, and the trend, over time in terms of: Are we actively addressing them? I was hoping to break that down to engineering departments so could create a report and say, "Hey, this particular department has been really good, they're actively fixing vulnerabilities as they're coming out. This other department could be a lot better." I was hoping to get that, and it kind of had that. To be honest, I haven't looked at it for quite a while. But when I first looked at it, it looked quite good, but I didn't understand quite a bit of the graphs. I ended up using my own data set instead.

We do have metrics on how much faster it helps us to fix issues but that's more because we have a company policy, we have an SLA there. It's based on the severity of the issue. There is a CVSS code. We map that into criticality, so if it's a ten, we say it's a severe security issue. There are ranges: critical, high, medium, low. This is actually mapped out to some standard policies that come with Nexus Lifecycle when you first install, so we just kept that in there because we thought that was best practice. 

But what we did say is that if there is anything that's critical, we want the team that's looking after the application to immediately stop work and address it straight away. If it's a "high," they have one month to address it. If it's a "medium," they've got three months, and if it's a "low," they've got six months. That's how we choose to address it, but that's set by us and it's enforced by Lifecycle. 

We have done something to integrate with it. It's not part of the feature set that it has. We integrated with it such that when we do discover something that's new - nothing that's introduced; rather something that's already in there that was okay yesterday but isn't okay today - we put a policy waiver (which is the term they use in Lifecycle) in place so it doesn't break the build. Once that SLA has expired, it will break the build and teams cannot make any more changes until they address it. That helps us conform to the SLA.

The data quality is generally pretty good. We're pretty happy with it. We have seen a few cases in the last year where there were things that came out, and the teams came to us and said, "Hey, it's saying this, but we investigated further, it's not really an issue." So we've gone back to Sonatype and told them about these things. But, having said that, across the board, we feel that Nexus has been the most accurate so far, compared to all the other ones that we have used.

It integrates fairly well with our existing DevOps tool. We had to do some work to get the metrics that we can show teams. We had to do some work to hand it the SLA stuff that we want our teams to go by. We are trying to do some work now where we want to create a defect ticket automatically. It hasn't been very good at that. It has some basic functionality but not as good as what we want. But generally, I would say it's good. I would also add that I don't think that it's any better or worse than the other products out there. It's doing all right.

The primary integration was to enforce our SLA. The other integration we have done is we created another tool that acts as a proxy. There are applications and applications belong to a team. It allows us to give immediate feedback to the teams. When the teams choose to build it locally and they run this tool, they don't use the Lifecycle tool, they use this tool that we wrote. The reason why we did that was for our SLA, because then the report comes back to the team. It actually shows them how many days remain for those things that are subject to the SLA.

We also did some work to create a Wiki page, one for each team, that we update every day. This is more to give to team leaders, who are not always on the code, an overview of what the outstanding security issues are, in which applications they are found, and how much time they have to fix them.

Regarding the time it takes to release apps, it hasn't changed the amount of time. We would like to move to continuous deployment but, at the moment, some of them are continuous and some are weekly and this has had has no impact on that.

We have about 135 users of the product in our organization. Software engineers are using it, DevOps engineers are using it, we've got some testers using it. We also have some delivery managers using it and they're using it more for the reporting to see how things are going. We also have some operations people using because it can also scan containers.

It has been utilized quite extensively. I don't think it's going to increase any more. It would increase if we had more applications, but we are also using a lot more technologies.

I give it a nine out of ten because of the accuracy. I like the information that it provides in terms of how to address issues. It would have been a ten, but there are other things that require integration, the extra stuff that we had to do, which I wish we didn't have to do, that it was all done for us. But we're probably not using it in a way that they envisioned most people would use it.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Systems Analyst at Thrivent Financial for Lutherans
Real User
Easy to configure and integrate, it has helped us address security and access issues
Pros and Cons
  • "Among its valuable features, it's easy to handle and easy configure, it's user-friendly, and it's easy to map and integrate."
  • "Sometimes we face difficulties with Maven Central... if I'm using the 1.0.0 version, after one or two years, the 1.0.0 version will be gone from Maven Central but our team will still be using that 1.0.0 version to build. When they do builds, it won't build completely because that version is gone from Maven Central. There is a difference in our Sonatype Maven Central."

What is our primary use case?

The solution is mainly providing security, as well as creating threshold values. In terms of dependencies, it helps us with which ones are used and which are not, which need to be kept, which do not need to be kept.

How has it helped my organization?

We have reduced a lot of security access issues. For example, we can restrict user access level for the baseline of our organization's security.

Right now we are using it in Jenkins, it's open-source and it has very good restrictive policies. We are now moving into Bamboo. It has not been completely implemented in production, but we have started on it.

What is most valuable?

  • Easy to handle and easy to configure
  • User-friendly 
  • Easy to map and easy to integrate 
  • Easy to update 
  • Fulfills a lot of security purposes

It has all the features we need.

What needs improvement?

The only thing I can say is that sometimes we face difficulties with Maven Central. We are integrating everything with that, as a repository. If Maven Central changes something in its versions... For example, if I'm using the 1.0.0 version, after one or two years, the 1.0.0 version will be gone from Maven Central but our team will still be using that 1.0.0 version to build. When they do builds, it won't build completely because that version is gone from Maven Central. There is a difference in our Sonatype Maven Central. That is the only issue I have seen so far. If an old version is gone, it's not able to use it anymore. Is there any way we can keep the old versions in our local repository instead of in Maven Central?

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

The stability is great.

What do I think about the scalability of the solution?

I would rate the scalability at eight out of ten.

How are customer service and technical support?

It's easy to solve issues and their support team is very helpful when I need help. They are able to give us solutions just like that, with a quick response. That is the beauty of their team. I like it. I rate technical support at nine out of ten. It's awesome the way they explain things to us, the way they email and send documentation.

Which solution did I use previously and why did I switch?

We are looking back almost five years. We used a lot of IBM products and we used in-house products. With them, we were able to directly copy the dependencies we had in Maven Central to our local repositories.

How was the initial setup?

We always us global setups. We use settings from XML files and we configure all of our repositories at a single, global repository in Nexus. We can just reference that URL and Nexus will report to our second XML file. That way, all the developers can use the same second XML file for extracting the different names or uploading the new Nexus stuff.

The deployment was very quick, it only took two or three minutes.

What's my experience with pricing, setup cost, and licensing?

The licensing is okay. Compared to IBM, Sonatype is good.

What other advice do I have?

There are demo licenses so ask them for one to try the solution. They will get back to you for sure. I would tell others how easy and how good the product is, and how easily they can implement, integrate it, and secure it. I refer this product to most of my colleagues and friends.

We integrated with Nexus IQ. The Sonatype people visited us three or four times. They explained to us how to use it, how Sonatype works, as well as the best features. They explained everything briefly and gave me the best examples and features and comparisons with other companies; how they're using it and how we could improve our organization. I liked that.

We have about 300 developers using it in our organization and they just use our global configuration files. They don't know what is going on in the background, it's completely infrastructure-driven. We used to give them instructions on how to use Nexus and how to check their security levels. Staff for deployment and maintenance includes six people in our team. Two are in the US and four are offshore in India. It's a 24/7 process so we need to cover everything.

We do have plans to increase usage, but that's not my role.

The solution is awesome, the way they have implemented it, the way they help us know what is good. We haven't found any difficulties.

Overall, I give the solution a nine out of ten. It's a very user-friendly product and it is very easy to integrate with any other products. It's more reliable and more securable.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Axel Niering - PeerSpot reviewer
Software Architect Sales Systems at SV Informatik GmbH
Real User
Provides a quick overview of the libraries in our application and their security and licensing issues
Pros and Cons
  • "The most valuable feature is that I get a quick overview of the libraries that are included in the application, and the issues that are connected with them. I can quickly understand which problems there are from a security point of view or from a licensing point of view. It's quick and very exact."
  • "It was very easy to integrate into our build pipeline, with Jenkins and Nexus Repository as the central product."
  • "If there is something which is not in Maven Central, sometimes it is difficult to get the right information because it's not found."
  • "If you look at NPM-based applications, JavaScript, for example, these are only checkable via the build pipeline. You cannot upload the application itself and scan it, as is possible with Java, because a file could change significantly."

What is our primary use case?

Our use case is to check and evaluate third-party libraries for vulnerabilities and licensing problems. We are integrating it into our build pipeline as well.

How has it helped my organization?

We're still using it in a PoC and it's not as integrated as it could be so it hasn't changed too much for us right now. But of course, what we want to do is to keep safe, look at the vulnerabilities that come from third-party libraries. It will change our development process and help us improve the security part, the development process.

In the way we are using it now, we have checked several applications manually and gotten some information about vulnerabilities. And we have been able to fix these vulnerabilities with help of the product.

The solution helps automate open-source governance and minimize risk. For example, a developer decides to use an open-source component, so he is going to add Wire Maven into the application. In this phase, he can already get information about possible vulnerabilities. If he ignores this, we can still absolutely detect such a problem later on and prevent it from being sent to production. This is a process which has several steps, of course. We also want to use the firewall to prevent such libraries from downloading, but this is something we haven't done yet.

It has also improved on the time it takes us to release secure apps to market. It was not possible for us, before, to ensure really secure development. But we are still on our way in that regard. Without a tool like this, you can't really find out which vulnerabilities are present. It's only possible if you use such a tool. Because we didn't have this kind of tool before, I cannot say how much time it has saved. I can only say that now it's possible to develop secure applications.

What is most valuable?

The most valuable feature is that I get a quick overview of the libraries that are included in the application, and the issues that are connected with them. I can quickly understand which problems there are from a security point of view or from a licensing point of view. It's quick and very exact.

The onboarding and policy grandfathering are quite useful, to keep in mind what we have already discussed around parts of the application, and to identify our own parts of the application which are not discovered by Nexus Lifecycle.

The data quality is really very good. We have also checked other products and they do not provide such good quality data. Still, we must look very closely at a single vulnerability from a single issue. We have to understand what problem it's indicating. However, without this tool there would be no way to do this. The data quality is really very good.

It was very easy to integrate into our build pipeline, with Jenkins and Nexus Repository as the central product. It was very easy to integrate the evaluation of the application to be built into the Jenkins process so that we had the ability to check how good the application is thus far. It also helps when you look at the stage we are at in building this application, whether test or production.

What needs improvement?

If there is something which is not in Maven Central, sometimes it is difficult to get the right information because it's not found.

And if you look at NPM-based applications, JavaScript, for example, these are only checkable via the build pipeline. You cannot upload the application itself and scan it, as is possible with Java, because a file could change significantly, so the applications are not found anymore. This is something that could be improved in future.

Also, I have seen in Black Duck, for example, that there is also information about exploits there are known for a given vulnerability. This is something I haven't seen or haven't found yet in Nexus Lifecycle. If there is a known exploit to a vulnerability, this could be something that is useful to know as well.

For how long have I used the solution?

Less than one year.

What do I think about the stability of the solution?

Nexus Lifecycle has had no problems until now. There is just a small circle of people using it directly, so this is not a critical mass of users. I cannot say what the stability will be like when there are more people using it. But right now, there is absolutely no problem. It just works.

The users in our company are developers and software architects.

What do I think about the scalability of the solution?

We are using just one instance right now, I don't know how it scales.

How are customer service and technical support?

We have always had quick responses to questions we had, and they have always been very helpful. The people involved are very smart. They know what to do.

How was the initial setup?

The initial process is straightforward. It took half an hour. We had everything working and then the integration into Jenkins took another half an hour. This was very straightforward. Of course, you must look at the rules and the metrics that are important to you. You must do something regarding the applications you are using and your organizations that are involved. But this is true for every tool.

What was our ROI?

We are still on our PoC, so there has been no investment up until now. We have just decided to invest in Nexus Lifecycle. I am sure that there will be a return on investment very soon.

What's my experience with pricing, setup cost, and licensing?

Its pricing is competitive within the market. It's not very cheap, it's not very expensive.

Which other solutions did I evaluate?

We also evaluated Black Duck. We selected Nexus because of the data quality and the ability to integrate it into our build process.

What other advice do I have?

Look very closely look at Nexus Lifecycle to check whether the system is a possibility in your environment. It has good data quality and good integration in our build environment. Everyone must check for themselves whether it is the right solution for them. But I would always advise to have a close look at Nexus Lifecycle, if there are similar requirements to ours.

The Success Metrics feature is something we have not used too much up until now. It's unused because when we started was it was very basic. However, it is a very good means for seeing how successful we have been in reducing the issues that are connected with applications.

We could improve the quality of the third-party libs we are using, and the SDLC is something we are going to improve as well. In this area, we hope Nexus Lifecycle will help us to do so. It's just a part of what there is to do, but Nexus Lifecycle will be very helpful in this kind of process. We can get the information about vulnerabilities and licensing problems very early, when integrating a library into Eclipse, for example. Further on we can scan applications manually and integrate the evaluation into the build pipeline. These things are important as early as possible, but it's also good to have the last look if there is something we do not want in production.

In terms of blocking undesirable open-source components from entering our development lifecycle, we could configure the solution to do so but we haven't done so yet. This is, of course, something we want to do.

As for the tool increasing developer productivity, I would say yes and no. Now we can better deliver secure applications but, on the other hand, there's more to do. Of course, it was just not done before so it would be comparing apples and oranges.

It is possible that we will extend the tool to other development departments, or even to those who are looking at the licenses. We are using it on-premise, right now, and this is something we would continue. We are integrating it with our Jenkins and Nexus-based build pipeline, which is also here on-premise. This is what we are going to do in the next weeks.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Charles Chani - PeerSpot reviewer
DevSecOps at a financial services firm with 10,001+ employees
Real User
Delivers a huge reduction in development lifecycle duration; automatically blocks insecure open-source libraries
Pros and Cons
  • "When developers are consuming open-source libraries from the internet, it's able to automatically block the ones that are insecure. And it has the ability to make suggestions on the ones they should be using instead."
  • "It's online, which means if a change is made to the Nexus database today, or within the hour, my developers will benefit instantly. The security features are discovered continuously. So if Nexus finds out that a library is no longer safe, they just have to flag it and, automatically, my developers will know."
  • "There is a feature called Continuous Monitoring. As time goes on we'll be able to know whether a platform is still secure or not because of this feature."
  • "They could do with making more plugins for the more common integration engines out there. Right now, it supports automation engine by Jenkins but it doesn't fully support something like TeamCity."
  • "In terms of features, the reports natively come in as PDF or JSON. They should start thinking of another way to filter their reports. The reporting tool used by most enterprises, like Splunk and Elasticsearch, do not work as well with JSON."

What is our primary use case?

We use it to automate DevSecOps.

How has it helped my organization?

Previously, the developers would do their work and then it would be evaluated using something called penetration testing. With the results of the penetration testing they would go back and make changes, and then we would have to do the penetration testing again. That was a very long-winded process, whereas now, they can develop with confidence knowing that the libraries and binaries that they are using have already passed penetration testing. That saves a lot of time in the lifecycle. It's difficult to even quantify because it's so huge. But we're talking about reducing the development lifecycle by about 90 percent, minimum.

It has helped developer productivity. It's like working in the dark and all of a sudden you've got visibility. You can see exactly what you're using and you have suggestions so that, if you can't use something, you've got alternatives. That is huge.

What is most valuable?

When developers are consuming open-source libraries from the internet, it's able to automatically block the ones that are insecure. And it has the ability to make suggestions on the ones they should be using instead.

Also, you can get reports, either in PDF format or in JSON. If you get them in JSON you can have them ingested into something like Splunk, so you can mine those reports as well.

The application onboarding and Policy Grandfathering features are new and quite useful. They allow you to focus on what you're currently working on and the stuff that's grandfathered can go in your backlog. It's another feature that helps organize your workload.

The data is as good as can be. It's online, which means if a change is made to the Nexus database today, or within the hour, my developers will benefit instantly. The security features are discovered continuously. So if Nexus finds out that a library is no longer safe, they just have to flag it and, automatically, my developers will know. In addition to that, anything that I've used in the past will also flag up. Because it's proactive and it's live data, you know instantly if any part of your application is now vulnerable. Not only that but when you get the information about the vulnerability, part of the Lifecycle mechanism actually gives you alternatives that you can use.

It also integrates well with your existing DevOps tools. They've got very good plugins for most of the common DevOps tools, like Jenkins and GitHub. There are ways that you can work around things like TeamCity. The product is designed to help the DevOps process to be seamless in terms of security.

Regarding open-source intelligence and policy enforcement across the SDL, that's exactly what they're trying to do. They realized that there's so much ingestion of open-source software in most of the software development lifecycles, that there was a need to automate the detection of the ones that are not deemed to be safe. What Lifecycle does to its Firewall product is that, as the binaries are being ingested, it's able to fingerprint them. And because there's a fingerprint, it can check with the Sonatype website and tell you exactly what you're ingesting. If what you're ingesting is not secure, it can block it. Then, you can manually say, "Okay I understand, use this." Or you can go with the suggestion that Sonatype gives you, which is a more secure alternative. So we use it to automate open-source governance and to minimize risk.

There is also a feature called Continuous Monitoring. As time goes on we'll be able to know whether a platform is still secure or not because of this feature. It's integrated, it's proactive, it's exactly what you want for a security product.

What needs improvement?

They could do with making more plugins for the more common integration engines out there. Right now, it supports automation engine by Jenkins but it doesn't fully support something like TeamCity. That's where they could make the most improvements.

In terms of features, the reports natively come in as PDF or JSON. They should start thinking of another way to filter their reports. The reporting tool used by most enterprises, like Splunk and Elasticsearch, do not work as well with JSON. They should improve the reporting so that the format can be expanded.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

The stability is very good. It probably needs to be improved a bit more. The cluster technology is first-generation and is still maturing. It needs to mature a bit more.

IQ is quite stable. It's a very simple engine, it takes something in, makes a decision, and then gives you the output.

What do I think about the scalability of the solution?

The scalability is good but it can be improved. I think they're working on it, but it needs to be clusterable. The best case is to have a cluster, a native cluster, for IQ Server, to improve the availability.

How are customer service and technical support?

Technical support is very good and the model that Sonatype has taken is that it is a product company, it is not a service company. You get this great support and it doesn't cost you anything. The support that they provide you is very good and it's free.

Which solution did I use previously and why did I switch?

We weren't using a previous solution, we were using a different approach which was very old and which doesn't work. It was penetration testing which is very problematic. The way it worked was that an application was made and deployed. Then, you or a specialist firm tested the security of that application. You would get a report saying, "Okay, this is what we found." Then you would have to go back and change the application and, after that, get it tested again. You can see how much time it could take you - three, four, five, six months, a year, two years - to get your application tested. It was very inefficient.

The department that is concerned with best practices was obviously doing its homework and that's when they consulted Sonatype. They had some discussions and then the decision was made that this was the way forward. In fact, it is the only way.

How was the initial setup?

The setup is straightforward. The product itself is counter-intuitive for most people, but the setup is very straightforward. It takes less than ten minutes to set up and deploy it. The policies can also be set up using normal human language. There is an interface to do that, so there's very little programming that's required to help the product become operational.

Our implementation strategy for a product like this is that you want it to be available all the time. Nexus, fortunately, has implemented a cluster for their repositories. You can set up a Nexus cluster for Nexus repositories. Lifecycle is not fully clusterable, so that's an improvement that is needed. They need to make it highly available as a cluster that is Active-Active. Right now, you need to have Active-Passive. 

But it's very easy to set up, it doesn't require super expertise. Any developer or any system admin can do it.

They've made Nexus Repository Manager clusterable. From what I've heard, they are trying to make Lifecycle, IQ Server, clusterable as well.

Since implementation, we have had four or five people involved in maintaining it and making improvements. 

What about the implementation team?

It was done in-house by the people who were employed to work on this product. We did get support from Sonatype. They have what are called "success engineers." Sonatype, being a product type company, doesn't charge you for this service, but they will come and give you some tips if there's anything that you're not sure about, or they will show you what best practices are, which is very good. They are very knowledgeable.

From the word "go," with design and planning, any design that we did we passed on to them and discussed it with them. If there was anything that they didn't like or that diverted from best practices, they would advise about it.

For example, the cluster is supposed to be in the same data center. We did that and what would have suited us best is to have the cluster scattered among a couple of data centers. We did that and then we had to use a strategy were we replicated the data to another data center so that we had disaster recovery capabilities.


What was our ROI?

We see ROI in terms of better visibility into what we have in our developed software.

Which other solutions did I evaluate?

I think they looked at competitors but that wasn't my job. I'm familiar with the competitors. They are similar to Sonatype but, possibly, not as comprehensive. There are at least three or four other solutions using different but similar concepts. In my view, they're not as convenient or as good as Sonatype.

What other advice do I have?

My advice is "do it yesterday." You save yourself a lot of money. Even during one, two, or three weeks, it's going to cost you a lot of money to fix the security vulnerabilities that you are ingesting in your development lifecycle. You could be avoiding that by using a product like Lifecycle.

With Lifecycle, the product itself, the intelligence is contained in the implementation called IQ Server. IQ Server has a component called Firewall. The Firewall, as the libraries are ingested into the organization, will scan each and every one of them. Depending on the policies, it's customizable as well. You can put policies there to say, if the library missed this criteria, block it. And you can say, if you block it, "But this library's okay, allow it in." You can waive policies. It's very highly customizable, such that you can block it at ingestion and you've got five other levels through which you could disallow a library. You could block a library from going into your staging or your development.

It will be used by over 2,000 developers in our organization, and that is just Phase One. Other phases will be rolled out, so it will be an enterprise deployment for the whole bank. It's a financial institution, an investment bank that is very big. We may have over 10,000 developers.

For all organizations - but most of all for financial institutions - security is very important. Somebody in the bank gave a mandate that we need to be more secure and this was implemented. The best way is to get the developers into the idea is that, by using the product, they'll be actually be saving themselves some time, because as far as security is concerned, they won't be required to change their programs as much.

I would give this product a nine out of ten, knowing that I'll have a full report of artifacts that would have been ingested into our organization - artifacts that are not secure - if I didn't have the product. That information is priceless.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Buyer's Guide
Download our free Sonatype Nexus Lifecycle Report and get advice and tips from experienced pros sharing their opinions.
Updated: November 2022
Buyer's Guide
Download our free Sonatype Nexus Lifecycle Report and get advice and tips from experienced pros sharing their opinions.