Sonatype Nexus Lifecycle Valuable Features

Ricardo Van Den Broek
Software Architect at a tech vendor with 11-50 employees
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. View full review »
EdwinKwan
Security Team Lead at Tyro Payments Limited
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. View full review »
Michael Esmeraldo
Sr. Enterprise Architect at MIB Group
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. View full review »
Learn what your peers think about Sonatype Nexus Lifecycle. Get advice and tips from experienced pros sharing their opinions. Updated: January 2021.
456,812 professionals have used our research since 2012.
ConfigManag73548
Configuration Manager at a wellness & fitness company with 5,001-10,000 employees
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. View full review »
Austin Bradley
Enterprise Infrastrcture Architect at Qrypt
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. View full review »
Charles Chani
DevSecOps at a financial services firm with 10,001+ employees
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. View full review »
Julien Carsique
DevOps Engineer at a tech vendor with 51-200 employees
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. View full review »
reviewer1381962
Application Security at a comms service provider with 1,001-5,000 employees
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. View full review »
Ryan Carrie
Security Analyst at a computer software company with 51-200 employees
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. View full review »
Russell Webster
VP and Sr. Manager at a financial services firm with 1,001-5,000 employees
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. View full review »
Sebastian Lawrence
Solutions Delivery Lead at a financial services firm with 201-500 employees
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. View full review »
reviewer1268016
IT Security Manager at a insurance company with 5,001-10,000 employees
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. View full review »
reviewer1380810
Computer Architecture Specialist at a energy/utilities company with 10,001+ employees
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. View full review »
Axel Niering
Achitekt at SV Informatik GmbH
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. View full review »
Wes Kanazawa
Sr. DevOps Engineer at Primerica
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. View full review »
Andy Cox
Product Strategy Group Director at Civica
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. View full review »
reviewer1342230
Application Development Manager at a financial services firm with 501-1,000 employees
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. View full review »
JavaDevef0ca
Java Development Manager at a government with 10,001+ employees
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. View full review »
ManojKumar9
Systems Analyst at Thrivent Financial for Lutherans
* 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. View full review »
Scott Hibbard
DevOps Engineer at Guardhat
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. View full review »
Gus Orologas
Lead IT Security Architect at a transportation company with 10,001+ employees
* 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. View full review »
Learn what your peers think about Sonatype Nexus Lifecycle. Get advice and tips from experienced pros sharing their opinions. Updated: January 2021.
456,812 professionals have used our research since 2012.